# T1059.013 - Container CLI/API ## Técnica Pai Esta é uma sub-técnica de [[t1059-command-scripting-interpreter|T1059 - T1059 - Command and Scripting Interpreter]]. ## Descrição Adversários abusam das ferramentas de linha de comando e APIs nativas de ambientes de contêiner para executar comandos maliciosos diretamente na infraestrutura alvo. O Docker, plataforma de conteinerização mais popular do mundo, expõe uma API via socket Unix ou porta TCP que o daemon `dockerd` usa para receber instruções. Qualquer processo com acesso a esse socket - sejá via Docker CLI, SDKs de linguagens como Python ou Go, ou chamadas REST diretas - pode controlar totalmente o ambiente de contêineres sem necessidade de privilégios adicionais do sistema operacional. Quando um atacante obtém acesso à API Docker ou ao `kubectl` (interface de linha de comando do Kubernetes), ele é capaz de executar práticamente qualquer ação no cluster: criar novos contêineres com imagens maliciosas, executar comandos dentro de contêineres já em execução, mapear volumes do host para exfiltrar dados, ou montar o sistema de arquivos raiz do nó para escalar privilégios. Uma tática comum é puxar imagens legítimas que contêm utilitários como `curl` ou `wget` e usá-las como plataformas de ataque - reduzindo alertas por parecerem atividade normal de DevOps. No ecossistema Kubernetes, a superfície de ataque é ainda maior. O servidor de API (`kube-apiserver`) é o ponto central de controle de todo o cluster e pode ser acessado diretamente via HTTP/HTTPS por qualquer cliente com credenciais válidas. Atacantes utilizam chamadas como `kubectl exec`, `kubectl creaté pod` e `kubectl get secrets` para movimento lateral entre namespaces, coleta de credenciais armazenadas em Secrets e implantação de workloads persistentes. O grupo [[g0139-teamtnt|TeamTNT]] é referência nessa técnica, tendo desenvolvido campanhas inteiras voltadas a instâncias Docker expostas e clusters Kubernetes misconfigured para mineração de criptomoedas e roubo de credenciais de nuvem. **Contexto Brasil/LATAM:** A adoção acelerada de DevOps e infraestruturas baseadas em contêineres em empresas brasileiras - especialmente no setor financeiro, fintechs e e-commerce - amplia significativamente a exposição a essa técnica. Instâncias Docker com API exposta sem autenticação são frequentemente encontradas em ambientes de desenvolvimento que, por descuido operacional, acabam acessíveis na internet. Clusters Kubernetes na AWS, GCP e Azure administrados por equipes reduzidas também são alvo frequente de varreduras automatizadas realizadas por grupos como o [[g0139-teamtnt|TeamTNT]]. ## Attack Flow ```mermaid graph TB A[Acesso Inicial] --> B[Descoberta de API Docker/K8s] B --> C[T1059.013 - Container CLI/API] C --> DDeploy Container] D --> EReconhecimento de Cluster] ``` ## Como Funciona **1. Preparação - Descoberta da superfície de ataque** O atacante escaneia a rede em busca de portas típicas de API Docker (2375/TCP sem TLS, 2376/TCP com TLS) ou do servidor de API Kubernetes (6443/TCP, 8443/TCP). Ferramentas como `masscan` e `shodan` são usadas para localizar instâncias expostas. Uma vez identificada a API, verifica-se o nível de acesso: ```bash # Verificação de API Docker exposta (artefato de detecção) curl -s http://<alvo>:2375/version curl -s http://<alvo>:2375/containers/json ``` **2. Execução - Abuso da CLI/API** Com acesso confirmado, o atacante usa `docker` CLI ou chamadas REST diretas para executar comandos maliciosos. Fluxos típicos incluem: - Listar contêineres em execução para identificar workloads sensíveis (`docker ps`) - Inspecionar variáveis de ambiente em busca de credenciais (`docker inspect <id>`) - Executar shell interativo dentro de contêiner existente (`docker exec -it <id> /bin/sh`) - Criar novo contêiner com volume do host montado para acesso ao sistema de arquivos raiz ```bash # Artefato de detecção - criação de contêiner com acesso root ao host docker run -v /:/host --rm -it alpine chroot /host ``` **3. Pós-execução - Persistência e exfiltração** Após execução inicial, o atacante instala [[t1610-deploy-container|contêineres persistentes]] configurados para reiniciar automaticamente (`--restart=always`), realiza [[t1613-container-and-resource-discovery|descoberta de recursos]] no cluster, e pode usar a técnica [[t1612-build-image-on-host|Build Image on Host]] para construir imagens customizadas que mascaram as ferramentas maliciosas dentro de camadas de imagem legítimas. ## Detecção **Fontes de dados:** Docker daemon logs, Kubernetes audit logs (Event ID equivalente: `kube-apiserver` audit events), Linux auditd para chamadas `execve` dentro de contêineres, Falco runtime security rules. ```yaml title: Docker Remote API Accessed Without TLS id: 9f3a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c status: experimental description: Detecta acesso à API Docker sem TLS, indicativo de instância exposta ou abuso de API logsource: category: network_connection product: linux detection: selection: DestinationPort: - 2375 Protocol: tcp condition: selection falsepositives: - Ambientes de desenvolvimento com Docker sem TLS configurado internamente level: high tags: - attack.execution - attack.t1059.013 ``` ## Mitigação | Mitigação | Recomendação Prática | |-----------|---------------------| | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Nunca expor o socket Docker (`/var/run/docker.sock`) para contêineres não confiáveis; restringir acesso à API com certificados TLS mútuo (mTLS) e RBAC no Kubernetes | | [[m1038-execution-prevention\|M1038 - Execution Prevention]] | Implementar políticas de admissão no Kubernetes (OPA/Gatekeeper, Kyverno) que bloqueiem pods privilegiados e volumes `hostPath`; usar `securityContext` para limitar capacidades de contêineres | ## Referências *Fonte: [MITRE ATT&CK - T1059.013](https://attack.mitre.org/techniques/T1059/013)*