Comandi nei Container: Container Administration Command (T1609)

La simulazione di questa tecnica in laboratorio è sorprendentemente diretta, perché gli strumenti necessari sono quelli che già utilizzi per gestire i container. Il punto di partenza è capire quale superficie d'attacco è esposta e con quali permessi.

Scenario Docker — Entrypoint malevolo e exec

Il primo vettore consiste nel deployment di un container con un entrypoint che esegue codice arbitrario. In un ambiente lab con Docker installato, prova a lanciare un container Ubuntu il cui punto di ingresso sia una reverse shell o, più prudentemente, uno script di enumerazione:

docker run -d --name test-t1609 --entrypoint "/bin/sh" ubuntu -c "id; cat /etc/shadow; sleep 3600"

Questo simula esattamente ciò che fa Kinsing, che viene eseguito attraverso un entrypoint di container Ubuntu che lancia script shell. Per il secondo vettore — l'esecuzione su container già attivi — il comando è ancora più immediato:

docker exec -it test-t1609 /bin/bash

Una volta dentro, verifica cosa puoi raggiungere: monta del filesystem host, accesso alla rete, token di servizio Kubernetes eventualmente montati in /var/run/secrets/kubernetes.io/serviceaccount/.

Scenario Kubernetes — API server e kubelet

In un cluster di test (Minikube o kind sono perfetti), simula un attaccante che ha ottenuto credenziali con permessi eccessivi. Il comando canonico per l'esecuzione remota è:

kubectl exec -it -n -- /bin/sh

Per simulare l'interazione diretta con il kubelet — come documentato per Hildegard — puoi interrogare l'endpoint di esecuzione del kubelet sulla porta 10250. Il comando curl va indirizzato all'API del kubelet con il path /run///, passando il comando da eseguire nel corpo della richiesta POST.

Tool dedicati

Peirates (open source) è il tool di penetration testing specifico per Kubernetes citato in questa tecnica. Permette di utilizzare kubectl o l'API Kubernetes direttamente per eseguire comandi nei pod, enumerare secret e tentare escalation. Installalo dal suo repository GitHub e lancialo all'interno di un pod compromesso per verificare cosa un attaccante potrebbe fare con i permessi disponibili.

Per una simulazione più strutturata, kube-hunter (open source) di Aqua Security esegue scansioni del cluster Kubernetes identificando superfici esposte, inclusi kubelet non autenticati. Affiancalo con kubeaudit (open source) per verificare le configurazioni di sicurezza dei pod.

Un aspetto cruciale da testare è la differenza tra un cluster con RBAC ben configurato e uno con permessi wildcard o utenti nel gruppo system:masters. Nel secondo caso, l'esecuzione di comandi è praticamente illimitata e rappresenta lo scenario peggiore.

Il detection di questa tecnica si gioca su due log source fondamentali: i log del daemon Docker e quelli dell'API server Kubernetes. La sfida è che i comandi exec sono operazioni quotidiane per gli sviluppatori e gli SRE, quindi la chiave è il contesto comportamentale, non il singolo evento.

Log source e cosa cercare

Per Docker, i log del daemon registrano ogni invocazione di docker exec. Configura il logging driver in modalità json-file o, meglio, inoltra i log a un SIEM. L'evento chiave è l'API call /containers/{id}/exec — ogni occorrenza va arricchita con l'identità dell'utente che la genera e l'IP sorgente.

Per Kubernetes, l'audit logging dell'API server è imprescindibile. Abilita il profilo di audit almeno a livello RequestResponse per i verbi create sulle risorse pods/exec e pods/attach. I log del kubelet sulla porta 10250 completano il quadro, catturando le esecuzioni dirette che bypassano l'API server — esattamente il vettore usato da Hildegard.

Strategia di alerting con tuning

La detection strategy documentata suggerisce quattro variabili di tuning che trasformano un alert rumoroso in uno azionabile:

