Container Malevoli: Deploy Container (T1610)

Deploy Container descrive la capacità di un avversario di creare e avviare container all'interno di un ambiente già compromesso — o accessibile tramite API esposte — per eseguire codice malevolo o aggirare i controlli di sicurezza esistenti. La tecnica si colloca a cavallo di due tattiche: Execution (TA0002), perché il container diventa il veicolo di esecuzione del payload, e Defense Evasion (TA0005), perché un container appena creato può nascere privo delle restrizioni di rete, delle policy di sicurezza e dei vincoli utente applicati al resto dell'infrastruttura.

In ambienti Kubernetes il rischio si amplifica: un container privilegiato può montare il filesystem dell'host, accedere ai namespace di processo e rete del nodo sottostante, e fungere da trampolino per l'escape-to-host. Il deployment può avvenire attraverso le API Docker (create/start), la dashboard Kubernetes, Kubeflow, oppure workload come ReplicaSet e DaemonSet che propagano il container su più nodi simultaneamente.

I dati MITRE documentano 1 gruppo APT, 3 software e 4 mitigazioni associate. Non sono registrate campagne formali, ma il panorama operativo mostra un utilizzo consolidato in attacchi contro infrastrutture cloud e cluster di orchestrazione.

La simulazione di T1610 in laboratorio richiede un ambiente Docker o Kubernetes isolato. L'obiettivo è dimostrare quanto sia semplice, per un attaccante con accesso alle API di orchestrazione, deployare un container malevolo che sfugga ai controlli.

Scenario 1 — Docker API esposta. Se il daemon Docker ascolta su un socket TCP senza autenticazione, l'attaccante può creare un container privilegiato da remoto. In lab, simula l'esposizione del socket e poi lancia:

docker -H tcp://<target>:2375 run -d --privileged --pid=host --net=host -v /:/hostfs alpine sh -c "cat /hostfs/etc/shadow"

Questo comando crea un container Alpine con accesso completo al filesystem host, ai namespace PID e di rete. In un assessment reale è esattamente il pattern usato da malware come Doki e Kinsing, che venivano eseguiti tramite container Ubuntu deployati su host con Docker API non protetta.

Scenario 2 — Kubernetes con credenziali deboli. Utilizzando Peirates (open source), il tool specifico per il pentesting Kubernetes, è possibile simulare il deploy di un pod privilegiato che monta la root del nodo:

peirates

Dal menu interattivo, seleziona l'opzione per deployare un pod con mount del filesystem host. Peirates automatizza la creazione di un pod che monta / del nodo sotto una directory del container e apre una reverse shell, replicando fedelmente la catena d'attacco documentata.

Scenario 3 — kubectl diretto. Se disponi di un kubeconfig con permessi eccessivi, puoi creare un manifest YAML per un pod privilegiato:

kubectl apply -f pod-privileged.yaml

Il manifest deve specificare privileged: true, hostPID: true e un volumeMount verso / dell'host. Dopo il deploy, verifica l'escape con:

kubectl exec -it <pod-name> -- chroot /hostfs /bin/bash

Per il red team è fondamentale anche testare la detection: prima di lanciare questi scenari, assicurati che il blue team abbia visibilità sugli audit log di Kubernetes (kube-apiserver audit policy) e sugli eventi Docker. Strumenti come kube-bench (open source) permettono di verificare se il cluster è configurato secondo i CIS Benchmark prima dell'esercizio, evidenziando le debolezze che un attaccante sfrutterebbe.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo