# T1610 - Deploy Container ## Descrição Adversários podem **implantar um novo contêiner** em um ambiente comprometido para facilitar execução de código malicioso ou evadir defesas existentes. A técnica é especialmente eficaz em ambientes que adotaram orquestração de contêineres (Docker, Kubernetes) sem implementar controles de segurança adequados - onde a criação de novos contêineres é uma operação rotineira e pode passar despercebida. Em alguns casos, o objetivo é **executar malware de forma isolada**: o adversário implanta um contêiner a partir de uma imagem maliciosa (geralmente hospedada em registros públicos como Docker Hub) ou de uma imagem legítima que baixa e executa payloads no momento da inicialização. Isso permite que o código malicioso opere em um ambiente previsível e controlado, separado dos processos do host. Em outros casos, o contêiner é configurado **intencionalmente sem restrições de segurança** - sem limites de rede, sem políticas de usuário, sem capacidades Linux restringidas - para contornar controles que seriam aplicados a processos nativos do host. Em ambientes Kubernetes, um contêiner privilegiado implantado em um nó específico pode ser usado para executar [[t1611-escape-to-host|T1611 - Escape to Host]] e comprometer outros contêineres e workloads no mesmo nó. --- ## Como Funciona A implantação pode ocorrer por múltiplos meios dependendo do ambiente alvo: **Docker API exposta:** Se o socket Docker (`/var/run/docker.sock`) ou a API remota (porta 2375/2376) estiver acessível sem autenticação, o adversário pode criar e iniciar contêineres diretamente via chamadas de API ou CLI Docker. A API Docker sem TLS mútuo é equivalente a acesso root no host - qualquer contêiner privilegiado montando o sistema de arquivos do host tem controle total. **Kubernetes Dashboard / Kubeflow:** Interfaces web de gerenciamento Kubernetes frequentemente expostas sem autenticação adequada permitem que adversários criem Pods, Deployments, DaemonSets ou ReplicaSets. DaemonSets são particularmente perigosos pois propagam automaticamente o contêiner malicioso para **todos os nós do cluster**. **Comprometimento de credenciais de CI/CD:** Pipelines de integração contínua com acesso a clusters Kubernetes são alvos frequentes. Uma vez comprometido, o adversário usa as credenciais do pipeline para implantar workloads maliciosos via `kubectl apply` ou Helm. **Imagens maliciosas em registros públicos:** Grupos como [[g0139-teamtnt|TeamTNT]] publicaram imagens de mineração de criptomoedas (principalmente Monero) no Docker Hub com nomes que imitam imagens legítimas. Equipes que não verificam assinaturas de imagens ou usam tags `latest` sem fixar digest são vulneráveis. --- ## Attack Flow ```mermaid graph TB A[Acesso Inicial ao Ambiente] --> B{Vetor de Implantação} B --> C[Docker API Exposta - Porta 2375/2376] B --> D[Kubernetes Dashboard sem Auth] B --> E[Credenciais de CI/CD Comprometidas] B --> F[Imagem Maliciosa em Registro Público] C --> G[docker creaté + docker start] D --> H[kubectl apply - Pod ou DaemonSet] E --> H F --> G G --> I[Contêiner Implantado no Host] H --> J[Contêiner Propagado no Cluster] I --> K{Objetivo Final} J --> K K --> L[Mineração de Criptomoeda - Cryptojacking] K --> M[Escape para Host - T1611] K --> N[Execução de Malware Isolado] K --> O[Persistência no Cluster] ``` --- ## Exemplos de Uso **TeamTNT** é o grupo mais documentado nesta técnica. Especializado em ataques a ambientes cloud e contêineres, o grupo desenvolveu um kit completo de ataque incluindo os malwares [[s0599-kinsing|Kinsing]] e [[s0600-doki|Doki]], além da ferramenta de ataque Kubernetes [[s0683-peirates|Peirates]]. Suas campanhas implantam contêineres de mineração Monero em hosts Docker com API exposta, geralmente combinando T1610 com [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] para roubar credenciais de ambientes cloud (AWS, Azure, GCP). **Rocke Group**, grupo chinês focado em cryptojacking, usa técnicas similares em ambientes Docker e Kubernetes - frequentemente implantando contêineres que desativam ferramentas de monitoramento do cloud provider antes de iniciar a mineração, demonstrando consciência das defesas típicas de ambientes cloud. Em campanhas mais sofisticadas, adversários usam T1610 como pivot: implantam um contêiner aparentemente legítimo (baseado em imagem Alpine ou Ubuntu) que serve como ponto de entrada para realizar reconhecimento interno da rede de contêineres e identificar alvos para [[t1611-escape-to-host|escape para o host]]. --- ## Detecção ```yaml title: Privileged Container Deployment via Docker API status: experimental logsource: category: container_creation product: docker detection: selection_privileged: CommandLine|contains: - '--privileged' - '--cap-add SYS_ADMIN' - '--cap-add SYS_PTRACE' selection_mount_docker: CommandLine|contains: - '/var/run/docker.sock' - '/proc/:/host/proc' - '/sys/:/host/sys' condition: selection_privileged or selection_mount_docker level: high ``` Estrategias de detecção complementares: - **Auditoria de API Docker:** habilitar logging de todas as chamadas à API Docker (`/containers/creaté`, `/containers/start`) e alertar para imagens não constantes da allowlist aprovada - **Kubernetes Audit Logs:** monitorar eventos `creaté` e `patch` nos recursos Pod, Deployment e DaemonSet - especialmente com `securityContext.privileged: true` - **Network baseline de contêineres:** alertar para contêineres estabelecendo conexões externas inesperadas, especialmente para pools de mineração (portas 3333, 4444, 14444) - **Integridade de imagens:** implementar admission controllers (OPA/Gatekeeper, Kyverno) que rejeitam imagens sem assinatura digital verificada - **Detecção de escape:** monitorar chamadas de sistema `mount`, `nsenter`, acesso ao socket Docker de dentro de contêineres --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Restringir quem pode criar e iniciar contêineres. No Kubernetes, usar RBAC granular - nenhuma conta de serviço deve ter permissão `creaté` em Pods fora de seu namespace. Nunca expor o socket Docker para contêineres não privilegiados. | | M1047 | [[m1047-audit\|M1047 - Audit]] | Habilitar Kubernetes Audit Logging e Docker API logging. Revisar regularmente logs de criação de contêineres e alertar para imagens não aprovadas ou configurações privilegiadas. | | M1030 | [[m1030-network-segmentation\|M1030 - Network Segmentation]] | Implementar Network Policies no Kubernetes para restringir comúnicação entre namespaces e bloquear egress não autorizado. Usar CNI plugins (Calico, Cilium) com políticas de negação padrão. | | M1035 | [[m1035-limit-access-to-resource-over-network\|M1035 - Limit Access to Resource Over Network]] | Nunca expor a API Docker (porta 2375) sem TLS mútuo. Restringir o Kubernetes API server a IPs autorizados. Desabilitar Kubernetes Dashboard ou protegê-lo com autenticação forte e rede interna. | --- ## Contexto Brasil/LATAM O crescimento acelerado de adoção de Kubernetes e containers no Brasil - impulsionado por fintechs, empresas de e-commerce e órgãos de governo que migraram para cloud - criou uma superfície de ataque significativa. Pesquisas da Shodan e Censys frequentemente revelam APIs Docker expostas em IPs de provedores cloud brasileiros (AWS São Paulo, GCP São Paulo, Oracle Cloud Vinhedo). O setor financeiro brasileiro, sob regulação do [[banco-central-brasil|Banco Central]] e normas do [[febraban|FEBRABAN]], começa a incluir segurança de contêineres em seus frameworks de gestão de risco - mas a lacuna entre adoção tecnológica e maturidade de segurança permanece ampla. Incidentes de cryptojacking em ambientes cloud brasileiros têm sido reportados desde 2019, com grupos como [[g0139-teamtnt|TeamTNT]] realizando varreduras ativas em blocos de IP da região. Para equipes de segurança brasileiras, a prioridade deve ser o inventário de todos os ambientes Docker/Kubernetes expostos, implementação de admission controllers e revisão de permissões RBAC - medidas frequentemente ausentes em ambientes que cresceram rapidamente sem planejamento de segurança adequado. --- ## Software Associado - [[s0599-kinsing|Kinsing]] - malware de mineração Monero implantado via contêiner - [[s0600-doki|Doki]] - backdoor que usa API Docker para persistência e C2 - [[s0683-peirates|Peirates]] - ferramenta de ataque Kubernetes para comprometimento de clusters --- ## Referências - [[g0139-teamtnt|TeamTNT]] - [[t1611-escape-to-host|T1611 - Escape to Host]] - [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] - [[m1018-user-account-management|M1018 - User Account Management]] - [[m1047-audit|M1047 - Audit]] - [[m1030-network-segmentation|M1030 - Network Segmentation]] - [[s0599-kinsing|Kinsing Malware]] *Fonte: MITRE ATT&CK - T1610*