• AuthorizedAdminUsers: definisci la lista di account autorizzati a usare exec. Qualsiasi account esterno a questa lista genera un alert ad alta priorità.
• ExecFrequencyThreshold: stabilisci una baseline di frequenza per le operazioni exec. Uno spike improvviso — ad esempio da 5 a 50 exec in un'ora — suggerisce automazione malevola o enumerazione.
• SourceIPRange: le operazioni di management devono provenire dal control plane o da jump host noti. Richieste da IP esterni o da range non previsti meritano investigazione immediata.
• NamespaceScope: identifica i namespace dove le operazioni exec sono normali (es. development, ci-cd) e quelli dove non dovrebbero mai accadere (es. kube-system, production).

Correlazione e catene comportamentali

Un singolo kubectl exec non è un incidente. Diventa sospetto quando si inserisce in una catena: una richiesta API anomala seguita da exec in un pod, seguita da connessioni di rete in uscita verso IP non noti. Correla gli eventi exec con i log di rete del cluster (Calico o Cilium generano flow log utili) e con eventuali mount di volumi sensibili.

Falco (open source), il runtime security tool della CNCF, è particolarmente efficace qui. Fornisce regole predefinite che generano alert quando viene eseguita una shell in un container, quando si accede a file sensibili come /etc/shadow, o quando si osservano connessioni di rete inattese. Integralo con il tuo SIEM per centralizzare gli alert. Tracee (open source) di Aqua Security offre capacità simili basate su eBPF, con granularità sulle syscall.

L'analisi forense di un'intrusione via container administration command richiede un cambio di prospettiva rispetto alla forensics tradizionale: i container sono effimeri, i filesystem sono stratificati e gli artefatti classici di Windows o Linux non sempre esistono nel modo in cui li conosciamo.

Artefatti Docker

Il punto di partenza è il filesystem dell'host che esegue il daemon Docker. La directory /var/lib/docker/ contiene la stratificazione dei layer di ogni container. Per un container sospetto, il layer scrivibile (il cosiddetto upper layer nell'overlay filesystem) conserva tutti i file creati o modificati durante l'esecuzione — inclusi script scaricati, binari droppati e output di comandi.

Recupera la configurazione del container con:

docker inspect

Questo rivela l'entrypoint configurato — cruciale per identificare scenari alla Kinsing, dove il punto di ingresso è uno script shell malevolo. Verifica anche i mount point: un container con accesso al filesystem host (flag -v /:/host) indica un tentativo di escape.

I log del container sono accessibili tramite docker logs oppure direttamente nel filesystem dell'host sotto /var/lib/docker/containers//-json.log. Questi log catturano stdout e stderr di tutto ciò che è stato eseguito, comprese le sessioni docker exec.

Artefatti Kubernetes

In un cluster Kubernetes, i log dell'API server audit sono l'artefatto primario. Ogni chiamata pods/exec viene registrata con timestamp, identità dell'utente, namespace, nome del pod e, se il livello di audit è RequestResponse, anche il comando eseguito. Ricostruisci la sequenza temporale partendo da queste entry.

I log del kubelet sull'host del nodo completano il quadro. Quando TeamTNT ha eseguito Hildegard attraverso il kubelet API run command, gli artefatti si sono materializzati sia nei log del kubelet sia nel filesystem del container. Cerca processi figli anomali generati dal runtime del container (containerd o CRI-O) utilizzando /proc o i log di journalctl -u kubelet.

Ricostruzione della timeline

La sequenza tipica da ricostruire è: autenticazione anomala all'API server (o accesso diretto al kubelet) → creazione di un exec/attach verso un pod → esecuzione di comandi di discovery (id, cat /etc/passwd, enumerazione dei service account token) → download di payload aggiuntivi → comunicazioni C2 in uscita.

