t1612-build-image-on-host

# T1612 - Build Image on Host ## Descrição Adversários podem construir uma imagem de container diretamente no host comprometido para contornar defesas que monitoram o download de imagens maliciosas a partir de registries públicos. Em ambientes de containerização, soluções de segurança frequentemente monitoram operações de `docker pull` e `kubectl` para detectar imagens conhecidas como maliciosas ou não autorizadas. A técnica T1612 contorna esse controle ao não baixar uma imagem pronta - em vez disso, o adversário envia uma requisição de **build** à API do Docker (ou APIs equivalentes de outros runtimes de container) acompanhada de um `Dockerfile` que instrui o host a construir a imagem localmente. O `Dockerfile` malicioso tipicamente parte de uma **imagem base legítima e inócua** - como `alpine`, `ubuntu`, `debian` ou `busybox` - disponível em registries públicos como Docker Hub. Por ser uma imagem amplamente reconhecida como legítima, o pull inicial não levanta alertas em soluções de segurança que trabalham com listas de imagens permitidas ou análise de reputação. A partir dessa base limpa, o `Dockerfile` inclui instruções `RUN` que baixam o payload malicioso diretamente do servidor C2 do adversário durante o processo de build, compila ferramentas de ataque, ou configura backdoors diretamente na camada da imagem resultante. Após a construção da imagem maliciosa no host, o adversário a utiliza em conjunto com [[t1610-deploy-container|T1610 - Deploy Container]] para instanciar containers que executam as cargas maliciosas - sejá para cryptomining, exfiltração de dados, movimento lateral dentro do cluster, ou estabelecimento de persistência. A combinação dessas duas técnicas forma um vetor de ataque completo contra infraestruturas Kubernetes e Docker que frequentemente opera abaixo do limiar de detecção de ferramentas de segurança tradicionais não adaptadas para ambientes de container. ## Como Funciona O fluxo de ataque via T1612 segue estas etapas principais: 1. **Acesso à API do Docker/container runtime:** O adversário obtém acesso à socket do Docker (`/var/run/docker.sock`) ou à API REST do Docker (porta 2375/2376). Esse acesso pode ser obtido por exploração de um container com montagem indevida da socket, via credenciais vazadas, ou por APIs Docker expostas sem autenticação na internet. 2. **Construção do Dockerfile malicioso:** O adversário prepara um `Dockerfile` que usa uma imagem base legítima e inclui instruções para baixar e configurar o payload malicioso durante o build. O payload pode ser um binário de cryptominer, um agente de C2, uma ferramenta de scanning de rede, ou qualquer outra carga. 3. **Envio da requisição de build:** A requisição `POST /build` é enviada à API do Docker com o contexto de build (Dockerfile + arquivos necessários). O daemon Docker executa o build localmente, baixando o payload do servidor C2 durante as etapas `RUN`. 4. **Imagem construída localmente:** A imagem resultante existe apenas no host local - nunca foi baixada de um registry monitorado. Ferramentas que verificam proveniência de imagens via digest de registry não conseguem rastreá-la. 5. **Deploy e execução:** Com a imagem construída, o adversário usa [[t1610-deploy-container|T1610 - Deploy Container]] para criar um ou mais containers a partir dela, executando o payload com as configurações desejadas (ex: modo privilegiado, montagem de volumes do host, acesso à rede do host). ## Attack Flow ```mermaid graph TB A[Acesso Inicial Docker API exposta ou socket comprometida] --> B[Reconhecimento da infrastrutura de containers docker info / ps] B --> C[Preparação do Dockerfile malicioso com base legítima alpine/ubuntu] C --> D[POST /build para Docker API local] D --> E[Docker daemon executa build no host] E --> F[Pull da imagem base legítima do registry] F --> G[Execução das instruções RUN Download do payload do C2] G --> H[Imagem maliciosa construída localmente sem rastro em registry] H --> I[Deploy Container T1610] I --> J{Objetivo} J --> K[Cryptomining em containers] J --> L[Backdoor / C2 persistente] J --> M[Movimento lateral no cluster Kubernetes] J --> N[Escape para o host via container privilegiado] ``` ## Exemplos de Uso **TeamTNT - Build de imagens de cryptomining em Kubernetes:** O grupo [[g0139-teamtnt|TeamTNT]] foi documentado usando a técnica T1612 em campanhas contra clusters Kubernetes mal configurados. Após comprometer nós do cluster via APIs Kubernetes expostas ou credenciais vazadas em repositórios públicos, o grupo enviava `Dockerfiles` para a API do Docker que construíam imagens baseadas em `alpine` com o minerador XMRig compilado durante o build. As imagens resultantes não tinham correspondência em nenhum registry público, tornando ineficazes as soluções de segurança baseadas em verificação de hash de imagem. **Abuso de registries locais (air-gapped clusters):** Em ambientes corporativos com restrições de acesso à internet, adversários que comprometem um nó com acesso a um registry interno privado podem construir imagens maliciosas e enviá-las ao registry interno. Quando outros nós do cluster fazem pull dessa imagem para novos deploys, disseminam o malware por todo o ambiente. Esse vetor é particularmente perigoso em clusters Kubernetes de produção onde pipelines CI/CD automatizados fazem deploy contínuo de imagens do registry interno. **Evasão de políticas de admissão Kubernetes:** Algumas organizações implementam *Admission Controllers* (como OPA Gatekeeper ou Kyverno) que bloqueiam o deploy de imagens de registries não autorizados. Ao construir a imagem localmente e fazer push para um registry interno autorizado (usando credenciais comprometidas), adversários podem contornar essas políticas. O Dockerfile benigno na aparência e a imagem base legítima reduzem a probabilidade de alertas em scanners de imagem estáticos como Trivy ou Grype, que podem não detectar payloads baixados em tempo de build se não tiverem assinaturas para o binário específico. **Compilação de ferramentas de ataque durante build:** Uma variante sofisticada envolve um `Dockerfile` que não baixa um binário pré-compilado (mais fácil de detectar por hash), mas sim código-fonte de um repositório público legítimo (ex: GitHub) que é compilado dentro do container durante o build. O resultado é um binário único que não tem hash conhecido em bancos de dados de threat intelligence, tornando a detecção baseada em assinatura completamente ineficaz. ## Detecção **Regra Sigma - Requisição de build à API Docker:** ```yaml title: Docker Build API Call - Potential T1612 Build Image on Host status: experimental description: > Detecta requisições de build enviadas à API do Docker que podem indicar T1612 - Build Image on Host. Construções de imagem locais são incomuns em ambientes de produção onde imagens devem originar de pipelines CI/CD. logsource: product: docker service: daemon detection: selection: EventType: 'build' Action: 'build' filter_cicd: Actor|contains: - 'jenkins' - 'gitlab-runner' - 'github-actions' - 'tekton' condition: selection and not filter_cicd fields: - Actor - Action - ResponseCode - RequestURI falsepositives: - Desenvolvimento local legítimo - Pipelines CI/CD que constroem imagens diretamente no nó level: medium tags: - attack.defense_evasion - attack.t1612 ``` **Regra Sigma - Conexões de saída durante processo de build:** ```yaml title: Suspicious Outbound Connection During Docker Build status: experimental description: > Detecta conexões de rede de saída originadas do processo dockerd durante operações de build, especialmente para IPs/domínios não relacionados a registries de imagem conhecidos. Pode indicar download de payload C2 durante etapas RUN do Dockerfile (T1612). logsource: category: network_connection product: linux detection: selection: Image|contains: 'dockerd' Initiated: 'true' filter_known_registries: DestinationHostname|endswith: - 'docker.io' - 'registry-1.docker.io' - 'gcr.io' - 'ghcr.io' - 'quay.io' - 'amazonaws.com' - 'azurecr.io' - 'pkg.dev' condition: selection and not filter_known_registries fields: - DestinationIp - DestinationHostname - DestinationPort - Image falsepositives: - Builds legítimos que baixam dependências de fontes não-padrão - Registries privados internos level: high tags: - attack.defense_evasion - attack.t1612 - attack.command_and_control ``` **Fontes de dados recomendadas:** - Docker daemon logs (`/var/log/docker.log` ou `journalctl -u docker`) - Kubernetes Audit Logs - eventos de criação de pods e imagens não reconhecidas - Falco - regras para detecção de uso anômalo da Docker API - Network flow logs - conexões de saída do processo `dockerd` para destinos não-padrão - Container image scanning pós-build (Trivy, Grype, Syft) - análise da imagem resultante - eBPF-based tools (Tetragon, Tracee) - syscall monitoring durante operações de build ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1035 | [[m1035-limit-access-to-resource-over-network\|M1035 - Limit Access to Resource Over Network]] | Restringir o acesso à API do Docker (porta 2375/2376 e socket Unix) apenas a processos e usuários estritamente necessários. Nunca expor a API Docker na rede sem TLS e autenticação mútua. Usar grupos Unix para controlar acesso à socket `/var/run/docker.sock` | | M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Implementar o princípio do menor privilégio para serviços que interagem com o Docker runtime. Evitar montar a Docker socket em containers de aplicação - se necessário, usar proxies como `docker-socket-proxy` que filtram operações perigosas como `/build` | | M1030 | [[m1030-network-segmentation\|M1030 - Network Segmentation]] | Implementar network policies no Kubernetes que restrinjam o tráfego de saída dos nós do cluster para IPs não autorizados durante operações de build. Usar egress filtering para bloquear conexões de containers e do daemon Docker para destinos não incluídos em allowlist | | M1047 | [[m1047-audit\|M1047 - Audit]] | Auditar regularmente as imagens presentes no host (`docker images`) e identificar imagens sem proveniência de registry conhecido. Implementar Image Policy Webhook no Kubernetes para rejeitar o deploy de imagens sem digest de registry confiável. Usar OPA Gatekeeper ou Kyverno para enforcement de políticas de imagem | | - | Admission Controllers | Configurar válidating admission webhooks no Kubernetes para rejeitar pods que tentam usar imagens construídas localmente (sem referência a registry externo com digest verificado) | | - | Imutabilidade do daemon Docker | Em ambientes de produção Kubernetes, considerar substituir Docker por runtimes mais seguros como containerd com configurações de segurança endurecidas, ou usar nós gerenciados pelo provedor de cloud onde o acesso ao runtime é restrito | ## Contexto Brasil/LATAM A técnica T1612 é especialmente relevante para o cenário brasileiro em razão do crescimento acelerado de adoção de Kubernetes e Docker por empresas de todos os portes - muitas vezes sem as devidas práticas de segurança em ambientes de produção. Pesquisas da CERT.br e relatórios de resposta a incidentes de provedores de cloud operando no Brasil consistentemente identificam APIs Docker expostas sem autenticação como um dos vetores de comprometimento mais comuns em servidores Linux no país. Campanhas de cryptomining, que são desproporcionalmente direcionadas à infraestrutura de cloud brasileira e latino-americana, são as principais usuárias desta técnica na região. Grupos como [[g0139-teamtnt|TeamTNT]] têm histórico de varreduras massivas de APIs Docker expostas em ranges de IP de provedores brasileiros como UOL, Locaweb, Contabo Brasil e outros. Uma vez dentro, a construção local de imagens de mining via T1612 garante que as soluções de segurança contratadas pelos provedores - que frequentemente se baseiam em verificação de hash de imagens conhecidas - não detectem a atividade maliciosa. Além do cryptomining, há crescente evidência de uso desta técnica por grupos de ransomware que operam na América Latina para preparar containers de staging usados na exfiltração de dados antes da criptografia. A dificuldade de detecção combinada com a velocidade de deploy em ambientes Kubernetes torna o T1612 uma técnica de alto risco para organizações brasileiras que operam plataformas digitais com infraestrutura containerizada. Times de segurança em empresas brasileiras que adotaram Kubernetes devem priorizar a implementação de políticas de admissão, o monitoramento de logs do daemon Docker e a adoção de ferramentas especializadas como Falco para detecção em tempo real de comportamentos anômalos no nível do container runtime - recursos frequentemente ausentes nos SOCs nacionais que ainda estão em processo de maturação para segurança de ambientes cloud-native. ## Referências - [[t1610-deploy-container|T1610 - Deploy Container]] - Técnica complementar usada para instanciar a imagem maliciosa construída - [[t1059-004-unix-shell|T1059.004 - Unix Shell]] - Frequentemente usada nas instruções RUN do Dockerfile para execução de comandos maliciosos durante o build - [[t1106-native-api|T1106 - Native API]] - Chamadas de API do Docker como vetor de acesso à funcionalidade de build - [[m1035-limit-access-to-resource-over-network|M1035 - Limit Access to Resource Over Network]] - Mitigação principal: restringir acesso à Docker API - [[m1047-audit|M1047 - Audit]] - Auditoria contínua de imagens e operações de build - [[m1030-network-segmentation|M1030 - Network Segmentation]] - Segmentação de rede para bloquear download de payloads C2 durante builds - [[g0139-teamtnt|TeamTNT]] - Grupo com amplo histórico de abuso de ambientes Docker/Kubernetes usando esta técnica --- *Fonte: MITRE ATT&CK - T1612*