Abuso CLI e API Container: Container CLI/API (T1059.013)

In un red team engagement contro infrastruttura containerizzata, la prima ricognizione punta a individuare daemon Docker esposti (porta TCP 2375/2376) e API server Kubernetes raggiungibili (6443, 8443, 10250 per kubelet). Strumenti come Nmap (open source) con script docker-version e http-title, o kube-hunter (open source) di Aqua Security, mappano rapidamente la superficie del cluster.

Una volta identificato un endpoint Docker non autenticato, la catena classica prevede l'enumerazione delle immagini e dei container attivi:

docker -H tcp://target:2375 ps -a

docker -H tcp://target:2375 images

docker -H tcp://target:2375 inspect <container_id>

L'output di inspect rivela variabili d'ambiente contenenti credenziali cloud, token e connection string, oltre a mount point che possono indicare filesystem host esposti. Per ottenere esecuzione codice sul nodo host, un pattern documentato consiste nel lanciare un container privilegiato con il filesystem root del nodo montato:

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

Su Kubernetes, con un token di service account estratto da un pod compromesso (leggibile in /var/run/secrets/kubernetes.io/serviceaccount/token), l'operatore red team può interrogare l'API server con kubectl (open source) impostando il token nel kubeconfig, oppure direttamente con curl:

curl -sk -H "Authorization: Bearer $TOKEN" https://kube-api:6443/api/v1/namespaces/default/pods

Se il service account dispone di verbi create o exec su pod, il tester può schedulare un pod con host namespace condivisi o eseguire comandi in pod esistenti:

kubectl exec -it -- /bin/sh

Per automatizzare l'analisi di postura si utilizzano Peirates (open source), pensato specificamente per pentest Kubernetes con moduli per token stealing e privilege escalation, e kubectl-who-can (open source) per enumerare rapidamente chi può eseguire azioni sensibili. Trivy (open source) e kube-bench (open source) verificano rispettivamente vulnerabilità nelle immagini e conformità CIS Benchmark del cluster.

In laboratorio è utile provisionare un cluster kind o minikube (entrambi open source) con configurazioni deliberatamente permissive per esercitarsi su RBAC misconfiguration, pod security policy assenti e socket Docker montati come volume — pattern osservati ripetutamente in ambienti reali.

La detection dell'abuso di CLI e API container ruota attorno alla correlazione tra eventi del control plane e comportamento interno ai container. La detection DET0083 individua l'esecuzione di comandi di orchestrazione (docker exec, kubectl exec) o interazioni API-driven provenienti da host non autorizzati o contesti utente inattesi, tipicamente seguite da scritture su filesystem, escalation o discovery laterale.

Le fonti log fondamentali sono l'audit log dell'API server Kubernetes (configurabile via --audit-policy-file), gli eventi del demone Docker (docker events o log di dockerd in /var/log/docker.log), gli eventi auditd con syscall execve dentro i namespace container, e AWS CloudTrail per cluster EKS. Su cluster gestiti, i log dell'API server confluiscono nativamente in CloudWatch, Azure Monitor o Google Cloud Logging.

Gli alert ad alto valore includono chiamate pods/exec o pods/attach verso l'API server originate da user-agent non presenti nella whitelist di runner CI/CD e tool SRE — il parametro di tuning AuthorizedUserAgents della detection serve proprio a mantenere questa lista. Altri segnali forti sono la creazione di pod con hostPID: true, hostNetwork: true o privileged: true, il montaggio del socket /var/run/docker.sock come volume, e il pull di immagini mai viste prima nel cluster (soglia NewImageThreshold).

Una regola comportamentale efficace correla, entro la finestra TimeWindow di due minuti, tre elementi: chiamata exec all'API, spawn di shell (/bin/sh, bash) come processo figlio di containerd-shim o runc, e attività di rete uscente verso destinazioni non presenti nella baseline del workload. La presenza di sessioni interattive senza TTY (InteractiveSessionExpectation) è ulteriore indicatore in ambienti dove il pattern normale prevede solo esecuzione batch.

Per il piano preventivo, in linea con la mitigazione M1026, il SOC dovrebbe verificare che RBAC Kubernetes segua il principio del minimo privilegio — nessun ClusterRoleBinding verso cluster-admin per service account applicativi — e che il demone Docker sia protetto con TLS mutuo o accessibile solo via SSH. La mitigazione M1038 suggerisce di limitare l'esecuzione di script client-side: policy di admission control come OPA Gatekeeper (open source) o Kyverno (open source) bloccano deployment che violano regole predefinite (privileged, hostPath, immagini da registry non fidati).

I falsi positivi principali provengono da pipeline CI/CD (ArgoCD, Flux, Jenkins agent), operatori come Prometheus e Fluentd che interrogano l'API in modo intensivo, e sessioni di troubleshooting legittimo degli SRE — da qui l'importanza di una baseline accurata degli user-agent e degli identity token attesi.

L'analisi forense di un incidente su ambiente containerizzato deve tenere conto dell'effimeralità dei workload: un container terminato perde il proprio filesystem writable a meno di configurazioni specifiche di persistence. La priorità dell'analista è quindi acquisire rapidamente le evidenze volatili prima che il cluster ricicli le risorse.

