Ricognizione Container: Container and Resource Discovery (T1613)

In un ingaggio red team su ambiente containerizzato, la fase di discovery inizia tipicamente dopo aver ottenuto shell in un pod compromesso o accesso a un token di service account. Il primo controllo è verificare se il container ha visibilità sull'API server: env | grep KUBERNETES rivela immediatamente le variabili KUBERNETES_SERVICE_HOST e KUBERNETES_SERVICE_PORT iniettate automaticamente nei pod.

Con il token di service account montato in /var/run/secrets/kubernetes.io/serviceaccount/token si possono interrogare direttamente le API. Il tool di riferimento in questa fase è kubectl (open source), quando presente nell'immagine, con comandi come kubectl get pods --all-namespaces, kubectl get nodes -o wide e kubectl auth can-i --list per capire quali verbi sono autorizzati sul token corrente.

Quando kubectl non è disponibile, si ricorre a curl contro l'API server passando il bearer token, oppure a strumenti specializzati come Peirates (open source, InGuardians), che automatizza l'enumerazione di pod, secret e service account in un namespace, oltre a fornire moduli di privilege escalation. Altri tool utili in laboratorio sono kube-hunter (open source, Aqua Security) per identificare configurazioni deboli e kubectl-who-can (open source) per mappare i permessi RBAC.

Sul piano Docker puro, replicando la tradecraft di TeamTNT, i comandi base sono docker ps -a per elencare i container, docker inspect <container_id> per estrarre variabili d'ambiente e mount, docker images per l'inventario delle immagini locali e docker network ls per la topologia di rete. Se il socket /var/run/docker.sock è montato dentro il container compromesso, l'attaccante può pilotare il daemon dell'host: uno dei pattern più abusati in scenari di container escape.

Per la scoperta di kubelet esposti sulla rete interna, Hildegard utilizza masscan (open source) contro la porta 10250. In laboratorio si replica con masscan -p10250 10.0.0.0/8 --rate=1000, seguito da richieste HTTP all'endpoint /pods del kubelet per ottenere l'elenco dei container schedulati sul nodo.

Un'attività red team completa combina questa enumerazione con l'ispezione dei log del container (docker logs), che spesso contengono connection string, token cloud e riferimenti a bucket S3 o storage account Azure, informazioni preziose per pianificare il pivot verso il piano di controllo cloud sottostante.

