Comandi di Amministrazione Container: Container Administration Command (T1609)

In un esercizio red team autorizzato, l'esplorazione di T1609 parte quasi sempre dalla mappatura delle API esposte. Su Docker, un daemon accessibile via TCP senza TLS risponde su 2375/tcp; su Kubernetes, l'API server ascolta su 6443/tcp e il kubelet su 10250/tcp. Uno scan preliminare con Nmap (open source) identifica rapidamente questi servizi in un range interno.

Contro un Docker daemon esposto, i comandi operativi sono nativi del client Docker (open source):

docker -H tcp://target:2375 ps

docker -H tcp://target:2375 exec -it <container_id> /bin/sh

Per materializzare un breakout, il classico è il deploy di un container privilegiato con montaggio del filesystem host:

docker -H tcp://target:2375 run -v /:/host --privileged -it alpine chroot /host

Su Kubernetes, se il red teamer ottiene un kubeconfig o un service account token, gli strumenti standard sono kubectl (open source) e la libreria client-go. Il pattern base è:

kubectl exec -n -- /bin/bash

kubectl auth can-i --list per enumerare rapidamente i permessi disponibili.

Per emulare scenari realistici documentati nei dati MITRE su TeamTNT e Hildegard, si passa dall'API kubelet quando esposta senza autenticazione. La chiamata all'endpoint run accetta un payload che specifica namespace, pod e comando, permettendo esecuzione senza toccare l'API server. Questo scenario va riprodotto solo in laboratorio isolato.

Strumenti dedicati all'attacco Kubernetes che vale la pena provare in lab:

• Peirates (open source, GitHub) — post-exploitation toolkit specifico per Kubernetes, replica esattamente il comportamento descritto in S0683
• kubeletctl (open source) — client dedicato per interrogare il kubelet, utile per verificare esposizioni della porta 10250
• kube-hunter (open source) — assessment automatico che identifica configurazioni deboli
• Trivy (open source) — scan di immagini e configurazioni cluster per prioritizzare i target

Una catena d'attacco realistica in lab: scan della rete cluster, identificazione di un kubelet non autenticato, enumerazione dei pod tramite l'endpoint pods, iniezione di un comando via run per stabilire una reverse shell verso l'operatore, escalation attraverso montaggio di hostPath su un nuovo pod. Documentare ogni passaggio con timestamp facilita il confronto con la telemetria che il SOC dovrebbe generare.

La detection di T1609 richiede visibilità sui piani di controllo dei container, dove convergono le richieste che portano all'esecuzione. La strategia MITRE DET0065 identifica come fonti primarie i log del daemon Docker (docker:daemon) e dell'API server Kubernetes (kubernetes:apiserver), a cui aggiungere i log del kubelet e l'audit log del cluster.

L'analisi comportamentale deve focalizzarsi su tre segnali. Il primo è la correlazione tra chiamate API exec/run e creazione di processi anomali all'interno del pod: un container che avvia una shell interattiva quando il suo entrypoint è un binario applicativo è un indicatore forte. Il secondo è l'origine della richiesta: le operazioni di amministrazione dovrebbero provenire da IP del control plane, da CI/CD identificabili o da workstation di operatori registrate; una richiesta kubectl exec originata da un pod all'interno del cluster stesso suggerisce lateral movement. Il terzo è la frequenza: picchi improvvisi di exec verso namespace di produzione fuori dalle finestre di manutenzione.

Nell'audit log Kubernetes, gli oggetti da tracciare sono le richieste con verb: create su pods/exec e pods/attach, e le chiamate all'endpoint kubelet pods/{namespace}/{pod}/run. Per Docker, gli eventi rilevanti nel journal del daemon includono container exec_create e container exec_start. Un buon parametro di tuning include la lista degli AuthorizedAdminUsers attesi, il range IP del control plane (SourceIPRange), i namespace autorizzati all'exec (NamespaceScope) e una soglia di frequenza (ExecFrequencyThreshold) basata sul baseline settimanale.

