Furto di Credenziali dal Metadata Cloud: Cloud Instance Metadata API (T1552.005)

La simulazione di questa tecnica in laboratorio è sorprendentemente semplice, ed è proprio questa semplicità a renderla pericolosa negli ambienti reali. L'intero attacco si riduce a una richiesta HTTP verso un indirizzo IP fisso, senza necessità di autenticazione.

Su un'istanza AWS EC2 con IMDSv1 attivo, il comando fondamentale per estrarre le credenziali temporanee del ruolo IAM associato è una catena in due passaggi. Prima si identifica il nome del ruolo:

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

Il servizio restituisce il nome del ruolo. A quel punto si richiede il token completo:

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/NOME-RUOLO

La risposta include AccessKeyId, SecretAccessKey e SessionToken — tutto ciò che serve per autenticarsi via AWS CLI da qualsiasi macchina esterna. Su GCP, l'equivalente richiede un header specifico:

curl -s -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

Per scenari SSRF, il red teamer può testare un'applicazione web vulnerabile iniettando l'indirizzo del metadata service come URL target in parametri di input che l'applicazione usa per effettuare richieste server-side. Tool come Burp Suite (a pagamento) o OWASP ZAP (open source) permettono di intercettare e manipolare questi parametri con precisione.

Lo strumento Peirates (open source) automatizza l'interrogazione delle metadata API sia su AWS che su GCP in contesti Kubernetes compromessi, ed è specificamente progettato per il pentesting di ambienti containerizzati. All'interno di un pod, Peirates enumera automaticamente i secret disponibili e tenta di estrarre credenziali cloud dal metadata endpoint.

Per simulare lo scenario IMDSv2 — la versione protetta da AWS — serve prima ottenere un token di sessione con una PUT:

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

E poi usarlo nelle richieste successive:

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

Questa seconda variante è più complessa da sfruttare via SSRF perché richiede una PUT con header personalizzato, cosa che molte vulnerabilità SSRF non consentono. Il red teamer dovrebbe documentare nel report se l'ambiente target usa IMDSv1 o IMDSv2, perché la differenza in termini di rischio è sostanziale.

Il detection engineering per questa tecnica si gioca su due piani: il traffico di rete verso l'endpoint metadata e il comportamento post-esfiltrazione delle credenziali ottenute. Il monitoraggio diretto delle chiamate al 169.254.169.254 è il punto di partenza, ma richiede attenzione perché molte applicazioni legittime — agent di configurazione, script di bootstrap, servizi cloud-native — interrogano regolarmente quel endpoint.

Le log source primarie sono AWS VPC Flow Logs, AWS CloudTrail e, a livello host, le syscall catturate via eBPF. I VPC Flow Logs registrano il traffico di rete e permettono di individuare connessioni anomale verso 169.254.169.254 da processi che normalmente non dovrebbero farlo. CloudTrail, dal canto suo, non registra la chiamata al metadata service in sé, ma cattura l'uso successivo delle credenziali temporanee — ed è qui che la detection diventa più affidabile.

Un alert ad alta fedeltà si costruisce correlando due eventi: una chiamata API registrata in CloudTrail in cui le credenziali temporanee di un'istanza vengono usate da un IP sorgente diverso dall'IP privato dell'istanza stessa. Questo pattern — credenziali di istanza usate dall'esterno — è quasi sempre indice di esfiltrazione avvenuta. Su AWS, il campo sourceIPAddress nel log CloudTrail va confrontato con l'IP dell'istanza proprietaria del ruolo.

Per la detection a livello host, osquery (open source) consente di monitorare le connessioni di rete attive e individuare processi che contattano l'indirizzo del metadata endpoint:

SELECT pid, name, remote_address, remote_port FROM process_open_sockets WHERE remote_address = '169.254.169.254';

Il tuning è cruciale per ridurre i falsi positivi. Occorre costruire una baseline dei processi e degli utenti che legittimamente accedono al metadata service — tipicamente cloud-init, l'agent SSM di AWS, agent di monitoring come CloudWatch o Datadog. Le query che provengono da shell interattive (bash, sh, python, curl lanciato manualmente) fuori da contesti di automazione dovrebbero alzare il livello di severità dell'alert.

Come controllo preventivo, la mitigazione più efficace è la migrazione a IMDSv2, che richiede un token di sessione ottenuto via PUT e neutralizza la maggior parte degli attacchi SSRF. A livello di rete, regole iptables sull'istanza possono limitare l'accesso al metadata endpoint ai soli processi root o a UID specifici. Un WAF correttamente configurato sulle applicazioni web esposte può bloccare richieste SSRF che puntano all'indirizzo link-local.

L'analisi forense di un incidente che coinvolge il metadata API cloud segue un percorso che parte dall'istanza compromessa e si espande verso l'intero tenant cloud. La sfida è che l'accesso al metadata endpoint non lascia log applicativi di default — non c'è un servizio che registri le chiamate HTTP a 169.254.169.254 sul lato del provider. Gli artefatti vanno cercati sia sull'host sia nei log centralizzati.

