# T1204.003 - Imagem Maliciosa
## Técnica Pai
Esta é uma sub-técnica de [[t1204-user-execution|T1204 - T1204 - User Execution]].
## Descrição
Adversários podem comprometer ou criar imagens de contêineres e máquinas virtuais em nuvem para induzir usuários a executar código malicioso sem perceber. Imagens Docker públicadas no Docker Hub, AMIs (Amazon Machine Images) na AWS, imagens no Google Cloud Platform ou Azure podem ser manipuladas para incluir backdoors, mineradores de criptomoeda ou agentes de acesso remoto. Quando um desenvolvedor ou operador de infraestrutura baixa e executa essa imagem, o payload é executado automaticamente como parte do ciclo de vida normal do contêiner ou instância.
Essa técnica é particularmente insidiosa porque contorna controles tradicionais de acesso inicial: o usuário executa o código voluntariamente, acreditando tratar-se de uma imagem legítima. O atacante frequentemente combinada essa abordagem com [[t1036-005-match-legitimate-resource-name-or-location|typosquatting de nomes de imagem]] - por exemplo, públicar `ubuntuu/nginx` ou `nginx-offcial` para imitar repositórios populares. O grupo [[g0139-teamtnt|TeamTNT]] notabilizou-se por essa tática ao públicar imagens Docker com mineradores de criptomoeda embutidos no Docker Hub, atingindo ambientes Kubernetes e Docker Swarm ao redor do mundo.
As imagens maliciosas também podem ser carregadas via [[t1608-001-upload-malware|upload direto para registries privados]] comprometidos dentro de pipelines de CI/CD. Em ambientes DevOps com baixa maturidade em segurança, não é incomum que imagens base não sejam verificadas por assinaturas digitais, abrindo espaço para substituição silenciosa durante o processo de build.
**Contexto Brasil/LATAM:** O crescimento acelerado de adoção de contêineres e nuvem pública no Brasil - especialmente em fintechs, e-commerces e startups - cria um terreno fértil para essa técnica. Equipes de engenharia que priorizam agilidade frequentemente pulam etapas de verificação de proveniência de imagens. Campanhas de cryptojacking como as do [[g0139-teamtnt|TeamTNT]] já exploraram ambientes brasileiros na AWS e GCP, usando imagens maliciosas para minerar Monero em instâncias de alto poder computacional. A ausência de políticas de assinatura de imagem (OCI Image Signing) é um gap crítico na maioria das organizações da região.
## Attack Flow
```mermaid
graph TB
A[Upload de Imagem Maliciosa] --> B[Usuário faz docker pull]
B --> C[Contêiner iniciado]
C --> D[Payload executado]
D --> E[C2 / Cryptomining]
```
## Como Funciona
**1. Preparação**
O adversário cria ou compromete uma imagem de contêiner ou VM. A imagem é públicada em um registry público (Docker Hub, ECR público, GCR) com nome que imita projetos legítimos populares. Em ataques mais sofisticados, registries privados de organizações são comprometidos via credenciais vazadas de pipelines CI/CD.
**2. Execução**
O usuário - desenvolvedor, engenheiro de infraestrutura ou processo automatizado - executa o pull e start da imagem. O payload embutido é acionado como parte do `ENTRYPOINT` ou `CMD` do Dockerfile, ou via scripts de inicialização ocultos em layers da imagem.
```bash
# Artefato de detecção: pull de imagem com nome suspeito (typosquatting)
# docker pull ubuntuu/redis:latest
# docker run -d --name cache ubuntuu/redis:latest
# Verificar layers de imagem para scripts ocultos:
docker history --no-trunc <image_id>
docker inspect <image_id> | jq '.[0].Config.Entrypoint'
```
**3. Pós-execução**
O contêiner malicioso estabelece comunicação com infraestrutura de C2, inicia mineração de criptomoeda, ou realiza movimentação lateral dentro do cluster Kubernetes. Em ambientes IaaS, a imagem comprometida pode acessar o serviço de metadados de instância para roubar credenciais de IAM.
## Detecção
**Fontes de dados:** Logs de registry (pull events), runtime de contêiner (Docker daemon logs, containerd logs), Network flow logs (conexões de saída para pools de mineração), auditoria de imagens com Trivy/Grype, alertas de comportamento anômalo em plataformas como AWS GuardDuty e GCP Security Command Center.
```yaml
title: Pull de imagem de contêiner de registry não aprovado
id: b7e2d341-9f3c-4a8e-c6d2-1b5f7a3e9c04
status: experimental
description: Detecta tentativas de pull de imagens Docker de registries não presentes na lista de aprovados
logsource:
category: container
product: docker
detection:
selection:
EventType: 'pull'
Image|not|startswith:
- 'mycompany.azurecr.io/'
- 'gcr.io/my-project/'
- '123456789.dkr.ecr.us-east-1.amazonaws.com/'
condition: selection
falsepositives:
- Desenvolvedores testando imagens localmente em ambientes de desenvolvimento
- Pulls de imagens base em builds legítimos ainda não migrados para registry interno
level: medium
tags:
- attack.execution
- attack.t1204.003
```
## Mitigação
| Mitigação | Recomendação Prática |
|-----------|---------------------|
| [[m1045-code-signing\|M1045 - Code Signing]] | Implementar assinatura de imagens com Cosign (Sigstore) e aplicar políticas de admissão via OPA/Kyverno que rejeitam imagens sem assinatura válida |
| [[m1031-network-intrusion-prevention\|M1031 - Network Intrusion Prevention]] | Bloquear conexões de saída de contêineres para domínios e IPs conhecidos de pools de mineração e C2; usar Network Policies no Kubernetes |
| [[m1017-user-training\|M1017 - User Training]] | Treinar equipes de engenharia para verificar proveniência de imagens, preferir registries privados internos e desconfiar de imagens com nomes similares a projetos populares |
| [[m1047-audit\|M1047 - Audit]] | Escanear imagens com Trivy ou Grype no pipeline de CI/CD antes do deploy; auditar regularmente imagens em uso nos clusters de produção |
## Referências
*Fonte: [MITRE ATT&CK - T1204.003](https://attack.mitre.org/techniques/T1204/003)*