Sul piano Kubernetes, l'artefatto primario è l'audit log dell'API server, che registra ogni chiamata con timestamp, user, source IP, verb, resource e response code. Un evento create su pods/exec con response 201 identifica univocamente una sessione di esecuzione remota; l'header User-Agent aiuta a distinguere kubectl ufficiale da client custom o curl. Gli eventi Kubernetes visibili con kubectl get events --all-namespaces forniscono contesto ma vengono conservati per default solo un'ora — vanno esportati subito su storage esterno.

A livello host, i log del demone container (dockerd, containerd, cri-o) elencano operazioni di image pull, container create, exec e stop con relativi ID. La directory /var/lib/docker/containers// contiene config.v2.json con la configurazione completa (comando, environment, mount, capability) e -json.log con stdout/stderr del processo principale. Su nodi con Sysmon for Linux (open source) o auditd configurato per tracciare execve, si ricostruisce l'albero di processi dentro il container correlando PID namespace.

La timeline tipica di un attacco a un daemon Docker esposto mostra: connessione TCP verso 2375, sequenza di GET /containers/json e /images/json per ricognizione, POST /containers/create con payload contenente Privileged: true e Binds: ["/:/host"], avvio del container e POST /exec con comandi chroot /host seguiti da download di payload via curl o wget. Le immagini scaricate da registry esterni lasciano traccia in /var/lib/docker/image/overlay2/repositories.json e nei layer sotto /var/lib/docker/overlay2/.

Per TeamTNT (G0139), le indagini pubbliche hanno documentato pattern ricorrenti: pull di immagini da account Docker Hub controllati dagli attaccanti, deployment di miner XMRig, scansione delle variabili d'ambiente tramite docker inspect per estrarre credenziali AWS e installazione di rootkit sul nodo host montato. L'analista dovrebbe cercare nei log di rete connessioni verso pool di mining noti e nel filesystem host tracce di script shell scritti in /tmp/ o /var/tmp/.

Strumenti utili in fase di risposta includono Falco (open source) per riesaminare eventi runtime se già deployato, kube-forensics (open source) per snapshot dello stato del cluster, e docker save per esportare immagini sospette come tar da analizzare offline con Dive (open source) o Trivy (open source), individuando layer aggiunti con contenuto malevolo.

Il panorama degli attori che sfruttano CLI e API di container è ancora relativamente concentrato ma in crescita, in parallelo con l'adozione di Kubernetes in produzione. Il caso di riferimento documentato è TeamTNT (G0139), gruppo cybercriminale a movente finanziario attivo dal 2019 e specializzato nel targeting di infrastrutture cloud e containerizzate. Il modus operandi tipico prevede scansioni internet-wide alla ricerca di demoni Docker esposti sulla porta 2375, seguite dall'uso dei tool CLI nativi per deployment di container di mining e furto di credenziali cloud dalle variabili d'ambiente.

TeamTNT ha rappresentato per lungo tempo il benchmark per comprendere questa classe di attacchi: le loro campagne hanno mostrato una maturazione progressiva, passando da semplici script bash a toolkit modulari con capacità di worming laterale tra nodi Kubernetes, esfiltrazione di credenziali AWS IAM tramite Instance Metadata Service, e persistence via DaemonSet malevoli. L'uso di immagini ospitate su account Docker Hub legittimi (poi rimossi) ha reso più difficile il blocco basato su registry blacklist.

Il pattern geografico dell'attività registrata contro daemon Docker esposti mostra concentrazione delle vittime in regioni con alta densità di provider cloud (Nord America, Europa occidentale, Asia orientale), riflettendo la distribuzione reale dei workload piuttosto che una preferenza degli attaccanti. La motivazione dominante osservata è economica — cryptomining di Monero — ma la stessa tecnica è direttamente riutilizzabile per obiettivi di spionaggio o ransomware, come dimostrato da episodi successivi in cui operatori ransomware hanno abusato di kubelet esposti per deployment massivi.

L'overlap tecnico tra attori è significativo perché i tool coinvolti sono nativi della piattaforma: chiunque abbia esperienza con kubectl o docker può replicare le tecniche senza sviluppare malware custom. Questo abbassa la barriera d'ingresso e complica l'attribution basata su tooling, spostando il peso su indicatori infrastrutturali (IP di scanning, wallet di mining, chiavi SSH iniettate) e TTP di post-exploitation.

Il trend prospettico indica una crescente attenzione agli ambienti Kubernetes gestiti (EKS, GKE, AKS) dove la superficie non è tanto l'API server pubblico — sempre più raramente esposto — quanto la compromissione di token di service account tramite SSRF applicativo, secret leak in repository Git, o supply chain compromise di immagini base. L'abuso di CLI e API resta il vettore finale di esecuzione una volta ottenuti i privilegi, rendendo la telemetria di controllo del cluster elemento non negoziabile per qualunque threat intelligence program che copra workload cloud-native.

MITRE ATT&CK T1059.013 (Container Administration Command / Container CLI); gruppo G0139 (TeamTNT); mitigazioni M1026 (Privileged Account Management) e M1038 (Execution Prevention); detection DET0083 con analytic AN0233. Documentazione ufficiale Docker Engine API, Kubernetes API Reference e CIS Kubernetes Benchmark. Per la sezione operativa è stata integrata conoscenza professionale su tool open source (kube-hunter, Peirates, Trivy, kube-bench, Falco, OPA Gatekeeper, Kyverno) verificata rispetto ai rispettivi repository pubblici.