# T1552.007 - Container API
> [!danger] Técnica de Acesso a Credenciais em Ambientes de Contêiner
> **Tática:** Credential Access · **ID:** T1552.007 · **Plataforma:** Containers
> Adversários exploram APIs de gerenciamento de contêineres (Docker, Kubernetes) para coletar credenciais armazenadas em logs, variáveis de ambiente, secrets e configurações de cluster.
## Descrição
A técnica **Container API** (T1552.007) descreve como adversários coletam credenciais por meio de APIs disponíveis em ambientes de orquestração de contêineres, como o **Docker API** e a **Kubernetes API**. É uma sub-técnica de [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]].
Em ambientes modernos de cloud-native e DevOps, APIs de gerenciamento de contêineres oferecem acesso programático amplo à infraestrutura de execução. Quando expostas sem controles adequados - ou quando acessadas por um adversário com permissões suficientes - essas APIs tornam-se vetores de coleta de credenciais extremamente ricos.
**Docker API:** A API REST do Docker, por padrão, ouve em um socket Unix local (`/var/run/docker.sock`), mas pode ser configurada para ouvir em um socket TCP - muitas vezes sem TLS ou autenticação adequada. Um adversário com acesso ao socket Docker pode enumerar contêineres em execução, extrair logs que contenham credenciais expostas, inspecionar variáveis de ambiente de contêineres ativos, e até executar comandos arbitrários em contêineres privilegiados.
**Kubernetes API:** A API do Kubernetes é o plano de controle central do cluster. Um adversário com acesso suficiente - sejá por comprometimento de uma conta de serviço (Service Account), token de acesso vazado, ou kubeconfig exposto - pode consultar **Secrets** do cluster (que frequentemente armazenam credenciais de banco de dados, chaves de API, certificados TLS e tokens de autenticação), inspecionar configurações de Pods para variáveis de ambiente sensíveis, e recuperar logs de aplicações com dados de autenticação.
O abuso dessas APIs é facilitado pela complexidade do modelo de controle de acesso do Kubernetes (RBAC), onde permissões overprovisionadas são comuns, especialmente em clusters gerenciados por equipes de desenvolvimento que priorizam velocidade sobre segurança. Ferramentas como [[s0683-peirates|Peirates]] foram específicamente desenvolvidas para explorar APIs Kubernetes na fase de pós-comprometimento.
## Como Funciona
### Via Docker API
1. **Acesso ao Socket Docker:** O adversário obtém acesso ao socket `/var/run/docker.sock` - sejá por escape de contêiner, por execução em um Pod com montagem do socket, ou por acesso direto ao host.
2. **Enumeração de Contêineres:** Usando a API REST (`GET /containers/json`), o adversário lista todos os contêineres em execução, incluindo seus nomes, imagens e variáveis de ambiente visíveis.
3. **Extração de Credenciais de Logs:** `GET /containers/{id}/logs` recupera os logs de saída de um contêiner. Aplicações frequentemente registram strings de conexão, tokens temporários e até senhas em logs de debug.
4. **Inspeção de Variáveis de Ambiente:** `GET /containers/{id}/json` retorna a configuração completa do contêiner, incluindo todas as variáveis de ambiente (`Env`), onde segredos frequentemente são injetados por pipelines de CI/CD.
5. **Execução Arbitrária:** Com acesso ao Docker API, o adversário pode criar e executar contêineres privilegiados com acesso ao namespace do host para escalar privilégios.
### Via Kubernetes API
1. **Obtenção de Credenciais Iniciais:** Token de Service Account (montado automaticamente em `/var/run/secrets/kubernetes.io/serviceaccount/token`), kubeconfig exposto em variáveis de ambiente, ou token roubado de outro Pod.
2. **Enumeração de Secrets:** `GET /api/v1/namespaces/{ns}/secrets` - Secrets Kubernetes são codificados em base64 (não criptografados por padrão no etcd) e contêm credenciais de banco de dados, chaves de API externas, certificados TLS, tokens OAuth e Docker registry credentials.
3. **Leitura de ConfigMaps:** `GET /api/v1/namespaces/{ns}/configmaps` - ConfigMaps frequentemente armazenam configurações que incluem URLs com credenciais embutidas.
4. **Acesso ao etcd:** O adversário com acesso direto ao etcd (banco de dados do cluster) pode extrair todos os Secrets do cluster diretamente, sem passar pelo RBAC da API.
5. **Coleta de Logs de Pods:** `GET /api/v1/namespaces/{ns}/pods/{name}/log` - Logs de aplicações com dados sensíveis.
## Attack Flow
```mermaid
graph TB
A["Acesso Inicial<br/>(Escape de Contêiner / Token Vazado)"] --> B{"Vetor de API"}
B --> C["Docker API<br/>(Socket /var/run/docker.sock)"]
B --> D["Kubernetes API<br/>(Token de Service Account)"]
C --> E["Enumerar Contêineres<br/>GET /containers/json"]
C --> F["Extrair Logs<br/>GET /containers/id/logs"]
C --> G["Inspecionar Env Vars<br/>GET /containers/id/json"]
D --> H["Listar Secrets<br/>GET /api/v1/.../secrets"]
D --> I["Ler ConfigMaps<br/>GET /api/v1/.../configmaps"]
D --> J["Logs de Pods<br/>GET .../pods/name/log"]
E --> K["Credenciais Identificadas<br/>(DB, API Keys, Tokens)"]
F --> K
G --> K
H --> K
I --> K
J --> K
K --> L["Decodificação e Análise<br/>(base64 decode, grep)"]
L --> M["Credential Access Completo"]
M --> N["Movimento Lateral<br/>para Sistemas Conectados"]
M --> O["Acesso a Serviços Cloud<br/>(AWS, GCP, Azure)"]
```
## Exemplos de Uso
### Exploração de Docker Socket Exposto
Um adversário que compromete um contêiner com o socket Docker montado (`-v /var/run/docker.sock:/var/run/docker.sock`) pode usar a API para listar variáveis de ambiente de todos os contêineres em execução no host. Isso é especialmente perigoso em ambientes onde o pattern de injeção de segredos via variáveis de ambiente é utilizado:
```
GET http://localhost/containers/{id}/json
→ "Env": ["DATABASE_URL=postgres://admin:S3cr3tP@
[email protected]:5432/prod", "AWS_SECRET_ACCESS_KEY=..."]
```
### Abuso de Service Account com RBAC Overprovisionado
Em clusters Kubernetes mal configurados, um Pod comprometido com um Service Account com permissões `cluster-admin` ou com acesso de leitura a Secrets pode executar:
```
GET https://kubernetes.default.svc/api/v1/secrets
→ Lista completa de todos os Secrets de todos os namespaces
```
Cada Secret retornado contém dados codificados em base64 que, quando decodificados, revelam credenciais completas.
### Uso do Peirates
A ferramenta [[s0683-peirates|Peirates]] automatiza o processo de reconhecimento e coleta de credenciais em clusters Kubernetes. Ela enumera automaticamente Secrets acessíveis, tokens de Service Accounts de outros namespaces, e credenciais de cloud provider armazenadas no cluster.
### Comprometimento via etcd Exposto
Clusters Kubernetes com o etcd exposto sem autenticação mTLS permitem leitura direta de todos os Secrets sem passar pelo RBAC da API. Este vetor foi explorado em ataques a clusters mal configurados para extrair credenciais de produção inteiras.
## Detecção
### Monitoramento de Auditoria da API Kubernetes
```yaml
title: Kubernetes Secrets Mass Enumeration
id: 4f7a9c12-8b3e-4d5a-9c1f-2e6b8d4a7c3f
status: experimental
description: Detecta enumeração em massa de Secrets via Kubernetes API
logsource:
category: kubernetes_audit
product: kubernetes
detection:
selection:
verb: list
resource: secrets
objectRef.resource: secrets
filter_system:
user.username|startswith:
- 'system:serviceaccount:kube-system'
condition: selection and not filter_system
level: high
tags:
- attack.credential_access
- attack.t1552.007
falsepositives:
- Ferramentas de gestão de segredos legítimas (Vault Agent, External Secrets Operator)
- Pipelines de CI/CD com acesso autorizado
```
### Acesso Anômalo ao Docker API
```yaml
title: Docker API Credential Harvesting Attempt
id: 2c8f5a1d-7e4b-3c9a-6f2d-5b8e1a4c7d9f
status: experimental
description: Detecta consultas ao Docker API para extração de variáveis de ambiente ou logs
logsource:
category: webserver
product: docker
detection:
selection_logs:
request|contains: '/containers/'
request|endswith:
- '/logs'
- '/json'
selection_env:
response|contains:
- 'PASSWORD'
- 'SECRET'
- 'KEY'
- 'TOKEN'
condition: selection_logs
level: medium
tags:
- attack.credential_access
- attack.t1552.007
```
### Fontes de Dados Recomendadas
| Fonte | O Que Monitorar |
|-------|-----------------|
| Kubernetes Audit Logs | Operações `list`/`get` em `secrets`, `configmaps` - especialmente fora de horário ou por SAs incomuns |
| Docker Daemon Logs | Requisições à API para `/containers/{id}/json` e `/containers/{id}/logs` |
| Network Traffic | Tráfego de saída não esperado de Pods para endpoints externos após acesso a Secrets |
| RBAC Analysis | Service Accounts com permissões de leitura desnecessárias em Secrets |
| etcd Access Logs | Qualquer acesso direto ao etcd fora do API Server |
## Mitigação
| ID | Mitigação | Descrição |
|----|-----------|-----------|
| [[m1026-privileged-account-management\|M1026]] | Privileged Account Management | Aplicar RBAC granular no Kubernetes: nenhum Service Account deve ter acesso a `secrets` de outros namespaces. Desabilitar automontagem de Service Account tokens em Pods que não precisam (`automountServiceAccountToken: false`). |
| [[m1035-limit-access-to-resource-over-network\|M1035]] | Limit Access to Resource Over Network | Restringir acesso à API do Kubernetes e ao Docker API por rede. O Docker socket nunca deve ser exposto via TCP sem TLS mútuo. A API do Kubernetes deve estar atrás de VPN ou com Network Policies restritivas. |
| [[m1030-network-segmentation\|M1030]] | Network Segmentation | Implementar Network Policies no Kubernetes para isolar namespaces. Pods de produção não devem ter comunicação direta com a API do Kubernetes. Segmentar o etcd em uma rede dedicada. |
| [[m1018-user-account-management\|M1018]] | User Account Management | Auditar regularmente todas as Service Accounts e RBAC bindings. Remover permissões não utilizadas. Implementar ferramentas como `rbac-police` ou `audit2rbac` para detectar overprovisionamento. |
### Controles Adicionais
- **Nunca montar o Docker socket em contêineres:** O pattern `-v /var/run/docker.sock:/var/run/docker.sock` é extremamente perigoso e deve ser proibido por policy.
- **Usar Kubernetes Secrets com criptografia em repouso:** Habilitar `EncryptionConfiguration` no API Server para criptografar Secrets no etcd.
- **Ferramentas de gestão de segredos:** Usar HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault em vez de Kubernetes Secrets nativos para dados altamente sensíveis.
- **Auditoria de API habilitada:** Habilitar Kubernetes Audit Policy com regras para registrar todos os acessos a `secrets`.
- **Proteção do etcd:** etcd deve ter TLS mútuo habilitado e acesso restrito exclusivamente ao API Server do Kubernetes.
## Contexto Brasil/LATAM
O abuso de APIs de contêiner é uma ameaça crescente para organizações brasileiras que aceleraram a adoção de Kubernetes e Docker em suas jornadas de transformação digital:
**Adoção Cloud-Native no Brasil:** O mercado brasileiro de cloud cresce consistentemente, com grandes bancos, fintechs e varejistas migrando cargas críticas para Kubernetes em AWS, GCP e Azure. A velocidade da adoção frequentemente supera a maturidade dos controles de segurança.
**Fintechs e Open Finance:** O ecossistema de Open Finance brasileiro (regulado pelo Banco Central) utiliza APIs e microsserviços extensivamente. Credenciais de APIs de parceiros armazenadas em Secrets Kubernetes são alvos de alto valor para atores financeiramente motivados.
**Ambientes DevOps com Baixa Maturidade de Segurança:** Em muitas organizações brasileiras de médio porte, clusters Kubernetes são gerenciados por equipes de desenvolvimento sem treinamento específico em segurança de containers. RBAC overprovisionado e Secrets com credenciais de produção expostos são padrões comuns.
**Grupos de Ransomware:** Grupos como [[lockbit|LockBit]] e operadores de ransomware com atuação no Brasil utilizam técnicas de coleta de credenciais em ambientes containerizados para escalar o impacto de suas operações - comprometendo bancos de dados e sistemas SaaS acessíveis via credenciais coletadas.
**Recomendação para Equipes de Segurança Brasileiras:** Incluir auditoria de RBAC Kubernetes e verificação de Secrets expostos nos processos de revisão de segurança de cloud. Ferramentas como `kube-bench`, `checkov` e `kubeaudit` devem ser parte do pipeline de CI/CD.
## Referências
- [MITRE ATT&CK - T1552.007: Container API](https://attack.mitre.org/techniques/T1552/007)
- [Kubernetes Security Best Practices - Secrets Management](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)
- [Docker Security - Protecting the Docker Daemon Socket](https://docs.docker.com/engine/security/protect-access/)
- [Trail of Bits - Kubernetes Security Guide](https://github.com/trailofbits/audit-kubernetes)
- [Peirates - Kubernetes Penetration Testing Tool](https://github.com/inguardians/peirates)
- [[s0683-peirates|Peirates]] - Ferramenta de exploração de APIs Kubernetes
- [[t1552-unsecured-credentials|T1552 - Unsecured Credentials]] - Técnica pai
- [[m1026-privileged-account-management|M1026 - Privileged Account Management]] - Mitigação principal
- [[m1030-network-segmentation|M1030 - Network Segmentation]] - Segmentação de rede
- [[t1610-deploy-container|T1610 - Deploy Container]] - Técnica frequentemente combinada
- [[t1613-container-and-resource-discovery|T1613 - Container and Resource Discovery]] - Reconhecimento em ambientes de contêiner
---
*Fonte: [MITRE ATT&CK - T1552.007](https://attack.mitre.org/techniques/T1552/007)*