Fuga dal Container: Escape to Host (T1611)

La simulazione di un container escape in laboratorio richiede un ambiente Docker o Kubernetes dedicato e isolato. Il primo scenario da replicare è il più classico: il bind mount del filesystem root dell'host.

Avvia un container con il filesystem dell'host montato in lettura-scrittura:

docker run -it -v /:/hostfs ubuntu /bin/bash

Da dentro il container, l'intero filesystem host è accessibile sotto /hostfs. Puoi verificare l'accesso con:

ls /hostfs/etc/shadow

Per simulare persistenza, scrivi un cron job direttamente sull'host:

echo ' * * * * root /tmp/payload.sh' > /hostfs/etc/cron.d/backdoor*

Questo replica esattamente il pattern usato da Doki, il cui container veniva configurato per effettuare il bind della directory root dell'host.

Il secondo scenario riguarda i container privilegiati. Lancia un container con flag --privileged:

docker run -it --privileged ubuntu /bin/bash

Da qui puoi montare il disco dell'host direttamente:

mkdir /mnt/host && mount /dev/sda1 /mnt/host

Oppure caricare un modulo kernel malevolo con insmod, dimostrando il livello di controllo che un container privilegiato offre sull'host.

Il terzo scenario coinvolge il Docker socket. Se il socket è montato nel container:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu /bin/bash

Dall'interno puoi creare un nuovo container privilegiato che monta il filesystem host, concatenando l'escape. Strumenti come Peirates (open source) automatizzano questo pattern in ambienti Kubernetes, ottenendo una reverse shell sull'host tramite hostPath mount. BOtB — Break out the Box (open source) — è il tool usato da Hildegard per automatizzare diverse tecniche di escape, incluso l'abuso di capability e l'accesso al metadata service.

Per ambienti Kubernetes, il tool CDK (open source) offre un kit completo per l'enumerazione delle capability del container e il tentativo automatico di escape tramite vari vettori. Un altro strumento utile è deepce (open source), che esegue l'enumerazione dell'ambiente container e identifica possibili percorsi di fuga.

Su Windows, la tecnica di Siloscape è più sofisticata: sfrutta link simbolici globali tramite la chiamata NtSetInformationSymbolicLink per mappare il disco C: dell'host nel container Windows. La simulazione richiede un ambiente Windows Server con container Windows in modalità process isolation.

La detection del container escape si gioca su quattro superfici distinte: container runtime, syscall Linux, eventi Windows e log ESXi. Ogni superficie richiede log source dedicati e soglie calibrate sull'ambiente specifico.

Per i container Docker e Kubernetes, le fonti primarie sono i log del daemon Docker e dell'API server Kubernetes. L'analytic chiave monitora tre segnali: configurazioni anomale di volume mount (in particolare hostPath verso / o /proc), lancio di container privilegiati oltre la soglia attesa, e comandi di amministrazione container che accedono a risorse host. Il parametro di tuning AllowedHostPaths è fondamentale: definisci una lista esplicita di directory permesse per i volumi hostPath. Qualsiasi accesso al di fuori di questi percorsi genera un alert. Parallelamente, stabilisci una PrivilegedContainerThreshold basata sul comportamento normale del tuo ambiente: in molti cluster di produzione, il lancio di container privilegiati è un evento raro e merita attenzione immediata.

In ambienti Kubernetes, implementa Pod Security Standards (in sostituzione delle deprecate Pod Security Policy) per bloccare preventivamente container privilegiati e mount pericolosi. Strumenti come Falco (open source) di Sysdig eccellono nel runtime detection: possono generare alert in tempo reale quando un processo nel container tenta di accedere a risorse host, eseguire syscall anomale o montare filesystem.

Sul fronte Linux, i log di auditd e di Sysmon for Linux (open source, richiede installazione separata) catturano le syscall critiche. Monitora in particolare le chiamate unshare, keyctl e mount originate da processi containerizzati. Una regola auditd efficace:

-a always,exit -F arch=b64 -S unshare -S keyctl -S mount -k container_escape

Il parametro SyscallWhitelist permette di filtrare il rumore: documenta le syscall legittime dei workload containerizzati e genera alert solo sulle deviazioni. La finestra di correlazione TimeWindow di 60 secondi tra una syscall sospetta e la creazione di un processo sull'host fuori dal namespace del container è un indicatore forte di escape riuscito.

Per Windows, Sysmon con la configurazione appropriata cattura la creazione di link simbolici e l'accesso a directory critiche. Il parametro RestrictedHostDirs definisce i percorsi che un container non dovrebbe mai raggiungere: C:\Windows e C:\ProgramData in primo luogo. Un EventCode 1 (Process Create) con working directory fuori dai confini del container merita investigazione.

Per ESXi, i log vmkernel sono l'unica fonte affidabile. Monitora il caricamento di moduli kernel non presenti nella lista AllowedKernelModules, operazioni VM anomale e tentativi di escalation. Correla questi eventi con i log vCenter per avere contesto completo.

La ricostruzione forense di un container escape richiede di correlare artefatti provenienti da due contesti distinti — il container compromesso e l'host bersaglio — e di tracciare il momento esatto in cui il confine tra i due viene violato.

