Furto dalle API dei Metadati Cloud: Cloud Instance Metadata API (T1552.005)

L'accesso ai metadati richiede solo una semplice richiesta HTTP dall'interno dell'istanza. Su AWS EC2, il comando base per recuperare le credenziali temporanee è:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

Per automatizzare l'enumerazione completa dei metadati disponibili, puoi utilizzare uno script ricorsivo che esplora tutti gli endpoint. Su Linux, questo one-liner elenca tutte le informazioni accessibili:

for url in $(curl -s http://169.254.169.254/latest/meta-data/ | grep -o '[^/]/$' | sed 's//$//'); do echo "=== $url ==="; curl -s http://169.254.169.254/latest/meta-data/$url/; echo; done*

Le vulnerabilità SSRF amplificano drasticamente il rischio. Se identifichi un'applicazione web che effettua richieste HTTP basate su input utente, prova a farle interrogare l'endpoint dei metadati inserendo URL come:

http://169.254.169.254/latest/user-data http://[::ffff:169.254.169.254]/latest/meta-data/

Il tool Peirates automatizza questi attacchi in ambienti Kubernetes, permettendo di estrarre token di servizio e credenziali cloud con un singolo comando. Per simulazioni più sofisticate, Hildegard dimostra come i malware reali implementano questa tecnica per mantenere la persistenza.

Gli ambienti containerizzati presentano sfide aggiuntive. Docker e Kubernetes possono implementare restrizioni di rete che bloccano l'accesso diretto all'API. Verifica sempre la connettività con:

timeout 2 curl -s http://169.254.169.254/ || echo "Metadata API blocked"

La detection efficace richiede monitoraggio su più livelli. I VPC Flow Logs rappresentano la prima linea di difesa, catturando ogni connessione verso 169.254.169.254 dalle tue istanze EC2.

Configura alert specifici per pattern anomali di accesso. Le applicazioni legittime accedono ai metadati durante il bootstrap, ma richieste ripetute o accessi a endpoint sensibili come /iam/security-credentials/ dopo l'avvio iniziale indicano potenziale compromissione.

Il monitoraggio SSRF richiede analisi dei Web Application Firewall logs. Cerca richieste con header Host contenenti l'IP dei metadati o parametri URL che potrebbero essere manipolati:

Host: 169.254.169.254
Referer: http://169.254.169.254/
X-Forwarded-For: 169.254.169.254

Per ambienti containerizzati, implementa eBPF probes che intercettano syscall connect verso l'indirizzo link-local. Sysmon Event ID 3 su Windows e auditd su Linux possono catturare queste connessioni a livello di processo.

La correlazione temporale è fondamentale. Un accesso ai metadati seguito immediatamente da connessioni esterne verso IP sconosciuti suggerisce exfiltration di credenziali. Mantieni una baseline del comportamento normale delle tue applicazioni per ridurre i falsi positivi.

CloudTrail non registra direttamente gli accessi all'API dei metadati, ma monitora eventi come GetInstanceIdentityDocument che potrebbero indicare reconnaissance correlata.

Gli accessi all'API dei metadati lasciano tracce sparse ma identificabili. I VPC Flow Logs costituiscono la fonte primaria, mostrando timestamp precisi e volumi di dati trasferiti verso 169.254.169.254.

L'analisi dei processi rivela quali applicazioni hanno effettuato le richieste. Su Linux, esamina /var/log/messages o journal di systemd per identificare processi che hanno stabilito connessioni HTTP verso l'endpoint dei metadati. La presenza di curl, wget o interpreti Python con argomenti contenenti l'IP target indica accesso manuale.

Le vulnerabilità SSRF lasciano artefatti nei web server logs. Apache access_log e nginx logs registrano le richieste originali che hanno innescato l'accesso ai metadati. Cerca pattern come:

"GET /proxy?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1" 200
"POST /api/fetch" {...,"url":"http://[::ffff:169.254.169.254]/"}

La timeline reconstruction deve considerare il contesto cloud. Le credenziali temporanee estratte hanno validità limitata (tipicamente 6 ore su AWS), quindi correla gli accessi ai metadati con successive chiamate API usando quelle credenziali.

Memory forensics può rivelare credenziali in plaintext nella memoria dei processi. Strings analysis su dump di memoria spesso espone access key e session token utilizzati per operazioni successive.

TeamTNT rimane l'attore principale associato a questa tecnica. Il gruppo opera dal 2019 con focus esclusivo su ambienti cloud e containerizzati, distinguendosi per l'uso sistematico dell'API dei metadati come primo step post-compromissione.

Il loro modus operandi segue pattern prevedibili. Dopo l'accesso iniziale tramite credenziali Docker esposte o kubelet mal configurati, interrogano immediatamente l'API per ottenere credenziali IAM. Queste vengono poi utilizzate per enumerare S3 bucket e lanciare nuove istanze per cryptomining.

L'evoluzione di TeamTNT mostra adattamento continuo. Le versioni iniziali del loro malware effettuavano richieste dirette all'API, mentre Hildegard implementa tecniche di offuscamento e verifica la presenza di sandbox prima di accedere ai metadati.

Altri gruppi stanno adottando questa tecnica. Attori focalizzati su ransomware hanno iniziato a includere moduli per l'estrazione di credenziali cloud, riconoscendo il valore degli ambienti cloud per lateral movement e data exfiltration.

La geografia degli attacchi mostra concentrazione in regioni con alta densità di datacenter cloud. Gli IP sorgente spesso corrispondono a exit node Tor o VPS compromessi, rendendo l'attribution geografica poco affidabile. Il vero indicatore rimane l'infrastruttura C2 e i wallet di criptovaluta utilizzati.

La presente analisi si basa sul framework MITRE ATT&CK, tecnica T1552.005. I pattern di attacco descritti derivano da campagne documentate di TeamTNT e dall'analisi del malware Hildegard. Le raccomandazioni di detection integrano best practice da AWS Instance Metadata Service v2 documentation e ricerche pubblicate da RedLock e Krebs on Security sul Capital One breach.