Sul piano del runtime interno al container, Falco (open source) offre regole pronte come Terminal shell in container e Launch Privileged Container che intercettano le syscall execve dentro il namespace del container. Tetragon (open source) fornisce visibilità simile basata su eBPF. L'integrazione con il SIEM va progettata per correlare l'evento API (chi ha chiesto l'exec) con l'evento runtime (quale processo è nato), riducendo drasticamente i falsi positivi.

I principali falsi positivi vengono da operazioni legittime: debug di sviluppatori in ambienti non-prod, job di CI che eseguono kubectl exec per test di integrazione, tool di observability come kubectl-debug. La whitelist deve essere costruita per service account e per namespace, non genericamente per utente.

Sul fronte preventivo, allineandosi con le indicazioni D3FEND, vanno attivati controlli di Credential Hardening (rotazione token service account, TokenRequest API con scadenza breve), Message Authentication sulle chiamate API (mTLS obbligatorio verso kubelet) e Network Isolation del control plane. Disabilitare l'accesso anonimo al kubelet e imporre --authorization-mode=Webhook sono controlli baseline non negoziabili.

L'indagine forense su T1609 si sviluppa su tre livelli: il piano di controllo del cluster, il filesystem del nodo che ospita il container e lo stato interno del container stesso. Ognuno espone artefatti con volatilità e ritenzione diverse, e l'ordine di acquisizione è critico.

Sul control plane Kubernetes, l'artefatto primario è l'audit log dell'API server, tipicamente scritto in JSON secondo la policy definita in audit-policy.yaml. Gli eventi utili contengono i campi user.username, sourceIPs, objectRef.resource=pods, objectRef.subresource=exec e la timestamp stageTimestamp. Ricostruire chi ha invocato exec, verso quale pod e da quale IP fornisce la spina dorsale della timeline. Per il kubelet, i log su systemd (recuperabili con journalctl -u kubelet) registrano le chiamate ricevute; su nodi compromessi da TeamTNT e Hildegard questi log hanno mostrato pattern ripetuti verso l'endpoint run.

Sul nodo, il runtime container lascia tracce nel filesystem sotto /var/lib/docker/containers// per Docker e /var/log/pods/ per Kubernetes. I file <container_id>-json.log contengono lo stdout/stderr dei processi, spesso l'unico posto dove sopravvivono gli output dei comandi exec dopo la terminazione del container. Il file config.v2.json della directory container documenta l'entrypoint originale — utile per rilevare deviazioni come quelle attribuite a Kinsing, che sfruttava entrypoint di container Ubuntu per lanciare shell script.

Quando il container è ancora vivo, l'acquisizione può includere:

• Snapshot del filesystem con docker commit forensic-image seguito da export
• Enumerazione dei processi interni con docker top o crictl inspect
• Dump di memoria del processo target dal namespace del nodo, correlando il PID host con quello containerizzato via /proc//status (campo NSpid)

Su Windows nodes, rilevante per il caso Siloscape, gli artefatti principali sono nel registro eventi Microsoft-Windows-Hyper-V-Compute-Operational e nei log di containerd. Siloscape è documentato per abusare di kubectl locale una volta dentro il cluster, quindi la ricerca del binario kubectl.exe in path non standard e la presenza di file kubeconfig fuori dalle directory utente attese sono segnali forensi rilevanti.

La timeline finale deve correlare: evento audit API server (T0), evento kubelet corrispondente (T0+ms), creazione processo nel container (T0+s), attività di rete in uscita dal container. Fonti esterne come passive DNS e log di egress firewall aiutano a legare l'attività a infrastrutture C2 note. La ritenzione dell'audit log è spesso il collo di bottiglia: in molti cluster è configurata su ore, non giorni, quindi l'acquisizione precoce è essenziale.

Il panorama delle minacce che sfruttano T1609 è dominato da attori motivati finanziariamente e focalizzati su ambienti cloud-native, con TeamTNT come riferimento principale nei dati MITRE.

TeamTNT (G0139) è un gruppo cybercriminale specializzato in attacchi a infrastrutture cloud Linux, particolarmente attivo contro cluster Kubernetes e istanze Docker esposte. La telemetria MITRE lo lega direttamente all'esecuzione di Hildegard attraverso l'API kubelet, specificamente tramite il comando run, e all'esecuzione di comandi su container in esecuzione. Il pattern operativo mostra una preferenza per scan massivi di API Docker esposte su porta 2375 e per kubelet non autenticati, seguiti dal deployment di miner Monero. TeamTNT ha storicamente colpito senza discriminazione geografica, con motivazione puramente economica.

Sul fronte del malware, i quattro campioni collegati alla tecnica raccontano l'evoluzione della minaccia. Kinsing (S0599) è un malware Go che viene deployato via entrypoint di container Ubuntu, eseguendo shell script che scaricano il miner e componenti di persistenza. Rappresenta il pattern "container come vettore", dove l'attaccante non compromette un container esistente ma ne crea uno nuovo con payload malevolo. Hildegard (S0601), associato a TeamTNT, sfrutta invece l'API kubelet e l'esecuzione su container attivi, mostrando conoscenza approfondita dell'architettura Kubernetes.

Siloscape (S0623) merita attenzione particolare: è uno dei primi malware noti a targettizzare specificamente Windows Server containers. Comunica via IRC con l'operatore e invia comandi kubectl verso i cluster vittima, propagandosi lateralmente all'interno dell'ambiente. Il fatto che integri kubectl localmente indica una progettazione dedicata al movimento intra-cluster, non solo all'accesso iniziale.

Peirates (S0683) è categorizzato come tool piuttosto che malware, e riflette la commoditizzazione delle tecniche offensive contro Kubernetes: usa kubectl o chiamate dirette all'API per l'esecuzione dei comandi, ed è utilizzato sia da red team che da attori malevoli che ne riprendono le tecniche.

Il trend osservabile è la convergenza tra crimeware cloud-native (cryptomining) e capacità di lateral movement all'interno dei cluster. La proliferazione di API esposte accidentalmente, unita alla complessità della configurazione RBAC di Kubernetes, mantiene questa tecnica ad alto rendimento per gli attaccanti. Le priorità di threat hunting dovrebbero concentrarsi su: chiamate al kubelet dall'esterno del control plane, deployment di container con entrypoint sospetti da account service non standard, e uso di kubectl exec verso namespace di produzione da sorgenti anomale. La superficie d'attacco cresce parallelamente all'adozione di Kubernetes in produzione, rendendo prevedibile un aumento di famiglie malware dedicate.

MITRE ATT&CK: T1609 (Container Administration Command), TA0002. Gruppi: G0139. Software: S0599, S0601, S0623, S0683. Mitigazioni: M1018, M1026, M1035, M1038, M1042. Detection: DET0065 (AN0177). Framework MITRE D3FEND consultato per controlli difensivi correlati. Per comandi operativi, tool (Falco, Tetragon, kube-hunter, Peirates, kubeletctl, Trivy, Nmap) e artefatti forensi è stata integrata conoscenza professionale di cybersecurity relativa ad ambienti Docker e Kubernetes.