Container Escape: Escape to Host (T1611)

Per testare la sicurezza dei tuoi container, inizia verificando la presenza di mount pericolosi. Il comando docker inspect [container_id] | grep -A 10 Mounts rivela rapidamente se il filesystem host è esposto. Un container privilegiato rappresenta la via più diretta per l'escape.

Crea un container di test con accesso privilegiato usando: docker run -it --privileged --pid=host ubuntu:latest /bin/bash

Una volta dentro, puoi accedere direttamente ai processi host tramite /proc/1/root. Questo percorso bypassa completamente l'isolamento del container. Per un approccio più sofisticato, sfrutta il socket Docker montato:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:latest

All'interno di questo container, installa il client Docker e potrai controllare l'intero daemon host. Il comando docker run -it -v /:/host ubuntu:latest chroot /host ti darà accesso root completo al sistema.

Su sistemi Windows, la tecnica di Siloscape utilizza link simbolici globali. Puoi replicarla creando un link che punta al disco C: dell'host attraverso la chiamata a NtSetInformationSymbolicLink. Questo richiede privilegi elevati nel container ma permette accesso diretto al filesystem Windows.

Per ambienti Kubernetes, Peirates dimostra come sfruttare hostPath mal configurati. Se un pod monta /, hai accesso completo. Verifica con: kubectl get pods -o json | jq '.items[].spec.volumes'

Gli escape tramite syscall rappresentano tecniche avanzate. Il comando unshare -m -r /bin/bash può creare un nuovo namespace con privilegi root. Combina questo con nsenter -t 1 -m -u -n -i sh per entrare nel namespace del processo init dell'host.

La detection efficace richiede visibilità su più livelli dell'infrastruttura. Configura il tuo SIEM per correlare eventi dal daemon Docker, dall'API server Kubernetes e dai log di sistema dell'host.

Per Docker, monitora il file /var/log/docker/daemon.log cercando pattern di mount sospetti. Un alert dovrebbe scattare quando vedi mount di / o /proc nell'host. La creazione di container con flag --privileged fuori dagli orari di manutenzione rappresenta un forte indicatore di compromissione.

Su Kubernetes, l'apiserver log rivela tentativi di creare pod con hostPath pericolosi. Definisci una AllowedHostPaths whitelist che includa solo directory necessarie come /var/log per la raccolta logs. Qualsiasi tentativo di montare path esterni genera un alert ad alta priorità.

Il monitoraggio delle syscall tramite auditd su Linux cattura tentativi di escape sofisticati. Configura regole per unshare, keyctl e mount quando provengono da processi containerizzati: -a always,exit -F arch=b64 -S unshare -F key=container_escape

Per ridurre i falsi positivi, implementa una SyscallWhitelist basata sul comportamento normale delle tue applicazioni. Molti container legittimi non dovrebbero mai invocare queste syscall. Definisci una TimeWindow di 60 secondi per correlare syscall sospette con successiva attività anomala sull'host.

Su Windows, EventCode 4688 (Process Creation) combinato con Sysmon Event ID 1 identifica processi che accedono a directory host da dentro un container. Paths critici come C:\Windows o C:\ProgramData non dovrebbero mai essere accessibili da container isolati.

L'analisi forense di un container escape richiede la ricostruzione precisa della catena di eventi. Inizia dal punto di ingresso nel container compromesso, tipicamente visibile nei log di autenticazione o nell'history dei comandi.

Su Linux, /var/log/audit/audit.log contiene tracce delle syscall utilizzate per l'escape. Cerca timestamp di chiamate a unshare seguite da creazione di processi con namespace differenti. Il file /proc/[pid]/ns/ mostra i namespace di ogni processo - confrontali per identificare anomalie.

La presenza di Doki lascia tracce caratteristiche: container configurati per montare l'intero filesystem root. Verifica /var/lib/docker/containers/[id]/config.v2.json per mount point sospetti creati durante il deployment iniziale.

Hildegard utilizza il tool BOtB che genera pattern specifici nei log. Cerca referenze a /proc/self/exe e tentativi di manipolazione dei cgroups in /sys/fs/cgroup. La timeline mostrerà tipicamente: accesso iniziale al container, download di tool aggiuntivi, escape attempt, e infine esecuzione di comandi sull'host.

Per Windows e Siloscape, l'analisi del registro eventi rivela la creazione di symbolic link globali. Event ID 4656 (Handle Request) con oggetti che puntano a *\Global* seguito da accessi a *C:* indicano un escape riuscito. La timeline includerà chiamate a NtSetInformationSymbolicLink visibili in ETW traces.

Su ESXi, /var/log/vmkernel.log registra anomalie nell'hypervisor. Module loading inaspettati o operazioni VM non autorizzate precedono tipicamente l'escape. Correla questi eventi con modifiche ai file di configurazione delle VM in /vmfs/volumes/.

TeamTNT rappresenta l'attore principale nell'ecosistema container escape. Questo gruppo si distingue per l'uso sistematico di container privilegiati che montano il filesystem delle vittime. La loro metodologia segue pattern prevedibili: scanning massivo per Docker API esposti, deployment di cryptominer, lateral movement attraverso credenziali rubate dall'host.

Il malware Hildegard mostra sofisticazione superiore con l'integrazione del tool BOtB. Questo indica evoluzione dalle tecniche base verso approcci automatizzati. La presenza di Hildegard suggerisce attaccanti con obiettivi oltre il cryptomining - possibile spionaggio industriale o staging per attacchi supply chain.

Siloscape rivela focus specifico su ambienti Windows containerizzati. L'uso di symbolic link globali attraverso NtSetInformationSymbolicLink dimostra conoscenza approfondita delle API Windows. Attori che deployano Siloscape probabilmente mirano a compromettere infrastrutture enterprise Windows-based.

Doki utilizza l'approccio più diretto: bind mount della root directory. Questa semplicità suggerisce operatori meno sofisticati o campagne di massa. Tuttavia, l'efficacia rimane alta contro ambienti mal configurati.

L'overlap nei tool suggerisce possibile condivisione nel underground o sviluppatori comuni. La progressione da mount semplici (Doki) a tecniche syscall avanzate (Hildegard) indica maturazione dell'ecosistema criminale. Prevedi evoluzione verso: exploit di vulnerabilità zero-day in runtime container, abuso di feature legittime come eBPF, targeting specifico di orchestratori oltre Kubernetes.

MITRE ATT&CK framework documenta dettagliatamente la tecnica T1611 con focus su metodologie di escape osservate in-the-wild. Le campagne TeamTNT forniscono case study reali per validare l'efficacia delle mitigazioni proposte. Risorse aggiuntive includono Docker Security Best Practices e Kubernetes Pod Security Standards per implementation guidance specifica.