# T1525 - Implant Internal Image ## Descrição Adversários podem implantar imagens de nuvem ou contêiner com código malicioso para estabelecer persistência após obter acesso a um ambiente. Imagens como **Amazon Machine Images (AMIs)** na AWS, imagens do **Google Cloud Platform (GCP)**, imagens do **Azure** e runtimes populares de contêiner como **Docker** e **Kubernetes** podem ser backdooriadas ou substituídas por versões comprometidas. Diferente de técnicas de upload de malware externo, esta técnica foca em adversários que implantam uma imagem diretamente em um registro interno da vítima - sejá um repositório privado no **Amazon ECR**, **Google Artifact Registry**, **Azure Container Registry** ou um registro Docker auto-hospedado. Se a infraestrutura for provisionada automaticamente para sempre usar a imagem mais recente (padrão em pipelines CI/CD), a persistência se torna imediata e escalável. O adversário geralmente já possui acesso ao ambiente - obtido via [[t1078-valid-accounts|T1078 - Contas Válidas]] ou [[t1190-exploit-public-facing-application|T1190 - Exploração de Aplicação Exposta]] - e em seguida: 1. Lista as imagens disponíveis no registro interno 2. Faz o pull de uma imagem legítima 3. Injeta código malicioso (ex: um [[t1505-003-web-shell|Web Shell]], um agente de C2, ou um coletor de credenciais) 4. Faz o push da imagem backdooriada de volta ao registro com a mesma tag (ex: `latest`) 5. Aguarda que novos contêineres sejam provisionados automaticamente a partir da imagem comprometida ```mermaid graph TB A[Acesso Inicial ao Ambiente Cloud] --> B[Listagem de Imagens no Registro Interno] B --> C[Pull da Imagem Legítima] C --> D[Injeção de Código Malicioso] D --> E[Push da Imagem Backdooriada<br/>com mesma tag 'latest'] E --> F{Provisionamento\nAutomático?} F -->|CI/CD Pipeline| G[Novos Contêineres Infectados] F -->|Manual| H[Aguarda Próximo Deploy] G --> I[Persistência Estabelecida] H --> I I --> J[Execução de Payload<br/>C2 / Webshell / Coletor] ``` Esta abordagem é particularmente eficaz em ambientes **cloud-native** e **DevOps** onde o ciclo de deploy é frequente e as imagens raramente são inspecionadas antes do uso. Grupos como [[g0139-teamtnt|TeamTNT]] e [[g0106-rocke|Rocke]] foram observados abusando de registros Docker públicos e privados para distribuir mineradores de criptomoedas e agentes de movimento lateral. ## Detecção A detecção eficaz requer monitoramento de operações no plano de controle de imagens, não apenas no runtime dos contêineres: | Vetor de Detecção | O que Monitorar | |-------------------|-----------------| | Logs de registro de contêiner | Push de novas camadas ou tags em imagens existentes - especialmente `latest` | | CloudTrail / Audit Logs | `PutImage`, `InitiateLayerUpload`, `CompleteLayerUpload` na AWS ECR | | Assinatura de imagem | Imagens sem assinatura válida (ex: Cosign / Notary) | | Diff de camadas | Camadas adicionadas ou modificadas em relação à imagem base oficial | | Pipeline CI/CD | Builds que não passam por processo de revisão ou varredura de vulnerabilidades | Ferramentas como **Falco**, **Trivy** e **Grype** podem ser integradas ao pipeline para escanear imagens antes do deploy e alertar sobre camadas suspeitas ou binários não esperados. ## Mitigação | ID | Mitigação | Aplicação | |----|-----------|-----------| | M1045 | [[m1045-code-signing\|M1045 - Code Signing]] | Assinar todas as imagens com Cosign ou Notary; rejeitar imagens sem assinatura válida | | M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Restringir quem tem permissão de `push` em registros de imagem; usar roles mínimas | | M1047 | [[m1047-audit\|M1047 - Audit]] | Auditar periodicamente todas as imagens no registro; comparar digest com baseline conhecido | ## Contexto Brasil/LATAM No Brasil e na América Latina, a adoção acelerada de infraestruturas cloud e práticas DevOps em setores como [[financial|financeiro]], [[government|governo]] e [[telecommunications|telecomúnicações]] ampliou significativamente a superfície de ataque explorada por essa técnica. Grupos como [[g0139-teamtnt|TeamTNT]] têm mira em instâncias mal configuradas na AWS e GCP hospedadas por empresas brasileiras, implantando imagens backdooriadas com mineradores de criptomoeda e agentes de [[t1496-resource-hijacking|Resource Hijacking]]. A prática de expor endpoints Docker sem autenticação - ainda comum em ambientes de desenvolvimento de startups e fintechs brasileiras - facilita o push de imagens comprometidas diretamente nos registros internos. Além disso, a baixa maturidade de práticas de assinatura de imagem (Cosign/Notary) na região faz com que imagens modificadas passem sem inspeção nos pipelines CI/CD. Equipes de segurança devem priorizar a auditoria de registros privados - especialmente Amazon ECR e Google Artifact Registry - e implementar políticas de controle baseadas em [[m1045-code-signing|M1045 - Code Signing]] e [[m1026-privileged-account-management|M1026 - Privileged Account Management]] para reduzir o risco de persistência via imagem backdooriada. ## Técnicas Relacionadas - [[t1610-deploy-container|T1610 - Deploy Container]] - adversários podem usar a imagem implantada para provisionar novos contêineres maliciosos - [[t1525-implant-internal-image|T1525]] pode ser combinado com [[t1078-valid-accounts|T1078]] para obter as credenciais necessárias para o push - [[t1505-003-web-shell|T1505.003 - Web Shell]] - payload comum encontrado em imagens backdooriadas - [[t1496-resource-hijacking|T1496 - Resource Hijacking]] - mineradores de criptomoeda frequentemente entregues via imagens comprometidas pelo [[g0139-teamtnt|TeamTNT]] --- *Fonte: [MITRE ATT&CK - T1525](https://attack.mitre.org/techniques/T1525)*