La detection di T1613 si basa principalmente su due sorgenti di log: kubernetes:apiserver (audit log dell'API server) e docker:daemon (log del daemon Docker). Il modello analitico AN1352 del framework MITRE indica di correlare le chiamate API di enumerazione con l'identità del chiamante e il contesto di rete.

Sul lato Kubernetes, l'audit log va configurato con policy che catturino almeno il livello Metadata per le richieste di tipo list e get sulle risorse pods, nodes, namespaces, deployments. Le query di interesse sono verbi list su risorse cluster-wide, particolarmente quando provengono da service account associati a workload applicativi che normalmente non hanno motivo di enumerare l'intero cluster. Una regola SIEM efficace conta le richieste list pods per user in una finestra di 10 minuti (TimeWindow) e alerta quando un singolo service account supera la soglia PodQueryThreshold, ad esempio 20 richieste distinte.

Il tuning fondamentale è la UserAllowList: identità come system:serviceaccount:kube-system:, controller di cluster e account di monitoring (Prometheus, Datadog) generano naturalmente traffico di discovery e vanno esclusi. Tutto ciò che non è in allowlist e interroga risorse cluster-wide merita triage. Un pattern particolarmente sospetto è la sequenza rapida auth can-i --list seguita da enumerazione di secret e pod: indica un attaccante che sta valutando i propri privilegi appena ottenuti.

Sul lato Docker, il daemon logga le chiamate API se configurato con --log-level=info o superiore, oppure via auditd sulla socket Unix. Chiamate GET /containers/json e GET /containers/{id}/json da processi non abituali (shell interattive dentro container, curl da pod applicativi) sono indicatori di ricognizione. L'accesso al socket Docker da dentro un container va considerato un'anomalia grave a prescindere.

Per la scoperta di kubelet via network scan (pattern Hildegard), i log di flow di rete o NSM come Zeek (open source) e Suricata (open source) permettono di rilevare scansioni sulla porta 10250 all'interno del segmento cluster. Regola tipica: connessioni TCP verso 10250 da un singolo source IP verso più di N destinazioni in una finestra breve.

Sul piano preventivo, i controlli D3FEND rilevanti includono Network Traffic Filtering per limitare l'accesso all'API server e Authentication Event Thresholding sui token di service account. La Kubernetes Dashboard, storicamente abusata (caso Tesla 2018), va disabilitata o esposta solo dietro autenticazione forte, monitorando gli accessi anomali al suo endpoint. I falsi positivi principali derivano da tool di backup come Velero (open source), scanner di compliance come kube-bench (open source) e agent di osservabilità: vanno tutti allowlistati per identità e finestra oraria.

L'analisi forense di un incidente T1613 richiede la raccolta congiunta di artefatti dal control plane Kubernetes, dai nodi worker e dai container coinvolti. Il punto di partenza è l'audit log dell'API server, tipicamente in /var/log/kubernetes/audit.log o esportato verso il SIEM. Ogni entry JSON contiene user.username, sourceIPs, verb, objectRef e timestamp: la ricostruzione della timeline parte filtrando le richieste con verbo list e get raggruppate per user.username e correlate per auditID.

Sui nodi worker, il kubelet log (accessibile via journalctl -u kubelet) registra le richieste ricevute sull'endpoint /pods e /metrics. Un pattern Hildegard-like lascia traccia di connessioni entranti sulla porta 10250 da IP interni al cluster, spesso da pod compromessi. La correlazione con la CNI (Calico, Cilium) permette di risalire al pod sorgente della scansione.

A livello container, il filesystem del pod compromesso contiene artefatti utili anche dopo la terminazione se si è preservato lo storage. La directory /var/lib/docker/containers// conserva il file -json.log con stdout/stderr del container: comandi docker eseguiti internamente, output di kubectl, dump di variabili d'ambiente sono qui visibili. Il file config.v2.json dello stesso path documenta i mount, inclusi eventuali bind del socket Docker (indicatore forte di intento di escape) e i token montati.

La history della shell nel container, se conservata (/root/.bash_history, /home//.bash_history*), rivela la sequenza esatta di comandi: la tradecraft di TeamTNT mostra tipicamente docker ps, docker inspect, curl verso metadata endpoint cloud e download di script shell da infrastruttura esterna. La presenza di binari come masscan, pnscan o zgrab nel filesystem del container è indicatore diagnostico.

Sul piano cloud, se il cluster è managed (EKS, GKE, AKS), i log del control plane sono disponibili su CloudTrail (a pagamento, incluso in AWS), Cloud Audit Logs (a pagamento, incluso in GCP) o Azure Monitor (a pagamento). Questi log tracciano anche le chiamate all'API server e permettono di correlare l'attività Kubernetes con eventuali abusi di credenziali IAM associate ai service account tramite IRSA o Workload Identity.

Gli artefatti digitali chiave da preservare per la timeline sono: hash dei binari trovati nel container, snapshot del filesystem del pod, export completo degli audit log per la finestra di interesse, dump della configurazione RBAC al momento dell'incidente (kubectl get clusterrolebindings -o yaml) e lista dei secret accessibili dal service account compromesso. La ricostruzione deve stabilire quali risorse sono state effettivamente enumerate e quali secret o configurazioni sono stati letti, per valutare l'esposizione reale.

L'unico gruppo formalmente associato a T1613 nel corpus MITRE è TeamTNT (G0139), attore criminale a movente finanziario noto per campagne di cryptomining su larga scala rivolte a infrastrutture cloud e containerizzate. Il gruppo ha industrializzato l'abuso di ambienti Docker e Kubernetes mal configurati, con particolare attenzione a socket Docker esposti su Internet (porta 2375/2376 senza TLS) e cluster Kubernetes con API server accessibili pubblicamente.

La tradecraft di TeamTNT in fase di discovery è caratterizzata dall'uso di comandi Docker nativi (docker ps, docker inspect) direttamente dagli script bash di post-exploitation, senza tool custom: un approccio living-off-the-land che riduce la superficie di detection basata su signature. Parallelamente il gruppo scansiona la rete interna del pod compromesso per identificare altri container e pod raggiungibili, propedeutico alla propagazione worm-like che caratterizza le loro campagne.

Sul piano del tooling, due famiglie malware sono mappate esplicitamente sulla tecnica. Hildegard (S0601) è un malware container-aware attribuito a TeamTNT stessa, che utilizza masscan per identificare kubelet esposti sulla porta 10250 e interrogarne l'API non autenticata per ottenere l'elenco dei container schedulati su ciascun nodo. Questa tecnica sfrutta configurazioni kubelet legacy prive di autenticazione anonymous-auth disabilitata, ancora presenti in cluster non aggiornati o installati manualmente.

Peirates (S0683) è un post-exploitation toolkit sviluppato da InGuardians e distribuito come open source, progettato specificamente per operazioni offensive in ambienti Kubernetes. La sua funzione di enumerazione dei pod in un namespace è direttamente rilevante per T1613, e il tool integra anche moduli per l'estrazione di secret, l'escalation via service account e il pivot verso il piano cloud. La sua natura dual-use lo rende presente sia in engagement legittimi che in incidenti reali, complicando l'attribuzione basata sulla sola presenza del binario.

Il pattern emergente dalla threat intelligence disponibile è chiaro: la ricognizione container è oggi appannaggio principalmente di attori criminali orientati al cryptomining, che sfruttano misconfiguration diffuse piuttosto che vulnerabilità zero-day. La superficie d'attacco è alimentata dall'adozione rapida di Kubernetes in produzione senza equivalente maturità nei controlli di sicurezza: API server esposti, RBAC permissivo con cluster-admin concesso liberamente, Dashboard senza autenticazione. Le mitigazioni MITRE M1018 (User Account Management), M1030 (Network Segmentation) e M1035 (Limit Access to Resource Over Network) convergono tutte su un principio operativo: ridurre drasticamente chi può parlare con le API di container e con quale privilegio, e segmentare il piano di controllo dal piano dati applicativo.

MITRE ATT&CK T1613 (Container and Resource Discovery), tattica TA0007. Gruppi: G0139 (TeamTNT). Software: S0601 (Hildegard), S0683 (Peirates). Mitigazioni: M1018, M1030, M1035. Detection: DET0490, modello analitico AN1352. Riferimenti D3FEND per Network Traffic Filtering e Authentication Event Thresholding. Il contenuto integra conoscenza professionale su tool open source (kubectl, kube-hunter, Peirates, masscan, Velero, kube-bench, Zeek, Suricata) e servizi cloud a pagamento (CloudTrail, Cloud Audit Logs, Azure Monitor) per contestualizzare procedure operative e artefatti forensi.