# DC0077 — Container Start ## Descrição Container Start captura eventos relacionados à ativação ou invocação de um container em um ambiente containerizado. Isso inclui a inicialização de um container previamente parado, a reinicialização de um container existente, ou a inicialização de um container para execução em runtime. O monitoramento dessas atividades é crítico para identificar ativações não autorizadas ou inesperadas de containers, que podem indicar atividade adversarial ou configurações incorretas. A distinção entre Container Start (DC0077) e Container Creation (DC0072) é operacionalmente relevante: criação representa o ato de definir e construir o container, enquanto start representa a ativação de um container já existente (potencialmente dormente ou parado). Adversários frequentemente utilizam containers pré-criados (mas parados) como mecanismo de persistência — a carga maliciosa é implantada na fase de criação, mas ativada mais tarde para evadir detecção temporal. Em ambientes Kubernetes, o ciclo de vida de containers é gerenciado automaticamente pelo kubelet via health checks e políticas de restart, o que pode mascarar reinicializações adversariais. A detecção deve correlacionar eventos de start com a imagem utilizada, o usuário/service account que desencadeou a ação e o comportamento subsequente do processo dentro do container. ## Telemetria | Plataforma | Fonte de Log | Evento / API Call | Notas | |------------|-------------|-------------------|-------| | Docker | Docker Events / auditd | `docker start <container>`, `docker restart <container>` | `docker events --filter event=start --filter event=restart` | | Kubernetes | API Server Audit Logs + kubelet | Mudanças de estado de pod para `Running` | Correlacionar com restart count crescente (`kubectl get pods`) | | AWS ECS | CloudTrail | `StartTask`, `UpdateService` (force new deployment) | `taskArn` identifica o container iniciado | | Azure ACI | Activity Log | `Microsoft.ContainerInstance/containerGroups/start/action` | Reinicializações de container groups | | GCP GKE | Cloud Logging | Pod status transitions para `Running` em `k8s_cluster` | Verificar `protoPayload.response.status.phase` | ## Queries de Detecção ### KQL — Azure AKS: container reiniciando em loop (possível crash loop de malware) ```kql AzureDiagnostics | where Category == "kube-audit" | where log_s contains "\"reason\":\"Started\"" | extend PodName = extract("\"name\":\"([^\"]+)\"", 1, log_s) | extend Namespace = extract("\"namespace\":\"([^\"]+)\"", 1, log_s) | summarize RestartCount = count() by PodName, Namespace, bin(TimeGenerated, 30m) | where RestartCount > 5 | project TimeGenerated, PodName, Namespace, RestartCount | order by RestartCount desc ``` ## Técnicas Relacionadas | Técnica | Nome | Relação | |---------|------|---------| | [[t1610-deploy-container\|T1610-deploy-container]] | Deploy Container | Técnica primária — start de container malicioso implantado previamente | | [[t1059-command-and-scripting-interpreter\|T1059-command-and-scripting-interpreter]] | Command and Scripting Interpreter | Execução de shell dentro de container iniciado para executar payloads | | [[t1496-resource-hijacking\|T1496-resource-hijacking]] | Resource Hijacking | Start de container de mineração previamente criado e parado | > **Ver também:** [[ds0032-container|DS0032 — Container]], [[dc0072-container-creation]], [[dc0037-pod-enumeration]], [[t1610-deploy-container|T1610-deploy-container]], [[t1496-resource-hijacking|T1496-resource-hijacking]] ## Contexto LATAM > [!info] Persistência via containers no Brasil > A técnica de implantar containers maliciosos dormentes como mecanismo de persistência tem sido observada em ambientes Kubernetes de organizações brasileiras de médio porte, particularmente aquelas que não implementam políticas de admissão (OPA Gatekeeper, Kyverno) para válidar imagens e configurações de container. Em ambientes AWS ECS no Brasil, a ativação de tasks maliciosas via `StartTask` por credenciais comprometidas é um vetor de persistência de baixo ruído. Organizações devem implementar Network Policies Kubernetes para limitar comunicação entre containers, Falco rules para detectar start de containers com imagens não aprovadas, e revisão periódica de containers parados em clusters de produção — que podem ser payloads aguardando ativação. ## Referências - [MITRE ATT&CK — DC0077 Container Start](https://attack.mitre.org/datacomponents/DC0077) - [MITRE ATT&CK — T1610 Deploy Container](https://attack.mitre.org/techniques/T1610/) - [Docker — Container Lifecycle Events](https://docs.docker.com/engine/reference/commandline/events/) - [Kubernetes — Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/) - [Falco — Default Rules for Container Security](https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml)