Scoperta di Container e Risorse: Container and Resource Discovery (T1613)

La simulazione di questa tecnica in laboratorio è relativamente semplice e non richiede exploit complessi: basta accesso a un nodo o a un pod con un service account troppo permissivo. L'obiettivo è dimostrare quanto velocemente un attaccante possa ottenere una mappa completa del cluster partendo da un singolo punto d'ingresso.

La catena d'attacco parte dalla discovery locale dei container Docker. Da una shell sul nodo host, l'enumerazione comincia con i comandi più basilari:

docker ps --format "{{.ID}} {{.Image}} {{.Names}} {{.Status}}"

Questo restituisce l'elenco dei container attivi con immagini associate e stato corrente. Per approfondire un target specifico:

docker inspect --format='{{json .Config}}' <container_name>

Il comando docker inspect rivela variabili d'ambiente, volumi montati, porte esposte e configurazione di rete — esattamente il pattern adottato da TeamTNT nelle proprie campagne. Da non trascurare anche i log, che possono contenere credenziali o endpoint interni:

docker logs --tail 100 <container_id>

In ambiente Kubernetes, la discovery si sposta sulle API del cluster. Da un pod compromesso con un service account che dispone di permessi di lettura:

kubectl get pods --all-namespaces -o wide

kubectl get nodes -o jsonpath='{range .items[]}{.metadata.name}{"\t"}{.status.addresses[0].address}{"\n"}{end}'*

kubectl get deployments --all-namespaces

Il tool Peirates (open source) automatizza queste operazioni in contesti di penetration testing Kubernetes. Consente di enumerare pod per namespace, tentare il furto di token dai service account e verificare i permessi disponibili. L'esecuzione in laboratorio richiede un cluster di test — Minikube o Kind sono ideali per questo scopo.

Per replicare il comportamento del malware Hildegard, che utilizzava masscan per individuare kubelet esposti sulla rete locale, si può procedere con:

masscan 10.0.0.0/8 -p10250,10255 --rate 1000 -oJ kubelet_scan.json

La porta 10250 è l'API autenticata del kubelet, la 10255 quella di sola lettura (deprecata ma ancora diffusa). Una volta individuati kubelet esposti, l'attaccante interroga l'endpoint di enumerazione pod direttamente via curl:

curl -sk

Per un assessment strutturato, lo strumento kube-bench (open source) verifica la conformità del cluster ai CIS Kubernetes Benchmark, evidenziando misconfigurazioni che abilitano questa tecnica. Anche kube-hunter (open source) esegue penetration testing automatizzato dei cluster, identificando API esposte e permessi eccessivi.

La detection di questa tecnica si concentra su due sorgenti log fondamentali: i Kubernetes API Server Audit Logs e i Docker Daemon Logs. Senza queste fonti configurate correttamente, la visibilità sull'enumerazione delle risorse è praticamente nulla.

L'audit logging di Kubernetes va configurato con policy di livello almeno Metadata per i verbi get, list e watch sulle risorse pods, nodes, deployments, services e namespaces. Il punto critico non è catturare la singola richiesta — ogni operatore legittimo esegue questi comandi quotidianamente — ma identificare pattern anomali rispetto a una baseline consolidata.

La strategia di tuning si basa su tre parametri chiave. Il primo è la UserAllowList: definire esplicitamente quali service account e ruoli amministrativi sono autorizzati a eseguire operazioni di discovery. Ogni attività proveniente da identità non presenti nella lista diventa immediatamente sospetta. Il secondo è la TimeWindow di correlazione, tipicamente impostata a 10 minuti: se un singolo utente esegue query di enumerazione su più tipologie di risorse in un intervallo ristretto, il comportamento è coerente con una ricognizione sistematica piuttosto che con un'operazione amministrativa puntuale.

Il terzo parametro, il PodQueryThreshold, definisce il numero massimo di richieste di enumerazione accettabili da un singolo utente. Superato questo valore, l'alert scatta segnalando possibile attività di scanning.

Sul versante Docker, il monitoraggio del daemon log deve intercettare invocazioni di docker ps, docker inspect e docker logs provenienti da contesti inattesi. Falco (open source), lo strumento di runtime security per container e Kubernetes, è particolarmente efficace: le sue regole predefinite rilevano chiamate API anomale al socket Docker e accessi non autorizzati ai metadati del cluster.

Per ridurre i falsi positivi, è fondamentale:

• Creare baseline per namespace e per service account, non generiche per cluster
• Escludere i controller interni di Kubernetes (kube-system) dalla correlazione
• Correlare le discovery con eventi precedenti sospetti (es. exec in pod, mount di volumi sensibili)
• Monitorare accessi alla Kubernetes Dashboard da IP o utenti non previsti

I controlli preventivi completano la strategia: la segmentazione di rete (M1030) limita la raggiungibilità delle API, la restrizione dell'accesso alle risorse (M1035) impone TLS obbligatorio e disabilita endpoint non autenticati, e la gestione degli account (M1018) assicura che i RoleBinding siano per namespace e non a livello cluster.

L'analisi forense di un'intrusione in ambiente containerizzato presenta sfide peculiari legate all'effimera natura dei container stessi. Un pod può essere distrutto e ricreato in secondi, portando con sé gli artefatti del filesystem. Per questo motivo la raccolta delle evidenze deve partire dalle fonti persistenti esterne ai container.

La sorgente primaria è il Kubernetes API Server Audit Log. Ogni richiesta all'API — autenticata o meno — viene registrata con timestamp, identità del chiamante, verbo HTTP, risorsa target e risultato. Filtrando per i verbi list e get sulle risorse pods, nodes e deployments, si ricostruisce la sequenza esatta di enumerazione eseguita dall'attaccante. L'identità del service account compromesso diventa il pivot della timeline.

Sul nodo host, i Docker Daemon Logs (tipicamente in /var/log/docker.log o tramite journalctl -u docker) registrano le interazioni con il daemon. Comandi come docker ps e docker inspect, usati da TeamTNT nelle campagne documentate, lasciano tracce nelle chiamate API al socket Docker. Se il nodo utilizza containerd come runtime, i log equivalenti si trovano in journalctl -u containerd.

Per il malware Hildegard, la componente di network scanning con masscan produce artefatti distinti: processi anomali nel process tree del pod compromesso (ricostruibili tramite /proc o log di Falco), connessioni verso le porte 10250 e 10255 visibili nei flow di rete, e potenzialmente output di scan salvati nel filesystem temporaneo del container.

La ricostruzione della timeline segue questa sequenza logica:

1. Accesso iniziale: identificare come l'attaccante ha ottenuto accesso al pod o al nodo (credenziali esposte, vulnerability exploit, misconfiguration)
2. Enumerazione locale: comandi Docker sul nodo host — cercare evidenze nei log del daemon e nella bash_history dell'utente compromesso
3. Enumerazione cluster: chiamate API Kubernetes — correlare i timestamp dell'audit log con l'attività di rete del pod sorgente
4. Network scanning: se presente, tracce di masscan o tool simili nei log di processo e nei flow di rete
5. Azioni successive: movimenti laterali verso pod o nodi scoperti durante l'enumerazione

Per la raccolta forense dei container ancora attivi, docker export consente di catturare il filesystem completo, mentre docker diff evidenzia le modifiche rispetto all'immagine originale. In Kubernetes, kubectl cp permette di estrarre file specifici prima che il pod venga terminato. Il tool kube-forensics (open source) automatizza la creazione di snapshot forensi dei pod in esecuzione.

Il panorama threat intelligence per questa tecnica è dominato da un singolo gruppo con operazioni ben documentate, affiancato da due strumenti software — uno offensivo e uno malevolo — che incarnano approcci diversi all'enumerazione dei container.

TeamTNT (G0139) è il gruppo di riferimento per le operazioni offensive in ambienti cloud e container. Il loro modus operandi combina discovery aggressiva con monetizzazione rapida, tipicamente cryptomining. L'utilizzo di docker ps e docker inspect per mappare i container attivi rappresenta la fase iniziale di una catena che prosegue con il deployment di miner e backdoor. La ricerca di pod Kubernetes sulla rete locale indica una capacità di movimento laterale intra-cluster, passando dall'host compromesso all'enumerazione dell'orchestratore. Il profilo di TeamTNT suggerisce un interesse primario verso ambienti cloud pubblici con configurazioni deboli — Docker API esposti senza autenticazione, kubelet accessibili in rete, service account con permessi eccessivi.

Hildegard (S0601) è il malware attribuito alle operazioni di TeamTNT e rappresenta un'evoluzione significativa: l'uso di masscan per scoprire kubelet sulla rete indica automazione su larga scala, non più singoli comandi manuali. Questo pattern di scanning massivo delle porte 10250/10255 è un indicatore tattico prezioso per correlare incidenti apparentemente scollegati.

Peirates (S0683) opera su un piano diverso: è un tool di penetration testing progettato specificamente per Kubernetes. La sua capacità di enumerare pod per namespace e interagire con i service account lo rende sia strumento legittimo per i red team sia potenziale arma nelle mani di avversari che lo adottano per accelerare la discovery.

Il trend operativo che emerge è chiaro: gli attaccanti stanno investendo nella comprensione degli ambienti cloud-native. La discovery dei container non è fine a sé stessa ma alimenta decisioni tattiche sul tipo di payload da deployare, sulla persistenza da stabilire e sulle risorse computazionali da dirottare. Per il TI officer, il monitoraggio degli indicatori legati a questa tecnica — query API anomale, scanning di porte kubelet, tool come Peirates in ambienti non autorizzati — fornisce un early warning sulle fasi iniziali di compromissioni che tipicamente evolvono verso cryptojacking, furto di credenziali cloud o compromissione della supply chain dei container.

Framework MITRE ATT&CK v16 — T1613 Container and Resource Discovery, TA0007 Discovery. Gruppi: G0139 TeamTNT. Software: S0683 Peirates, S0601 Hildegard. Mitigazioni: M1030, M1035, M1018. Detection: DET0490, AN1352. Tool di detection: Falco, kube-bench, kube-hunter, kube-forensics. Integrato con conoscenza professionale per tool e procedure operative.