# T1552.005 - Cloud Instance Metadata API > [!danger] Técnica de Credential Access > **Tática:** Credential Access | **Plataforma:** IaaS (AWS, Azure, GCP, Oracle Cloud) | **MITRE ID:** T1552.005 > Adversários acessam a API de metadados de instâncias cloud para coletar credenciais temporárias, tokens IAM e dados sensíveis sem necessidade de autenticação adicional dentro da instância. ## Descrição A técnica **T1552.005 - Cloud Instance Metadata API** descreve como adversários exploram o serviço de metadados de instâncias disponível em práticamente todos os provedores de nuvem (AWS, Azure, GCP, Oracle Cloud) para coletar credenciais e dados sensíveis sem necessidade de autenticação adicional. Em ambientes de nuvem, cada instância virtual (VM) tem acesso a um endpoint especial de metadados, acessível exclusivamente de dentro da própria instância. Este serviço foi projetado para facilitar o gerenciamento e automação de aplicações cloud-native, fornecendo informações sobre o ambiente de execução. O endereço padrão deste serviço é `http://169.254.169.254` - um endereço IP de link-local que não é roteável pela internet pública, mas é acessível internamente a partir da VM. O serviço de metadados expõe informações como: - **Credenciais IAM temporárias** associadas ao perfil de instância (AWS Instance Profile, Azure Managed Identity, GCP Service Account) - **Tokens de acesso** para serviços cloud (S3, Azure Blob Storage, GCS, etc.) - **Scripts UserData** que frequentemente contêm segredos, senhas e chaves de API embutidas por administradores durante a inicialização da instância - **Dados de configuração** do ambiente, rede, região e zona de disponibilidade - **Certificados** e chaves criptográficas O cenário de abuso mais crítico envolve **vulnerabilidades SSRF (Server-Side Request Forgery)** em aplicações web públicas hospedadas na nuvem. Um adversário que explora uma vulnerabilidade SSRF pode forçar o servidor a realizar uma requisição ao endpoint de metadados `http://169.254.169.254/latest/meta-data/iam/security-credentials/` e retornar as credenciais IAM da instância ao atacante - sem necessitar de acesso direto à VM. Esta técnica está intimamente ligada à [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] e pode ser o ponto de partida para [[t1078-valid-accounts|T1078 - Valid Accounts]] quando as credenciais obtidas são reutilizadas para autenticação em outros serviços AWS/Azure/GCP. O grupo [[g0139-teamtnt|TeamTNT]] é o ator de ameaças mais documentado no uso desta técnica, particularmente em ataques a ambientes Kubernetes e Docker expostos, onde a API de metadados é frequentemente acessada para pivotar de workloads comprometidos para o plano de controle cloud. ## Como Funciona A exploração da Cloud Instance Metadata API pode ocorrer de duas formas principais: ### 1. Acesso Direto (Presença na Instância) Quando um adversário já possui execução de código dentro de uma instância cloud (após comprometer um container, explorar uma vulnerabilidade RCE ou obter acesso SSH não autorizado), a API de metadados é acessível diretamente: **AWS - Coleta de credenciais IAM:** ``` GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ GET http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name} ``` A resposta retorna `AccessKeyId`, `SecretAccessKey` e `Token` temporários (válidos por até 6 horas), que podem ser utilizados com o AWS CLI ou SDK para acessar recursos S3, EC2, Lambda, etc. **AWS - Coleta de UserData (scripts de inicialização):** ``` GET http://169.254.169.254/latest/user-data ``` Scripts UserData frequentemente contêm credenciais de banco de dados, chaves de API de terceiros e senhas hardcoded inseridas por equipes de DevOps. **GCP - Token de Service Account:** ``` GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token Header: Metadata-Flavor: Google ``` **Azure - Token de Managed Identity:** ``` GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/ Header: Metadata: true ``` ### 2. Exploração via SSRF O vetor mais perigoso: a aplicação web hospedada na VM é vulnerável a SSRF. O adversário envia uma requisição maliciosa que faz o servidor realizar uma chamada interna ao endpoint de metadados e retornar o resultado: ``` GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role ``` O servidor processa a URL como legítima, acessa a API de metadados de dentro da rede interna, e retorna as credenciais IAM ao atacante externo. Este foi o vetor utilizado no famoso breach da Capital One em 2019, onde credenciais AWS foram obtidas via SSRF em um WAF mal configurado. ### Defesa do AWS IMDSv2 A AWS introduziu o **IMDSv2 (Instance Metadata Service v2)** como contramedida. O IMDSv2 exige um token de sessão obtido via PUT antes de qualquer requisição GET, tornando ataques SSRF simples ineficazes: ``` PUT http://169.254.169.254/latest/api/token Header: X-aws-ec2-metadata-token-ttl-seconds: 21600 ``` No entanto, ambientes que não migraram para IMDSv2 (v1 ainda habilitado) permanecem vulneráveis. ## Attack Flow ```mermaid graph TB A[Reconhecimento: Identificar instância cloud alvo] --> B{Vetor de Acesso} B --> C[Acesso Direto: RCE/Container Escape/SSH] B --> D[SSRF em aplicação web pública] C --> E[curl http://169.254.169.254/latest/meta-data/] D --> F[Requisição SSRF → servidor faz chamada interna] E --> G[Coletar credenciais IAM temporárias] F --> G G --> H[Coletar UserData/scripts com segredos hardcoded] H --> I[Exfiltrar AccessKeyId + SecretAccessKey + Token] I --> J{Uso das credenciais} J --> K[Pivotar para outros serviços: S3, RDS, Lambda] J --> L[Escalar privilégios IAM via privilege escalation] J --> M[Persistência: criar novos usuários IAM / roles] K --> N[Exfiltração de dados sensíveis] L --> N M --> N ``` ## Exemplos de Uso ### Capital One Data Breach (2019) O caso mais emblemático de exploração desta técnica em larga escala. Uma atriz de ameaças (Paige Thompson) explorou uma **vulnerabilidade SSRF** em um WAF (Web Application Firewall) da Capital One hospedado na AWS. Através da SSRF, foi possível acessar o endpoint de metadados da instância EC2 e obter credenciais IAM com permissões excessivas. Com essas credenciais, mais de **100 milhões de registros** de clientes foram exfiltrados de buckets S3. O dano estimado superou **$80 milhões** em custos de remediação e multas regulatórias. ### TeamTNT - Campanha de Cryptomining em AWS (2020-2023) O grupo [[g0139-teamtnt|TeamTNT]], especializado em ataques a ambientes cloud e containers, utilizou sistematicamente a Cloud Instance Metadata API como parte de sua cadeia de ataque. Após comprometer instâncias Docker ou Kubernetes expostas, o grupo executava scripts automatizados que acessavam `http://169.254.169.254/latest/meta-data/iam/security-credentials/` para coletar credenciais AWS. As credenciais eram então usadas para criar novas instâncias EC2 para mineração de criptomoedas e para persistência lateral no ambiente cloud. A ferramenta [[s0683-peirates|Peirates]] foi identificada em algumas dessas campanhas para automação da coleta de metadados. ### Hildegard Malware - Kubernetes Cryptomining O malware [[s0601-hildegard|Hildegard]], atribuído ao TeamTNT, combinava evasão de defesas em Kubernetes com coleta ativa de metadados cloud. Após comprometer containers via API Kubernetes exposta, o malware acessava automaticamente a API de metadados para obter tokens de service account e credenciais IAM, expandindo o acesso além do container comprometido. ### Ataques a Pipelines CI/CD (2024) Em 2024, múltiplos incidentes documentados pelo [[sources|Mandiant]] e [[unit42|Unit 42]] descreveram adversários comprometendo pipelines CI/CD (GitHub Actions, GitLab CI, CircleCI) que executam em instâncias cloud. Os runners comprometidos acessavam automaticamente a API de metadados para obter tokens de serviço com amplas permissões, permitindo acesso a repositórios de código, registros de containers e buckets de artefatos de build. ## Detecção ### Estrategias Gerais de Detecção A detecção eficaz desta técnica requer monitoramento em múltiplas camadas: logs de auditoria cloud (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs), logs de rede/VPC Flow Logs, e logs de aplicação para identificar padrões SSRF. **Indicadores de comprometimento (IoCs) comportamentais:** - Requisições ao endpoint `169.254.169.254` provenientes de processos não esperados - Uso de credenciais IAM temporárias de regiões ou endereços IP incomuns - Pico de chamadas à API de metadados em curto período (varredura automatizada) - Chamadas `AssumeRole` ou `GetSessionToken` imediatamente após acesso à metadata API ### Regra Sigma - Acesso Suspeito à Metadata API (Linux) ```yaml title: Suspicious Access to Cloud Instance Metadata API status: experimental logsource: category: process_creation product: linux detection: selection_curl: CommandLine|contains: - '169.254.169.254' - 'metadata.google.internal' - 'metadata/identity/oauth2/token' selection_wget: Image|endswith: - '/curl' - '/wget' - '/python' - '/python3' CommandLine|contains: '169.254.169.254' condition: selection_curl or selection_wget falsepositives: - Ferramentas legítimas de gerenciamento cloud (cloud-init, awscli em scripts autorizados) - Aplicações cloud-native que consultam metadados por design level: high tags: - attack.credential_access - attack.t1552.005 ``` ### Regra Sigma - SSRF para Metadata API (Logs de Aplicação Web) ```yaml title: SSRF Attempt Targeting Cloud Metadata Endpoint status: experimental logsource: category: webserver detection: selection: cs-uri-query|contains: - '169.254.169.254' - 'metadata.google.internal' - 'metadata/identity' - 'latest/meta-data' - 'latest/user-data' condition: selection falsepositives: - Testes de segurança autorizados (pentest) - Scanners de vulnerabilidade legítimos level: high tags: - attack.credential_access - attack.t1552.005 - attack.t1190 ``` ### Detecção via AWS CloudTrail Monitorar eventos CloudTrail específicos que indicam uso de credenciais temporárias obtidas via metadata API: - `GetCallerIdentity` de IPs externos imediatamente após acesso à metadata API - `ListBuckets`, `DescribeInstances` com credenciais temporárias de instância fora do horário normal - `CreateUser`, `AttachUserPolicy` com credenciais de instance profile (indica tentativa de persistência) ## Mitigação | ID | Mitigação | Descrição | |---|-----------|-----------| | M1035 | [[m1035-limit-access-to-resource-over-network\|M1035 - Limit Access to Resource Over Network]] | Restringir quais processos e usuários podem acessar o endpoint de metadados via iptables ou security groups internos. No Linux, usar `iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP` para limitar acesso apenas a processos privilegiados. | | M1042 | [[m1042-disable-or-remove-feature-or-program\|M1042 - Disable or Remove Feature or Program]] | Migrar obrigatoriamente para **IMDSv2** em todas as instâncias AWS. Desabilitar IMDSv1 via configuração da instância: `aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required`. Para novas instâncias, configurar IMDSv2 por padrão via IAM policy ou AWS Organizations SCP. | | M1037 | [[m1037-filter-network-traffic\|M1037 - Filter Network Traffic]] | Implementar regras de firewall de saída em containers e VMs para bloquear requisições diretas ao endereço `169.254.169.254` de processos não autorizados. Em Kubernetes, usar NetworkPolicy para restringir acesso à metadata API apenas para pods que genuinamente necessitam. | **Mitigações adicionais recomendadas:** - **Princípio do menor privilégio IAM:** Instance profiles devem ter apenas as permissões mínimas necessárias. Credenciais de instância com permissões `*` ou `AdministratorAccess` são extremamente perigosas. - **Validação de entrada contra SSRF:** Implementar allowlist de URLs permitidas em aplicações que fazem fetch de URLs externas. Rejeitar requisições para IPs RFC 1918 e link-local (169.254.x.x). - **Monitoramento contínuo de credenciais:** AWS GuardDuty, Microsoft Defender for Cloud e Google Security Command Center possuem detecções nativas para uso anômalo de credenciais de instância. ## Contexto Brasil/LATAM A Cloud Instance Metadata API é uma superfície de ataque crescente no contexto brasileiro, dada a acelerada adoção de infraestrutura cloud por empresas do setor [[financial|financeiro]], [[government|governo]] e [[telecommunications|telecomúnicações]]. **Cenário LATAM específico:** - **Setor Financeiro Brasileiro:** Bancos e fintechs que migraram para AWS/Azure sem fortalecer controles de IAM são alvos prioritários. A combinação de aplicações web legadas com SSRF e instâncias com permissões IAM excessivas cria condições ideais para esta técnica. - **Governo Digital:** Iniciativas de governo digital no Brasil (Gov.br, serviços SERPRO) utilizam infraestrutura cloud crescentemente. Instâncias com dados sensíveis de cidadãos são alvos de alto valor. - **Campanhas de Cryptomining:** O Brasil figura entre os países mais afetados por campanhas de cryptomining direcionadas a clouds, particularmente por grupos como [[g0139-teamtnt|TeamTNT]] que utilizam esta técnica para pivotar de um container comprometido para o ambiente AWS completo. - **Regulatório LGPD:** Breaches via esta técnica que resultem em exfiltração de dados pessoais de brasileiros estão sujeitos à LGPD (Lei Geral de Proteção de Dados), com multas de até 2% do faturamento. **Recomendações específicas para o contexto nacional:** 1. Exigir IMDSv2 em todas as instâncias - implementar via AWS Organizations SCP ou Azure Policy para garantir compliance organizacional 2. Integrar detecção de SSRF nos WAFs brasileiros (F5, Imperva, AWS WAF com managed rules) 3. Incluir teste de SSRF→Metadata API em programas de bug bounty e exercícios de red team ## Referências - [MITRE ATT&CK - T1552.005](https://attack.mitre.org/techniques/T1552/005) - [AWS - Best Practices for Instance Metadata Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) - [Capital One Data Breach - AWS SSRF Incident (2019)](https://krebsonsecurity.com/2019/07/capital-one-data-theft-impacts-106m-people/) - [TeamTNT AWS Credential Theft - Cado Security (2020)](https://www.cadosecurity.com/teamtnt-the-first-crypto-mining-worm-to-steal-aws-credentials/) - [Hildegard Malware Analysis - Unit 42](https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/) - [SSRF in AWS: Exploiting the Metadata Service](https://blog.paloaltonetworks.com/2022/01/cloud-threat-landscape-2021/) - [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] (técnica pai) - [[t1078-valid-accounts|T1078 - Valid Accounts]] (técnica relacionada - reutilização das credenciais obtidas) - [[t1190-exploit-public-facing-application|T1190 - Exploit Public-Facing Application]] (vetor SSRF) --- *Fonte: [MITRE ATT&CK - T1552.005](https://attack.mitre.org/techniques/T1552/005)*