La spazzatura digitale colpisce il cuore del cloud: scansione indiscriminata

Il 19 agosto 2025 Johannes B. Ullrich, Dean of Research presso SANS.edu, ha riportato l'osservazione first-hand di una scansione diffusa e non mirata verso l'indirizzo IPv4 169.254.169.254, il punto di accesso standard del Cloud Metadata Service. La rilevazione non riguarda un exploit sofisticato ma un approccio brute-force e generico, che sonda la superficie di attacco SSRF senza selezionare target specifici. La novità sta nel metodo: dagli attacchi mirati del passato, gli operatori sembrano passare a una ricognizione a tappeto che conta sulla persistenza di configurazioni deboli.

Perché 169.254.169.254 è un bersaglio sensibile

Cloud provider esponono API REST metadata all'indirizzo 169.254.169.254. Il servizio può restituire credenziali IAM role e service account tokens, rendendolo un obiettivo strategico per la post-compromissione o l'escalation privilegi. L'indirizzo rientra nel prefisso link-local 169.254/16 definito in RFC 3927, assegnato a comunicazioni locali non routable su reti IPv4. La non-routabilità lo rende ideale per servizi che devono essere accessibili solo localmente alla VM, ma non lo immunizza da attacchi che sfruttano il server come proxy involontario.

Attacker possono raggiungere il metadata service tramite SSRF, inducendo il server a inoltrare la richiesta verso l'indirizzo link-local. La tecnica non è nuova. Il breach Capital One resta il caso più noto di abuso del metadata service, con conseguenze in termini di data leak e procedimenti giudiziari. Quell'incidente ha catalizzato l'introduzione di IMDSv2 da parte di Amazon, che aggiunge autenticazione session-based alla semplice richiesta GET.

Dal precision strike allo spam di rete: il cambio di tattica

Ciò che distingue la rilevazione di Ullrich non è la vulnerabilità sfruttata, ma l'assenza di selezione del target. La scansione non sembra targettare una vulnerabilità specifica: è un tentativo generico di trovare "some" vulnerability, con il target che resta indefinito. Questo passaggio da exploit SSRF mirati — che presupponevano conoscenza dell'applicazione vulnerabile e del suo stack cloud — a una ricognizione indiscriminata rivela una maturità diversa nelle tattiche offensive.

La logica è quella dello spam applicato all'infrastruttura: se un numero sufficiente di istanze cloud rimane configurato con IMDSv1 o presenta path SSRF non mitigati, il costo della scansione generalizzata si ripaga con il volume di potenziali successi. Il dossier non specifica se la scansione sia automatizzata o manuale, né la sua frequenza temporale. Mancano dati quantitativi su richieste per minuto, IP sorgenti, distribuzione geografica o verticale dei target.

"This scan does not appear to target a specific vulnerability; it is a more generic attempt to find 'some' vulnerability, and it is not clear which one." — Johannes B. Ullrich, Dean of Research, SANS.edu

IMDSv2 e il limite della mitigazione distribuita

Amazon ha introdotto IMDSv2 dopo il breach Capital One. Il protocollo richiede una sequenza di richieste autenticate che rende l'accesso SSRF via semplice GET "highly unlikely", come documenta Ullrich. La mitigazione è tecnicamente solida ma dipende dalla sua adozione universale: istanze con IMDSv1 enforced o con configurazioni ibride restano esposte alla tecnica base. Il problema si sposta quindi dal gap tecnologico al gap operativo, dalla vulnerabilità zero-day alla configurazione legacy.

Il dossier non documenta misure correttive specifiche né lo stato di adozione di IMDSv2 nel parco istanze esposte alla scansione. IPv6 introduce una distinzione tecnica rilevante: l'indirizzo equivalente è fd20:ce::254, un unique local address, non fe80:: come si potrebbe presumere dal modello link-local IPv4. Questo dettaglio architetturale indica che gli operatori di scansione devono adattare il loro tooling a due namespace separati.

Perché è importante

La fonte non specifica la natura dei dati eventualmente esposti da istanze vulnerabili. Il dossier non documenta compromissioni avvenute, né fornisce indicatori di compromissione verificabili. Mancano conferme indipendenti da altri ricercatori, CERT o dataset honeypot. Il volume esatto della scansione, la sua origine geografica, la motivazione precisa e la distribuzione dei target restano unknown.

Ciò che emerge con chiarezza è il segnale strategico: la superficie di attacco IMDS/SSRF rimane attivamente sondata anche con tecniche generiche, non solo exploit mirati. La persistenza di questa scansione — anche nella sua indeterminatezza — indica che gli operatori offensive considerano ancora redditizia la scommessa su configurazioni cloud deboli. Il brief non specifica se altri cloud provider oltre AWS siano inclusi nel perimetro della scansione.

Cosa non sappiamo e i punti da verificare

Il dossier lascia aperti interrogativi operativi rilevanti. Non emerge se la scansione sia associata a un framework di attacco noto, a una campagna precedente o a un attore specifico. Non sono documentati pattern di richiesta, user-agent o altre impronte tecniche che permetterebbero il riconoscimento. L'anno dell'evento è inferito: la data di pubblicazione del diary è il 19 agosto 2025, ma il dossier non esplicita se la scansione sia avvenuta in quel giorno o in un arco temporale più ampio.

La mancanza di log grezzi pubblicati limita la riproducibilità dell'osservazione. Ullrich riporta l'evento come rilevazione first-hand, ma il lettore non ha accesso ai dati grezzi che la sorreggono. Questo è un limite strutturale della fonte singola, non una delegittimazione: la credibilità istituzionale di SANS e la posizione dell'autore forniscono contesto, ma non sostituiscono la verifica indipendente.

Fonti

• https://isc.sans.edu/diary/rss/33260
• https://www.rfc-editor.org/info/rfc3927/
• https://sans.edu/
• https://jbu.me/164
• https://www.sans.org/blog/cloud-instance-metadata-services-imds-

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti