JADEPUFFER colpisce Azure: l’attacco agentico cancella risorse cloud

🛡️ Cosa cambia

• Microsoft collega JADEPUFFER a una campagna distruttiva contro Azure basata su service principal compromessi e automazione coordinata.
• In circa sette minuti sono partiti oltre 100 tentativi di cancellazione di Storage Account, insieme ad attacchi contro SQL, Key Vault, Function App e risorse di recovery.
• Il punto debole non è stato un exploit sofisticato del cloud: identità workload troppo privilegiate e credenziali esposte hanno trasformato l’accesso in capacità distruttiva.

JADEPUFFER ha fatto il salto dal ransomware agentico contro database alla distruzione coordinata di infrastrutture Azure. Microsoft Security Research ha collegato a Storm-3168 un’operazione osservata all’inizio di giugno 2026 nella quale due service principal compromessi dello stesso tenant sono stati utilizzati per mappare l’ambiente, raccogliere credenziali e cancellare risorse cloud. L’operazione ha colpito Storage Account, Key Vault, Function App e App Service, tentando contemporaneamente di eliminare database SQL e protezioni legate ad Azure Backup e Site Recovery. Il dato più interessante non è però la quantità delle risorse distrutte: è la velocità con cui ricognizione, enumerazione, cancellazione e recupero delle chiavi sono state coordinate attraverso identità applicative già autorizzate nell’ambiente.

Due identità applicative hanno trasformato Azure in un bersaglio interno

La ricostruzione tecnica pubblicata da Microsoft mostra due service principal compromessi con compiti differenti. Il primo ha effettuato per circa 15 ore e mezza oltre 300 operazioni di lettura, enumerando macchine virtuali, subscription, resource group e altre risorse. Circa novanta minuti dopo l’inizio della ricognizione, il secondo principal ha attraversato due subscription in pochi secondi e, sedici ore più tardi, ha iniziato a interrogare gli store di configurazione degli App Service, verosimilmente alla ricerca di altre credenziali. Settanta secondi dopo l’ultima operazione di inventory è partita la fase distruttiva.

In 35 minuti Microsoft ha registrato oltre 150 operazioni riconducibili a cancellazione o raccolta credenziali, con una finestra distruttiva particolarmente intensa di circa sette minuti. In quel periodo sono stati eseguiti più di cento tentativi di cancellazione di Storage Account e la maggior parte delle risorse bersagliate è stata effettivamente eliminata. Sono stati cancellati anche un Key Vault, una Function App e un App Service plan, mentre i tentativi di eliminare più database Azure SQL sono falliti per un errore dell’attaccante nell’utilizzo della versione API. Protezioni indipendenti come resource lock e deletion protection hanno invece impedito la cancellazione di alcuni Storage Account, dimostrando quanto possano essere decisive quando un’identità privilegiata viene compromessa.

Leggi anche: Claude Code Security usa l’AI per cercare vulnerabilità nel codice

Il vero perimetro del cloud è l’identità workload

Il caso diventa ancora più rilevante osservando il possibile vettore iniziale. Microsoft precisa di non poter dimostrare che sia stato utilizzato proprio quel segreto, ma ha scoperto che client ID, client secret e tenant ID di uno dei service principal erano stati pubblicati in chiaro in una issue GitHub pubblica da un dipendente dell’organizzazione colpita. La issue era stata successivamente modificata per rimuovere il secret, ma il valore restava consultabile nella cronologia pubblica delle modifiche. È un dettaglio che demolisce una delle false sicurezze più diffuse nella gestione delle credenziali: cancellare un segreto da una pagina pubblica non significa revocarlo. Il problema si aggrava perché quei service principal disponevano già di ruoli sufficienti per operare sulle risorse. Un ruolo Storage Account Contributor ottenuto attraverso un gruppo permetteva le operazioni distruttive sugli storage, mentre permessi Contributor diretti autorizzavano la cancellazione delle risorse applicative. L’account disponeva inoltre di SQL DB Contributor, motivo per cui le eliminazioni dei database sarebbero state tecnicamente consentite se le chiamate API fossero state corrette. JADEPUFFER non ha dovuto violare il modello autorizzativo di Azure: ha semplicemente sfruttato fino in fondo ciò che l’identità compromessa era già autorizzata a fare. È qui che il caso supera il tema del ransomware. Nel cloud il confine non coincide più con la macchina o con la rete: coincide con l’identità, i secret associati e le policy IAM. Una credenziale workload esposta può diventare un accesso persistente alle API di gestione, e la velocità dell’automazione permette di attraversare l’ambiente molto prima che un operatore umano riesca a interpretare singolarmente ogni evento.

Da Sysdig a Microsoft, JADEPUFFER industrializza l’attacco agentico

Il nome JADEPUFFER nasce dal report Sysdig pubblicato a luglio, nel quale il gruppo di ricerca aveva documentato quello che definiva il primo caso completo di ransomware agentico guidato end-to-end da un large language model. In quella campagna l’accesso iniziale era avvenuto attraverso un’istanza Langflow esposta e vulnerabile a CVE-2025-3248; l’agente aveva poi concatenato ricognizione, raccolta delle credenziali, movimento laterale e distruzione del database, generando e adattando centinaia di payload senza la classica sequenza manuale di comandi impartiti da un operatore. Microsoft oggi espande il profilo della stessa minaccia mostrando la sua attività in Azure. Nel nuovo incidente non pubblica la stessa telemetria che consentirebbe di vedere direttamente il ragionamento di un LLM, ma osserva cinque token distinti, operazioni concorrenti, suddivisione dei compiti e flussi sovrapposti, elementi che indicano una forte componente automatizzata o scriptata. Due token hanno lavorato contemporaneamente per circa settanta secondi, uno sulle cancellazioni Storage e l’altro su Storage e SQL. Terminata la distruzione, lo stesso principal ha effettuato oltre trenta richieste ListKeys sugli Storage Account rimasti, incluse risorse legate a Site Recovery.

Continua con:
GPT-4 sfrutta vulnerabilità partendo dagli avvisi di sicurezza
Ondata di vulnerabilità critiche minaccia infrastrutture, IA e servizi cloud

L’AI accelera l’attacco, ma il fallimento resta umano

JADEPUFFER mostra quindi una trasformazione concreta della minaccia, non perché utilizzi tecniche mai viste prima, ma perché riduce il tempo necessario per concatenarle. Le stesse debolezze restano note: segreti pubblicati per errore, permessi eccessivi, recovery non abbastanza isolata, identità applicative lasciate valide troppo a lungo. L’agente rende però queste debolezze sfruttabili a velocità macchina e permette di colpire contemporaneamente più superfici. Microsoft raccomanda rotazione immediata dei secret esposti, least privilege sulle workload identity, protezione separata dell’infrastruttura di backup e monitoraggio delle modifiche alle risorse di recovery. Il caso Azure dimostra perché queste misure non siano più semplicemente “best practice”: quando l’attaccante può automatizzare ricognizione e distruzione, ogni minuto lasciato a una credenziale compromessa diventa capacità operativa. La lezione di Storm-3168 è quindi meno futuristica di quanto sembri. L’AI non ha inventato il buco: lo ha percorso più velocemente. Il cloud era già vulnerabile nel punto decisivo, cioè nelle identità e nei privilegi concessi. JADEPUFFER ha semplicemente mostrato cosa succede quando un agente può trasformare quella debolezza in una sequenza distruttiva quasi immediata.