Discovery nei Container: Container and Resource Discovery (T1613)

La simulazione di questa tecnica inizia sempre con i comandi base di enumerazione Docker. Il comando docker ps rivela immediatamente tutti i container in esecuzione, mentre docker inspect [container_name] fornisce dettagli granulari su configurazioni e variabili d'ambiente.

TeamTNT, gruppo specializzato in attacchi a infrastrutture cloud, combina questi comandi con scansioni di rete per identificare kubelet esposti. La sequenza tipica prevede:

docker ps -a
docker images
docker network ls

Per ambienti Kubernetes, l'approccio si evolve con query API più sofisticate. Il tool Peirates automatizza l'enumerazione di pod in namespace specifici, mentre Hildegard utilizza masscan per identificare kubelet API esposte su reti locali.

La ricognizione Kubernetes segue questo pattern:

kubectl get pods --all-namespaces
kubectl get nodes -o wide
kubectl describe deployments

Un attaccante esperto combina sempre discovery automatizzata con analisi manuale dei log Docker. I log spesso contengono informazioni sensibili sulla configurazione dell'ambiente e sul cloud provider utilizzato. La dashboard Kubernetes, se accessibile, rappresenta una miniera d'oro di informazioni visuali sull'intera infrastruttura.

Per simulazioni avanzate, considerate l'uso di proxy API per mascherare l'origine delle query e l'implementazione di rate limiting per evitare detection basata su soglie di richieste.

Il monitoraggio efficace di questa tecnica richiede visibilità su kubernetes:apiserver e docker:daemon logs. La strategia DET0490 enfatizza la correlazione tra API call anomale e contesto utente per identificare pattern di discovery.

Configurate alert basati su soglie dinamiche piuttosto che statiche. Il parametro PodQueryThreshold dovrebbe adattarsi al normale utilizzo dell'ambiente - un developer potrebbe legittimamente eseguire 50 query in 10 minuti, ma lo stesso comportamento da un service account di produzione è sospetto.

La UserAllowList rappresenta il cuore della detection comportamentale. Mappate accuratamente quali account sono autorizzati a eseguire operazioni di discovery e in quali orari. Un service account che improvvisamente esegue kubectl get nodes alle 3 del mattino merita investigazione immediata.

Eventi critici da monitorare includono:

• Burst di richieste API GET su risorse multiple
• Accessi alla dashboard Kubernetes da IP non autorizzati
• Query su metadata endpoint da container non privilegiati
• Pattern di scansione sequenziale di namespace

Il TimeWindow di correlazione di 10 minuti permette di collegare discovery attempts frammentati. Attenzione ai falsi positivi generati da tool di monitoring legittimi - implementate whitelist granulari basate su user-agent e pattern di query.

L'analisi forense di container discovery richiede la preservazione immediata dei log API prima che vengano ruotati. I log di kubernetes:apiserver contengono timestamp precisi di ogni query, permettendo la ricostruzione dettagliata delle azioni dell'attaccante.

TeamTNT lascia tracce caratteristiche nei docker daemon logs quando esegue docker inspect su container specifici. Cercate pattern di ispezione sistematica dove ogni container viene interrogato in sequenza temporale ravvicinata. La presenza di query su container con nomi sensibili come "database" o "vault" indica targeting mirato.

Gli artefatti critici per la timeline includono:

• Audit log Kubernetes con verb="get" o "list"
• Docker daemon eventi di tipo "container_inspect"
• Access log della dashboard con pattern di navigazione
• Metadata delle immagini Docker pullate di recente

La correlazione temporale tra discovery e successive azioni malevole è fondamentale. Hildegard tipicamente esegue masscan entro 5 minuti dal compromesso iniziale, seguito da tentativi di lateral movement verso i kubelet identificati.

Per container compromessi, esaminate /var/log/containers/ per tracce di comandi di enumerazione eseguiti internamente. La presenza di binari come kubectl o docker client all'interno di container applicativi è un forte indicatore di compromissione.

TeamTNT emerge come l'attore principale in questo spazio, con focus specifico su infrastrutture cloud e cryptomining. Il gruppo dimostra conoscenza approfondita di ambienti containerizzati, combinando tool pubblici con script custom per massimizzare l'efficienza della discovery.

L'evoluzione degli strumenti è significativa. Peirates, originariamente sviluppato per penetration testing, è stato adottato da attori malevoli per automatizzare l'enumerazione Kubernetes. Hildegard rappresenta l'evoluzione successiva, integrando capacità di scansione network con discovery API native.

I pattern geografici mostrano concentrazione di attività in regioni con alta densità di infrastrutture cloud pubbliche. Gli attaccanti privilegiano target con Kubernetes dashboard esposti pubblicamente o Docker API non autenticate.

L'overlap di tool tra gruppi diversi complica l'attribuzione. La presenza di Peirates non implica automaticamente TeamTNT - altri gruppi hanno adottato toolset simili. Monitorate l'evoluzione verso discovery più sofisticate che sfruttano service mesh e sidecar container per movimento laterale invisibile.

Le prossime evoluzioni probabili includono:

• Discovery mirata a secret stores e ConfigMaps
• Sfruttamento di admission controller per persistence
• Targeting di container registry privati per supply chain attacks

Tecnica documentata in MITRE ATT&CK framework con focus su ambienti containerizzati Docker e Kubernetes. TeamTNT campaigns analizzate attraverso threat intelligence report di Palo Alto e Trend Micro. Detection strategy DET0490 basata su correlazione di API logs e behavioral analytics per identificare pattern di resource discovery anomali.