Inizia dall'host. Se l'escape è avvenuto tramite bind mount, cerca nei log Docker la configurazione del container incriminato. Il comando docker inspect (o l'equivalente query ai log del daemon) rivela i mount point configurati. Un container con "Binds": ["/:/hostfs"] o path simili verso la root è un indicatore inequivocabile. Verifica i timestamp di creazione del container nei log del daemon Docker, solitamente in /var/log/docker.log o gestiti da journald.

Sul filesystem host, cerca file creati o modificati con timestamp coerenti con l'attività del container malevolo. I percorsi critici sono quelli tipici della persistenza: /etc/cron.d/, /etc/crontab, /root/.ssh/authorized_keys. Usa il tool mactime del framework The Sleuth Kit (open source) per generare una timeline del filesystem e filtrare per la finestra temporale sospetta. In ambienti dove era attivo auditd, i record SYSCALL con le chiamate mount, unshare e keyctl offrono timestamp precisi e il PID del processo originante.

Per escape tramite container privilegiati, verifica nei log di auditd la presenza di chiamate init_module o finit_module che indicano il caricamento di moduli kernel. Correla il PID con il namespace del container tramite il file /proc/<PID>/cgroup — se il processo risulta in un cgroup Docker ma esegue operazioni kernel-level, hai la prova dell'abuso di privilegi.

In caso di abuso del Docker socket, i log del daemon registrano le chiamate API ricevute. Cerca richieste POST /containers/create con configurazioni privilegiate originate dall'interno di un container esistente. Il pattern è distintivo: un container che crea altri container è quasi sempre anomalo.

Su Windows, il pattern di Siloscape lascia tracce specifiche. Cerca nei log Sysmon eventi EventCode 11 (FileCreate) relativi a link simbolici verso directory host. L'analisi del registro di sistema può rivelare modifiche ai percorsi dei symbolic link globali. I prefissi dei device path nei log di Security (EventCode 4663, Object Access) possono mostrare accessi fuori dal boundary del container.

Per ambienti ESXi, i log vmkernel sono la fonte primaria. Cerca entry relative al caricamento di moduli kernel non autorizzati, messaggi di errore legati a operazioni VM anomale e tentativi di accesso a strutture dati dell'hypervisor. Correla con i log di vCenter per ricostruire la sequenza completa delle operazioni sulla VM compromessa.

Costruisci la timeline incrociando: timestamp di creazione container → syscall/eventi anomali → primo processo sull'host fuori dal namespace container → attività di post-exploitation (persistenza, lateral movement, C2).

Il panorama degli attori che sfruttano il container escape è dominato da un gruppo ben documentato e da un ecosistema di malware specializzato che rivela pattern operativi ricorrenti.

TeamTNT (G0139) è il gruppo più rilevante per questa tecnica. Il loro modus operandi prevede il deployment di container privilegiati che montano il filesystem della macchina vittima, ottenendo accesso diretto all'host per finalità che spaziano dal cryptomining al furto di credenziali cloud. TeamTNT rappresenta l'archetipo dell'attore che opera nell'intersezione tra cloud infrastructure e container exploitation: i loro target primari sono ambienti Docker e Kubernetes esposti, spesso con configurazioni errate.

L'ecosistema software associato a T1611 racconta una storia coerente. Doki (S0600) configura il proprio container per effettuare il bind della directory root dell'host — una tecnica diretta e brutale che non richiede vulnerabilità, solo una configurazione permissiva. Hildegard (S0601) utilizza il tool BOtB per automatizzare il breakout dal container, aggiungendo sofisticazione all'approccio. Peirates (S0683) si specializza nell'ambiente Kubernetes, ottenendo reverse shell sull'host tramite il mount di hostPath. Siloscape (S0623) merita attenzione particolare: è il primo malware documentato che prende di mira container Windows, utilizzando link simbolici globali per mappare il disco dell'host nel container — un approccio completamente diverso dai vettori Linux.

L'analisi di questi tool rivela un pattern evolutivo chiaro. La prima generazione sfrutta configurazioni errate (bind mount, container privilegiati). La seconda genera automazione (BOtB, Peirates). La terza esplora nuove superfici d'attacco (Windows container con Siloscape, ambienti ESXi). Questo suggerisce che la prossima frontiera sarà l'escape da ambienti serverless e da micro-VM come Firecracker o gVisor.

Dal punto di vista geografico, gli attori che utilizzano container escape si concentrano su infrastrutture cloud pubbliche, dove la probabilità di trovare container mal configurati è elevata. Il vettore iniziale più comune è l'esposizione di API Docker o Kubernetes non autenticate su Internet.

Per il threat modeling, considera che la presenza di uno qualsiasi dei quattro software documentati è un indicatore forte di compromissione container. Monitora i feed di threat intelligence per nuove CVE relative a container runtime (containerd, runc, CRI-O) e hypervisor (ESXi), perché queste vulnerabilità vengono weaponizzate rapidamente dagli attori che operano in questo spazio.

Framework MITRE ATT&CK v16 — T1611 (Escape to Host), TA0004 (Privilege Escalation). Gruppo: G0139 (TeamTNT). Software: S0683 (Peirates), S0600 (Doki), S0623 (Siloscape), S0601 (Hildegard). Mitigazioni: M1051, M1038, M1048, M1026, M1042. Analytics: AN0612–AN0615. Integrato con conoscenza professionale per tool e procedure operative.