Sul filesystem dell'istanza, il primo elemento da verificare è la bash history degli utenti (~/.bash_history, /root/.bash_history): comandi curl o wget verso 169.254.169.254 sono evidenza diretta. Anche la history di Python (~/.python_history) può contenere tracce di script che hanno usato la libreria requests per interrogare il metadata service. Se l'attacco è passato attraverso un'applicazione web, i log di accesso del web server (Apache, Nginx) possono contenere richieste con il payload SSRF — tipicamente parametri URL contenenti l'indirizzo del metadata endpoint.

La timeline deve includere i log CloudTrail come elemento cardine. L'analista cerca eventi AssumeRole e chiamate API effettuate con le credenziali temporanee dell'istanza, verificando se il campo sourceIPAddress corrisponde all'IP dell'istanza o a un indirizzo esterno. Un cambio di IP sorgente segna il momento in cui le credenziali sono state esfiltrate e usate altrove. È importante annotare il TTL residuo del token al momento dell'uso anomalo: i token IAM di istanza hanno una durata massima di 6 ore, quindi la finestra temporale dell'attacco è limitata.

Per istanze containerizzate, come nel caso di Hildegard — malware documentato in ambienti Kubernetes — gli artefatti si trovano anche nei log del container runtime. I log di containerd o dockerd possono rivelare l'esecuzione di processi non previsti dall'immagine originale. Hildegard ha interrogato il metadata API per ottenere credenziali cloud direttamente dall'interno dei pod, e il gruppo TeamTNT ha usato questo approccio specificamente su istanze AWS per poi muoversi lateralmente verso altri servizi del tenant.

L'acquisizione forense in ambito cloud richiede tool specifici: Prowler (open source) per auditare la configurazione IAM e identificare ruoli con permessi eccessivi associati alle istanze coinvolte, e CloudTrail Lake o Athena per interrogare grandi volumi di log con query SQL. La correlazione temporale tra l'accesso al metadata endpoint (ricostruito dagli artefatti host) e il primo uso anomalo delle credenziali (da CloudTrail) definisce la finestra critica dell'incidente.

Il panorama degli attori che sfruttano il metadata API cloud è ancora relativamente ristretto nei dati strutturati, ma in rapida espansione. Il gruppo e i software documentati dipingono un quadro coerente: operazioni orientate al cloud, con focus su ambienti containerizzati e automazione massiva.

TeamTNT (G0139) è il gruppo più rappresentativo di questa tecnica. Si tratta di un threat actor specializzato in attacchi a infrastrutture cloud e container, con un focus particolare su AWS. La loro interrogazione del metadata service per estrarre credenziali IAM è parte di una catena d'attacco più ampia che include il cryptomining e il furto sistematico di risorse computazionali. Il pattern operativo di TeamTNT prevede tipicamente l'accesso iniziale tramite servizi esposti (Docker API, Kubernetes dashboard non autenticati), seguito dall'interrogazione immediata del metadata endpoint per escalare i privilegi a livello di tenant cloud.

Il malware Hildegard (S0601) rappresenta l'evoluzione della toolchain di TeamTNT, progettato specificamente per ambienti Kubernetes. La capacità di Hildegard di interrogare il metadata API per ottenere credenziali cloud direttamente dai pod compromessi mostra una maturità operativa significativa: l'attore non si limita al nodo, ma punta al control plane cloud.

Lo strumento Peirates (S0683), pur essendo un tool di pentesting open source, è stato adottato in operazioni offensive reali. La sua capacità di interrogare sia le API metadata di AWS che quelle di GCP lo rende un indicatore di attività multi-cloud. Quando un analista TI rileva l'uso di Peirates in un incidente, dovrebbe valutare la possibilità che l'attore stia operando su più provider contemporaneamente.

Il trend più rilevante per il prossimo periodo riguarda la transizione da IMDSv1 a IMDSv2 su AWS: man mano che le organizzazioni adottano la versione protetta, gli attori dovranno evolvere le loro tecniche — probabilmente spostando il vettore dall'SSRF classico verso l'esecuzione diretta di codice sull'istanza, dove anche IMDSv2 rimane sfruttabile. L'analista TI dovrebbe monitorare l'adozione di IMDSv2 nel proprio tenant come indicatore di riduzione del rischio e tracciare eventuali nuovi tool che automatizzino il bypass della protezione token-based.

Framework MITRE ATT&CK v16 — Tecnica T1552.005 (Cloud Instance Metadata API), Tattica TA0006. Gruppi: G0139. Software: S0683, S0601. Mitigazioni: M1035, M1042, M1037. Detection: analisi su AWS VPC Flow Logs, CloudTrail, eBPF syscalls. Integrato con conoscenza professionale per tool e procedure operative.