Per Siloscape, aggiungi un passaggio ulteriore: il malware invia comandi kubectl attraverso un canale IRC, quindi cerca artefatti di rete che mostrino traffico IRC in uscita dal cluster, e poi correla con esecuzioni kubectl locali che indicano propagazione laterale tra nodi.

Conserva immagini forensi dei nodi host, non solo dei container — i layer overlay, i log del daemon e i log di audit vivono sull'host e sopravvivono alla distruzione del container.

Il panorama threat intelligence per questa tecnica è concentrato ma significativo. Un singolo gruppo APT e quattro software delineano un ecosistema offensivo focalizzato su ambienti cloud-native e Kubernetes, con un trend chiaro verso l'automazione dell'exploitation dei cluster.

TeamTNT (G0139) è il gruppo di riferimento per questa tecnica. Specializzato in attacchi a infrastrutture cloud e container, ha eseguito Hildegard sfruttando il kubelet API run command e lanciando comandi su container in esecuzione. Il modus operandi di TeamTNT è caratterizzato da un approccio opportunistico ma tecnicamente sofisticato: scansione massiva di servizi esposti (Docker API non autenticati, kubelet aperti), compromissione iniziale, e poi monetizzazione tramite cryptomining. L'uso del kubelet come vettore di esecuzione — anziché passare dall'API server Kubernetes — indica una conoscenza approfondita dell'architettura del cluster e la volontà di evitare i controlli RBAC centralizzati.

L'arsenale software racconta la maturazione dell'ecosistema offensivo container-native:

• Hildegard (S0601) rappresenta il malware operativo di TeamTNT, progettato specificamente per l'esecuzione via kubelet e container attivi.
• Kinsing (S0599) adotta un approccio diverso: sfrutta l'entrypoint del container come vettore di esecuzione iniziale, inserendo script shell nella configurazione di deploy di container Ubuntu. Questo indica targeting della supply chain di deployment.
• Siloscape (S0623) introduce un elemento di complessità ulteriore: utilizza canali IRC per inviare comandi kubectl ai cluster compromessi e poi si propaga lateralmente eseguendo kubectl localmente. La combinazione di C2 via IRC e kubectl come strumento di propagazione è un pattern distintivo.
• Peirates (S0683) è l'unico tool offensivo (non malware) del gruppo, concepito per penetration testing Kubernetes. La sua capacità di utilizzare kubectl o l'API Kubernetes per eseguire comandi lo rende uno strumento dual-use: utile per i red team, ma potenzialmente adottabile da attori malevoli.

Pattern emergenti e previsioni

Il pattern geografico è globale: gli attacchi a infrastrutture container colpiscono ovunque esistano cluster mal configurati esposti su Internet. Il denominatore comune non è il settore della vittima ma la superficie esposta — Docker API sulla porta 2375/2376 senza TLS, kubelet sulla porta 10250 senza autenticazione.

L'evoluzione prevedibile segue due direttrici. La prima è l'aumento di malware che sfrutta le API native di Kubernetes per propagarsi, seguendo il modello Siloscape. La seconda è lo spostamento verso supply chain di container image e CI/CD pipeline come vettori di inserimento di entrypoint malevoli, sulla scia dell'approccio di Kinsing. I team di threat intelligence dovrebbero monitorare con attenzione le configurazioni di cluster esposti tramite servizi come Shodan e Censys, tracciando l'evoluzione degli indicatori di compromissione legati a cryptomining e C2 basati su protocolli non convenzionali come IRC.

Framework MITRE ATT&CK: tecnica T1609 (Container Administration Command), tattica TA0002 (Execution). Gruppo: G0139 (TeamTNT). Software: S0683 (Peirates), S0601 (Hildegard), S0623 (Siloscape), S0599 (Kinsing). Mitigazioni: M1018, M1026, M1035, M1038, M1042. Tool di detection e hardening: Falco, Tracee, kube-hunter, kubeaudit. Integrato con conoscenza professionale per tool e procedure operative.