Fuga dal Container: Escape to Host (T1611)

In un ingaggio red team su infrastruttura containerizzata, la simulazione di T1611 parte dalla ricognizione delle capabilities e dei mount disponibili all'interno del container compromesso. Il primo controllo è banale ma rivelatore: cat /proc/self/status | grep CapEff mostra le capabilities effettive; un valore come 0000003fffffffff indica un container --privileged da cui la fuga è quasi immediata.

Lo scenario più classico è il mount della socket Docker. Se /var/run/docker.sock è esposta nel container, basta installare il client Docker (apk add docker-cli su Alpine) ed eseguire un comando che lancia un nuovo container con il filesystem host montato:

docker -H unix:///var/run/docker.sock run -v /:/host -it alpine chroot /host bash

A quel punto si è root sull'host. Un pattern equivalente in Kubernetes sfrutta l'API server: Peirates (open source, repository InGuardians su GitHub) automatizza l'enumerazione dei service account token in /var/run/secrets/kubernetes.io/serviceaccount/token e il lancio di pod con hostPath: / per ottenere reverse shell sul nodo.

Per container privilegiati senza socket Docker, la strada canonica è il caricamento di un modulo kernel oppure l'abuso del cgroup release_agent, tecnica pubblicata da Felix Wilhelm. In alternativa, BOtB (Break out the Box, open source) fornisce un binario Go che testa automaticamente più vettori: CVE-2019-5736 (runc), abuso di /proc/sys/kernel/core_pattern, mount del device host. Il tool è stato integrato nel malware Hildegard, quindi la sua telemetria è realistica per esercizi di detection engineering.

Su Windows Server Containers il vettore documentato è l'abuso dei symbolic link globali via NtSetInformationSymbolicLink, sfruttato da Siloscape per mappare il drive C: dell'host nel container. La PoC richiede l'esecuzione all'interno di un container process-isolated (non Hyper-V) e la creazione di un link che punti a \GLOBAL??\C:.

In ambiente ESXi, la simulazione lab-safe si limita a esercitare le CVE storiche (CVE-2021-21974 su OpenSLP, CVE-2024-37085 su AD group bypass) in un cluster isolato. Il red team deve validare che la segmentazione della management network impedisca l'accesso alla porta 443 del vCenter da workload guest.

Stack di laboratorio consigliato: kind o minikube (open source) per il cluster Kubernetes, Falco (open source) come sensore, kube-bench (open source) per la baseline CIS. Ogni test va documentato con hash del binario, timestamp UTC e nodo target per correlazione con il blue team.

La detection di T1611 richiede visibilità simultanea su tre piani: runtime del container (syscall e process tree), control plane (API server Kubernetes, Docker daemon) e host (processi figli non attribuibili al container runtime). Un singolo log source non è sufficiente perché l'evasione è per definizione una transizione fra domini.

Su Linux, la fonte primaria è auditd:SYSCALL integrato con Falco (open source, CNCF). Le regole Falco pertinenti sono Launch Privileged Container, Mount Launched in Privileged Container e Change thread namespace, quest'ultima cattura l'uso di unshare e setns da processi che non dovrebbero eseguirli. Un'alternativa è Tetragon (open source, Isovalent) basato su eBPF, che permette policy sui syscall keyctl e mount con overhead minimo. Sysmon for Linux (open source) fornisce EventID 1 (ProcessCreate) utile per correlare l'esecuzione di chroot o nsenter da PID appartenenti a cgroup di container.

Sul control plane Kubernetes, l'audit log dell'API server (kubernetes:apiserver nella detection strategy AN0612) va configurato a livello RequestResponse per le risorse pods e pods/exec. Gli indicatori di alert sono: creazione di pod con securityContext.privileged: true, hostPID: true, hostNetwork: true, oppure volumes.hostPath.path che punta a /, /proc, /var/run/docker.sock o /etc. Una query Splunk tipica cerca sourcetype=kube:apiserver "privileged":true correlata con l'utente che ha effettuato la richiesta.

Su Windows, gli EventID rilevanti in WinEventLog:Security sono il 4688 (process creation) con parent appartenente a vmcompute.exe e figli che accedono a percorsi come C:\Windows\System32 dell'host. Sysmon EventID 1 e EventID 11 (FileCreate) su path host sono i marker principali per pattern tipo Siloscape.

Per ESXi, il monitoraggio di esxi:vmkernel deve intercettare vmkload_mod con moduli non presenti nella baseline e operazioni AcquireCredential anomale dal vpxd log.

I falsi positivi più frequenti derivano da tool legittimi: agenti di backup (Velero, Kasten) montano volumi host, sidecar di observability (Datadog, Prometheus node-exporter) richiedono hostPID. La strategia di tuning suggerita da AN0612 include una whitelist di AllowedHostPaths e una soglia PrivilegedContainerThreshold calibrata sull'ambiente. Per Linux, definire un SyscallWhitelist per workload e una TimeWindow di 60 secondi per correlare syscall sospette e process creation sull'host riduce drasticamente il rumore. Kyverno o OPA Gatekeeper (entrambi open source) come admission controller bloccano preventivamente le configurazioni pericolose, generando eventi che il SOC può ingerire come detection primaria.

L'analisi forense di un evento Escape to Host richiede di ricostruire tre timeline parallele e correlarle: container runtime, host OS e orchestratore. La sfida principale è che il container potrebbe essere effimero e distrutto prima dell'acquisizione, quindi la priorità è preservare gli artefatti che sopravvivono alla terminazione.

Su un host Linux/Docker, gli artefatti persistenti chiave sono in /var/lib/docker/containers//: il file config.v2.json contiene HostConfig.Binds, Privileged, CapAdd e SecurityOpt, permettendo di verificare a posteriori se il container era configurato per la fuga (come nel caso Doki, che bindava la root host). Il file -json.log conserva lo stdout/stderr, spesso ricco di output di comandi di ricognizione. Il layer filesystem in /var/lib/docker/overlay2//diff conserva i file scritti dal container fino al successivo prune.

La timeline host va costruita da auditd (se attivo con regole su execve, mount, unshare), dai log del daemon in /var/log/docker.log o via journalctl -u docker, e dai file bash_history dell'utente root per intercettare comandi post-escape come crontab -e o systemctl enable. Il file /etc/crontab e la directory /etc/cron.d/ sono i primi punti di persistenza da verificare, dato che TeamTNT ha usato ripetutamente cron per stabilire foothold sull'host dopo l'evasione.

In ambiente Kubernetes, l'audit log dell'API server (tipicamente /var/log/kubernetes/audit.log o esportato via webhook) è la fonte principale per attribuire l'azione a un service account specifico. Il campo user.username e sourceIPs identificano l'attore, mentre requestObject.spec.volumes e requestObject.spec.securityContext documentano il vettore. Per pod terminati, etcd conserva la storia delle risorse solo per la finestra di retention configurata; è utile controllare eventuali export di backup.

Su Windows Server Containers compromessi da Siloscape, l'artefatto centrale è la traccia in WinEventLog:Sysmon dell'invocazione di NtSetInformationSymbolicLink (visibile come EventID 1 se il processo caricava NTDLL con hooking, altrimenti come EventID 7 sul modulo). Il registro HKLM\SYSTEM\CurrentControlSet\Services\vmcompute e i log Microsoft-Windows-Hyper-V-Compute-Operational danno contesto sulle operazioni container.

Per ESXi, gli artefatti sono in /var/log/vmkernel.log, /var/log/hostd.log e /var/log/vpxa.log. Vanno cercate operazioni AcquireCredential, caricamenti di VIB non firmati e modifiche a /etc/rc.local.d/local.sh frequentemente abusato per persistenza post-escape.

Gli IOC di Hildegard includono l'esecuzione di BOtB con nomi come tshd o xmrig-cc, mentre Peirates lascia tracce nei log API come richieste GET verso /api/v1/namespaces/*/secrets seguite da creazione di pod con hostPath.

Il panorama degli attori che padroneggiano l'escape da container è ristretto ma altamente specializzato, con una netta prevalenza di gruppi motivati finanziariamente e orientati al cloud abuse più che allo spionaggio tradizionale.

TeamTNT (G0139) è l'attore di riferimento per T1611. Il gruppo, attivo dal 2020, ha costruito la propria reputazione automatizzando la compromissione di Docker daemon esposti pubblicamente e cluster Kubernetes mal configurati. La loro tattica documentata da MITRE consiste nel deployare container privilegiati che montano il filesystem della macchina vittima, ottenendo così accesso root all'host per installare cryptominer (principalmente XMRig su Monero), rubare credenziali cloud da ~/.aws/credentials e propagarsi lateralmente ad altri nodi. La motivazione è puramente finanziaria e l'operazione è caratterizzata da automazione worm-like tramite script bash e binari Go compilati staticamente.

Sul fronte del tooling malware, quattro famiglie coprono lo spettro di tecniche di evasione: Doki (S0600) è un backdoor Linux distribuito insieme a container configurati per bindare la directory root dell'host, sfrutta l'algoritmo DGA basato sulla blockchain Dogecoin per la risoluzione C2, rendendo il takedown particolarmente difficile. Hildegard (S0601), attribuita a TeamTNT stessa, integra il tool open source BOtB per testare automaticamente molteplici vettori di escape, dimostrando come framework difensivi finiscano regolarmente riadattati offensivamente. Siloscape (S0623) è il primo malware pubblicamente documentato a colpire specificamente Windows Server Containers, sfruttando la primitiva NtSetInformationSymbolicLink per creare un link globale che mappa il drive C: dell'host nel container: una volta ottenuto l'accesso, il malware apre una backdoor su Tor per rivendere l'accesso al cluster Kubernetes compromesso. Peirates (S0683) è un tool offensivo pubblico di InGuardians, adottato da attori sia legittimi (red team) sia opportunistici per l'enumerazione e l'exploit di service account Kubernetes con permessi eccessivi.

Il pattern geografico dei bersagli è agnostico: TeamTNT colpisce indiscriminatamente cluster esposti su internet, con concentrazione in Nord America, Europa occidentale e Asia orientale semplicemente per densità di deployment cloud. Il tool overlap più significativo è l'uso di BOtB sia in Hildegard sia in engagement red team commerciali, il che complica la triage: una singola detection non basta ad attribuire, serve correlazione con infrastruttura C2 e TTP successive.

Il trend osservabile è la migrazione verso l'abuso di credenziali cloud legittime post-escape (STS token, service account JSON) invece di persistenza tradizionale, riflettendo la maturazione degli ambienti target verso architetture ephemeral dove il container come persistence store non ha più senso. L'evoluzione verso ESXi (documentata dalla stessa nota MITRE) segnala un ampliamento del target set verso hypervisor enterprise, in linea con l'ondata di ransomware ESXi osservata negli anni recenti.

MITRE ATT&CK T1611 (Escape to Host), tattica TA0004. Gruppi: G0139 TeamTNT. Software: S0600 Doki, S0601 Hildegard, S0623 Siloscape, S0683 Peirates. Mitigazioni: M1026, M1038, M1042, M1048, M1051. Detection strategy DET0219 con analytics AN0612-AN0615. Integrata conoscenza professionale su tool difensivi (Falco, Tetragon, Sysmon for Linux, Kyverno, OPA Gatekeeper, kube-bench) e offensivi (BOtB, Peirates) verificati come progetti open source attivi al momento della stesura.