Deploy Container: Distribuzione di Container Malevoli (T1610)
La tecnica T1610 – Deploy Container descrive l'abuso delle API di orchestrazione container per distribuire nuovi workload in ambienti Docker o Kubernetes con finalità offensive. L'avversario sfrutta endpoint come Docker create/start, la Kubernetes Dashboard, Kubeflow o direttamente il kube-apiserver per istanziare container che eseguono payload malevoli oppure che, grazie a configurazioni permissive, aggirano i controlli di sicurezza esistenti.
La tecnica è mappata su due tattiche: TA0002 (Execution), perché il container diventa il vettore d'esecuzione di codice controllato dall'attaccante, e TA0005 (Defense Evasion), quando il nuovo workload viene creato deliberatamente senza policy di rete, senza limiti utente o con flag --privileged per bypassare le difese del cluster. In ambienti Kubernetes, distribuire un pod privilegiato su un nodo specifico apre la strada a Escape to Host (T1611) e all'accesso trasversale agli altri container che condividono il nodo.
I dati MITRE registrano 1 gruppo APT (TeamTNT), 3 famiglie software (Kinsing, Doki, Peirates) e 4 mitigazioni ufficiali. L'impatto operativo tocca cryptomining opportunistico, deployment di reverse shell sui nodi worker e persistenza tramite ReplicaSet o DaemonSet che ridistribuiscono automaticamente il payload su più nodi del cluster.
In un ingaggio red team che coinvolge infrastrutture containerizzate, il primo obiettivo è enumerare gli endpoint di orchestrazione esposti. Un Docker daemon in ascolto senza TLS sulla porta 2375 consente il deploy diretto tramite docker -H tcp://target:2375 run -d --privileged --pid=host --net=host -v /:/host alpine chroot /host sh, ottenendo di fatto una shell sull'host sottostante. Per Kubernetes, il primo controllo è sul kube-apiserver (porta 6443 o 8443) e sulla eventuale Dashboard esposta senza autenticazione.
Con un token di service account compromesso o un kubeconfig recuperato, si verifica il livello di privilegio disponibile:
kubectl auth can-i create pods --all-namespaces
kubectl auth can-i create daemonsets
Se il principal può creare pod, il classico manifest offensivo monta il filesystem del nodo host all'interno di un container privilegiato:
kubectl run pwn --image=alpine --overrides='{"spec":{"hostPID":true,"containers":[{"name":"pwn","image":"alpine","securityContext":{"privileged":true},"volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"name":"host","hostPath":{"path":"/"}}]}}' -it -- sh
Per automatizzare la catena, Peirates (open source) è lo strumento di riferimento nei lab: enumera token, ruoli RBAC e permette il deploy di pod che effettuano mount della root del nodo per generare reverse shell. Comandi come peirates e la voce menu "Attack pod via API server" replicano fedelmente il TTP osservato in vivo.
Altri tool utili in laboratorio includono kube-hunter (open source) di Aqua Security per scoprire misconfigurazioni lato Kubernetes e kdigger (open source) per il context discovery da dentro un pod compromesso. Per l'analisi offline di manifest e RBAC, kubectl-who-can (open source) e rbac-lookup (open source) mappano rapidamente chi può creare pod, deployment o daemonset in ciascun namespace.
Una volta ottenuto foothold sul nodo, la persistenza si realizza distribuendo un DaemonSet mascherato da componente di sistema (es. kube-system/log-collector) che rischedula il payload su qualsiasi nodo aggiunto al cluster. Per il cryptomining opportunistico simulato in test, si può replicare il pattern di TeamTNT distribuendo pod basati su immagini Ubuntu che scaricano XMRig al runtime, senza inserirlo nell'immagine base per eludere lo scan statico dei registry.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.