# T1613 - Descoberta de Contêineres e Recursos ## Descrição Em ambientes de contêineres, adversários buscam ativamente mapear a infraestrutura disponível antes de avançar para etapas posteriores do ataque. Isso inclui enumerar contêineres em execução, imagens disponíveis, pods, nós do cluster, deployments e o estado geral da orquestração - sejá via Docker, Kubernetes ou plataformas de nuvem que os gerenciam. Essa enumeração pode ser realizada por meio de APIs expostas (como a API do Kubernetes na porta 8443 ou o socket Docker em `/var/run/docker.sock`), dashboards web como o Kubernetes Dashboard, ou ferramentas de linha de comando como `kubectl`, `docker ps` e `crictl`. Logs de contêiner também são uma fonte valiosa de reconhecimento passivo, revelando variáveis de ambiente, configurações de serviço e até credenciais armazenadas de forma insegura. O objetivo principal não é apenas catalogar o que existe, mas entender o escopo do ambiente comprometido: quantos pods rodam, quais serviços estão expostos internamente, se há acesso a secrets do Kubernetes, e quais caminhos de movimentação lateral estão disponíveis dentro do cluster. Grupos como [[g0139-teamtnt|TeamTNT]] são conhecidos por automatizar inteiramente essa fase, usando scripts que consultam APIs de metadados de nuvem e APIs de orquestração em sequência. **Contexto Brasil/LATAM:** A adoção acelerada de Kubernetes e Docker em ambientes de fintech, e-commerce e governo digital no Brasil torna essa técnica cada vez mais relevante. Muitas organizações migram para contêineres sem adaptar seus modelos de segurança - expondo APIs de orquestração sem autenticação adequada ou deixando o socket Docker acessível a processos com excesso de privilégios. O grupo [[g0139-teamtnt|TeamTNT]] tem histórico de campanhas que visam específicamente instâncias Docker e Kubernetes mal configuradas em provedores de nuvem utilizados na região, incluindo AWS e GCP. ## Attack Flow ```mermaid graph TB A[Acesso Inicial ao Contêiner] --> B[**T1613 - Descoberta de Contêineres**] B --> C[T1552 - Coleta de Credenciais] B --> D[T1610 - Deploy de Contêiner Malicioso] C --> E[Movimentação Lateral no Cluster] ``` ## Como Funciona 1. **Preparação:** O adversário obtém acesso a um contêiner - sejá por exploração de vulnerabilidade em aplicação, imagem comprometida no supply chain ou credenciais vazadas de registry. Com esse ponto de entrada, inicia o reconhecimento do ambiente de orquestração. 2. **Execução:** São consultadas as APIs disponíveis - API do Kubernetes via `kubectl get pods --all-namespaces`, API do Docker via socket local (`docker ps`, `docker images`), ou diretamente via HTTP contra `http://localhost:8080` (API sem autenticação). O adversário também verifica variáveis de ambiente em busca de tokens de service account e inspeciona arquivos em `/var/run/secrets/kubernetes.io/serviceaccount/`. 3. **Pós-execução:** Com o mapa do cluster em mãos, o adversário identifica pods com permissões elevadas, serviços de interesse (bancos de dados, message brokers, ferramentas de CI/CD), possibilidade de escalonamento de privilégios via RBAC mal configurado, e caminhos para escapar do contêiner para o nó host. **Exemplo:** ```bash # Artefato detectável: chamada à API do Kubernetes via service account montado # Este comando gera eventos nos logs de auditoria do kube-apiserver curl -sk \ -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ https://kubernetes.default.svc/api/v1/pods \ | grep -o '"name":"[^"]*"' ``` ## Detecção **Fontes de dados:** Logs de auditoria do kube-apiserver (eventos `list`/`get` em recursos `pods`, `nodes`, `secrets`), logs do Docker daemon, monitoramento de chamadas ao socket `/var/run/docker.sock`, alertas de ferramentas de runtime security como Falco. ```yaml title: Kubernetes API Enumeration from Pod id: 7e3c1a2b-4f89-4d01-bc23-9a8f5e6d7c10 status: experimental description: Detecta enumeração de recursos do cluster Kubernetes a partir de um pod comprometido via service account token logsource: category: kubernetes.audit product: kubernetes detection: selection: objectRef.resource: - pods - nodes - secrets - deployments verb: - list - get user.groups|contains: "system:serviceaccounts" condition: selection falsepositives: - Ferramentas de monitoramento legítimas (Prometheus, Datadog agent) - Operações de CI/CD automatizadas level: medium tags: - attack.discovery - attack.t1613 ``` ## Mitigação | Mitigação | Recomendação Prática | |-----------|---------------------| | [[m1030-network-segmentation\|M1030 - Network Segmentation]] | Restringir acesso à API do Kubernetes por Network Policies; bloquear acesso direto ao kube-apiserver a partir de pods de aplicação | | [[m1035-limit-access-to-resource-over-network\|M1035 - Limit Access to Resource Over Network]] | Desabilitar o endpoint HTTP não autenticado (porta 8080); garantir que o socket Docker não sejá montado em contêineres de aplicação | | [[m1018-user-account-management\|M1018 - User Account Management]] | Aplicar RBAC com princípio do menor privilégio; service accounts de aplicação não devem ter permissão `list` em recursos sensíveis como `pods`, `secrets` ou `nodes` | ## Referências *Fonte: [MITRE ATT&CK - T1613](https://attack.mitre.org/techniques/T1613)*