JadePuffer/Storm-3168: un attore agentico elimina lo storage di un tenant Azure in una raffica distruttiva di 7 minuti

Microsoft Security Research ha segnalato il 25 settembre 2026 che un attore, servendosi di due service principal compromessi, ha operato all'interno di un tenant Azure di cui non è stato reso noto il nome all'inizio di giugno 2026, iniziando con oltre 15 ore di ricognizione e poi, in circa sette minuti, tentando di eliminare più di 100 account di archiviazione, riuscendovi nella maggior parte dei casi, ed eliminando un Azure Key Vault, una Function App e un piano di App Service. Microsoft attribuisce l'intrusione all'attore che monitora con il nome di Storm-3168, che la società di sicurezza Sysdig chiama JADEPUFFER e che ha documentato nel luglio 2026 come la prima operazione ransomware eseguita end-to-end da un modello linguistico di grandi dimensioni. Microsoft ha dichiarato di non aver trovato alcuna nota di riscatto e non ha confermato l'esfiltrazione di dati. L'archivio registra questa campagna come un incidente ad alta gravità, con coinvolgimento confermato dell'IA e danni reali, e la voce completa nell'Orca AI Incident Archive riporta le sue fonti, il grado di gravità e la valutazione di affidabilità.

La vittima non è stata nominata. Il rapporto di Microsoft descrive un singolo tenant Azure, due service principal compromessi che appartenevano ad esso e una divisione dei compiti tra loro: un principal si è occupato di ricognizione per circa 15 ore e 30 minuti ed ha effettuato più di 300 operazioni di lettura riuscite enumerando macchine virtuali, sottoscrizioni, gruppi di risorse e risorse; l'altro ha eseguito l'attività di discovery, le operazioni distruttive e la raccolta di credenziali. Microsoft non ha reso noto quante organizzazioni siano state colpite e non è stato in grado di stabilire come i service principal siano stati compromessi inizialmente.

Cosa mostra la telemetria, in ordine

La seconda entità principale è iniziata circa 90 minuti dopo l'inizio della prima e ha enumerato macchine virtuali e gruppi di risorse in due sottoscrizioni in circa cinque secondi, secondo Microsoft. Entrambe le identità utilizzavano infrastrutture che Microsoft riconduce a Storm-3168, condividevano la stessa impronta di rete e presentavano lo stesso user agent, python-requests/2.34.2. Microsoft ha affermato che la tempistica e la divisione del lavoro "indicano fortemente un'esecuzione automatizzata o tramite script".

Circa 16 ore dopo, il secondo principal controllò gli archivi di configurazione di Azure App Service alla ricerca di credenziali esposte e cercò, senza successo, Azure OpenSearch. Settanta secondi dopo, tentò un'operazione ListKey contro un account di archiviazione che non esisteva. Meno di un secondo dopo quella chiamata fallita, iniziò la distruzione. Nei 35 minuti successivi Microsoft contò più di 150 operazioni distruttive o di raccolta di credenziali; la fase distruttiva principale durò circa sette minuti.

I sette minuti, e i controlli che hanno retto

Microsoft afferma che la maggior parte degli account di archiviazione presi di mira dall'attore è stata eliminata con successo. L'attore ha anche eliminato un Azure Key Vault, una Function App e un piano di App Service che si trovavano nello stesso gruppo di risorse e sembravano supportare la Function App. Il targeting non si è limitato allo storage: Microsoft ha registrato molteplici tentativi di eliminare blocchi di Azure Site Recovery e blocchi di protezione di Azure Backup, e ha segnalato che tali tentativi non sono riusciti.

Microsoft afferma che non tutte le eliminazioni hanno funzionato, e le ragioni differiscono in un modo che conta per i difensori. Alcuni account di archiviazione sono sopravvissuti perché i blocchi delle risorse di Azure e la protezione dall'eliminazione a livello di account di archiviazione hanno bloccato l'operazione. I tentativi paralleli di eliminare i database Azure SQL sono falliti per un motivo diverso: ognuno usava una versione API non supportata. La Cloud Security Alliance l'ha descritto come un errore operativo anziché un'azione bloccata. Microsoft ha riassunto la combinazione di eliminazione delle risorse, tentativi di interferire con il ripristino e raccolta di credenziali come "coerente con tattiche che possono supportare operazioni di ransomware ed estorsione".

Il resoconto di Microsoft descrive normali assegnazioni di ruolo di Azure anziché uno sfruttamento di Azure stesso. Ha rilevato che un ruolo, concesso a un gruppo, Collaboratore account di archiviazione consentiva la distruzione dello storage, un ruolo Collaboratore diretto consentiva l'eliminazione delle tre risorse applicative e un altro recupero di chiavi, e un ruolo Collaboratore database SQL diretto consentiva i tentativi SQL falliti. Microsoft ha osservato cinque token univoci emessi per la seconda entità servizio: quattro supportavano l'eliminazione e il quinto gestiva l'inventario dello storage e il recupero delle chiavi. Due dei token di eliminazione erano attivi durante lo stesso periodo di 70 secondi. Il report osserva inoltre che gli account di archiviazione con terraform e backup nei nomi erano tra gli obiettivi, potenzialmente per compromettere il ripristino.

Il reso per le chiavi di archiviazione

Circa 30 minuti dopo la fine della distruzione, la stessa entità è tornata. Ha inventariato gli account di archiviazione ed effettuato più di 30 richieste ListKeys riuscite, anche contro l'archiviazione collegata a Site Recovery. Un account di archiviazione con un nome simile nello stesso gruppo di risorse era stato risparmiato durante la fase di eliminazione ed è stato poi oggetto di un ListKeys riuscito. Microsoft non ha osservato alcuna nota di riscatto e non ha confermato un'esfiltrazione di dati riuscita, ma ha affermato che le chiavi raccolte potrebbero favorire future esfiltrazioni.

Quella sequenza cambia il significato del ripristino, secondo Ross Filipek, responsabile della sicurezza delle informazioni di Corsica Technologies, che ha parlato a CSO Online dell’incidente. Ricostruire le risorse eliminate non basta, ha affermato, perché le successive richieste di chiavi di archiviazione possono creare un’altra via ai dati; le squadre di risposta devono stabilire quali identità e chiavi sono state coinvolte e rivederne l’uso prima di considerare affidabili i servizi ripristinati. "Una volta che gli attaccanti possiedono un’identità applicativa, le loro attività possono sembrare normale amministrazione cloud", ha detto Filipek a CSO Online.

Come sono emerse le credenziali

Microsoft non è riuscita a confermare il vettore di accesso iniziale. Ciò che ha trovato è stata un'esposizione: l'ID client, il client secret e l'ID tenant di uno dei service principal erano apparsi in chiaro in una issue pubblica su GitHub, pubblicata da un dipendente dell'organizzazione colpita. La issue è stata successivamente modificata, ma Microsoft ha affermato che il segreto è rimasto accessibile tramite la cronologia pubblica delle modifiche della issue. Il rapporto afferma chiaramente che Microsoft non è riuscita a confermare se fosse proprio questo segreto a essere stato utilizzato.

L'avvertenza collegata a tale rilevamento è la parte pratica. Microsoft afferma che le credenziali esposte pubblicamente devono essere considerate compromesse, revocate o ruotate immediatamente e sottoposte a indagine per verificarne l'uso precedente; rimuovere o oscurare un segreto esposto non lo invalida, e le credenziali esposte pubblicamente restano utilizzabili finché non vengono revocate o ruotate.

Microsoft ha anche descritto un'attività di probing più ampia da parte di infrastrutture collegate a Storm-3168, a partire dall'inizio del 2026, contro Azure App Services su amministrazione WordPress, PHP-CGI, l'endpoint Langflow /api/v1/validate/code e percorsi simili a webshell. Tali obiettivi non si sovrapponevano alle sottoscrizioni della vittima e Microsoft non ha trovato alcun percorso da un App Service alle credenziali di Azure Resource Manager. Il rapporto elenca tre indicatori: 45.131.66[.]106 per il probing e le richieste ARM malevole, e 34.153.223[.]102 e 64.20.53[.]230 per il probing di App Service.

Lo stesso attore, un'operazione diversa

Il rapporto del 1° luglio 2026 di Sysdig è il motivo per cui il termine "agentico" viene associato a questo attore. Sysdig ha descritto JADEPUFFER come il primo caso documentato di ransomware agentico — "un'operazione di estorsione completa gestita dall'inizio alla fine da un modello linguistico di grandi dimensioni" — e ha affermato che le sue capacità provenivano da un agente AI anziché da un toolkit gestito da esseri umani. In quell'intrusione, l'attore ha sfruttato CVE-2025-3248 in un'istanza Langflow esposta a Internet, ha crittografato 1.342 elementi di configurazione Nacos usando la funzione AES_ENCRYPT() integrata di MySQL, ha eliminato le tabelle originali e ha lasciato una tabella README_RANSOM con un indirizzo Bitcoin e un contatto Proton Mail. Sysdig ha segnalato più di 600 payload distinti, codice auto-narrante e un payload correttivo a più fasi che è seguito a un login Nacos fallito nel giro di 31 secondi. Sysdig ha anche affermato di non avere visibilità sul prompt di sistema o sulla configurazione dell'agente.

La campagna Azure è un'operazione distinta dello stesso attore, non una ripetizione dell'intrusione di luglio: riguardava la cancellazione e la raccolta di chiavi, non la crittografia, e Microsoft non ha trovato alcuna nota di riscatto. Il legame tra le due si basa in parte sull'infrastruttura. La Cloud Security Alliance ha osservato in una nota di ricerca del 28 settembre che due degli indirizzi IP elencati da Microsoft, 45.131.66[.]106 e 34.153.223[.]102, erano apparsi nel resoconto di luglio di Sysdig. La stessa nota avvertiva che il solo riutilizzo degli IP non può escludere un hosting condiviso di terze parti.

Stabilito, valutato e ancora aperto

I meccanismi dell'intrusione in Azure sono ben documentati. L'autonomia non è documentata allo stesso standard, e la differenza è la precisazione più importante in questo resoconto.

Stabilito dalla telemetria di Microsoft: due principal di servizio compromessi in un unico tenant; più di 300 operazioni di lettura riuscite in circa 15 ore e mezza; più di 100 tentativi di eliminazione di account di archiviazione, la maggior parte dei quali riusciti; l'eliminazione di un Key Vault, di una Function App e di un piano di App Service; eliminazioni di database SQL tutte fallite a causa di una versione API non supportata; account di archiviazione salvati da blocchi delle risorse e dalla protezione dall'eliminazione; più di 30 richieste ListKeys riuscite dopo la distruzione; credenziali in chiaro di principal di servizio in un issue pubblico di GitHub e nella relativa cronologia delle modifiche; nessuna nota di riscatto osservata; e nessuna esfiltrazione confermata.

Valutato da Microsoft: che l'attività appartiene a Storm-3168; che la combinazione di cancellazione, interferenza con il ripristino e raccolta delle chiavi è coerente con ransomware ed estorsione; che l'esecuzione era probabilmente automatizzata o scriptata; e che le chiavi raccolte potrebbero supportare future esfiltrazioni. Il rapporto pubblico di Microsoft non descrive un agente autonomo che ragiona attraverso i passaggi specifici di Azure.

Aperte: come le entità servizio siano state compromesse inizialmente; l'identità della vittima e il numero di organizzazioni colpite; se dei dati siano usciti dal tenant; e se un agente AI, anziché uno script, abbia diretto le operazioni di Azure stesse.

La Cloud Security Alliance ha individuato con precisione la lacuna probatoria nella sua nota del 28 settembre: la caratterizzazione "agentica", scrive, si basa attualmente "sulla precisione, sul ritmo e sulla divisione del lavoro tra identità", anziché su tracce acquisite del ragionamento dell'agente. Le prove usate da Sysdig a luglio — payload autodescrittivi e un rapido ciclo di diagnosi e correzione — sono assenti dal registro pubblico della campagna Azure. Nick Tausek della società di sicurezza Swimlane ha dichiarato a CSO Online che le prove relative ad Azure mostrano "un'automazione coordinata anziché dimostrare che l'IA abbia diretto ogni fase".

La copertura della divulgazione ha utilizzato la formulazione più forte. Il titolo di BleepingComputer descriveva "attacchi di IA agentica" contro Azure, mentre quello di Dark Reading descriveva un "attore IA" che comprometteva un tenant Azure; il rapporto di Microsoft stesso afferma che la tempistica e la divisione del lavoro "indicano fortemente un'esecuzione automatizzata o scriptata" e non attribuisce i singoli passaggi su Azure a un agente.

L'archivio assegna a questo record una confidenza A e non lo segnala come contestato. L'etichetta di coinvolgimento dell'IA «confermato» del record dipende dall'attribuzione a JADEPUFFER, l'attore che Sysdig ha documentato come guidato da LLM; non è un'asserzione che Microsoft abbia catturato il ragionamento di un agente durante le cancellazioni in Azure. Il danno è accertato, l'automazione è accertata e l'autonomia è dedotta.

Ciò che, secondo Microsoft, dovrebbe cambiare

Le raccomandazioni di Microsoft sono operative e derivano direttamente da come è avvenuta questa intrusione. Chiede ai difensori di abilitare i piani pertinenti di Microsoft Defender for Cloud per Resource Manager, Storage, Key Vault, App Service e Databases; di tenere le credenziali dell'entità servizio, le chiavi di archiviazione, le stringhe di connessione e altri segreti fuori dal codice sorgente, dalla configurazione, dai repository e dalle issue; di usare Microsoft Entra Workload ID invece di segreti di lunga durata; di applicare il privilegio minimo e rivedere le assegnazioni RBAC di Azure per le identità del carico di lavoro; e di limitare e monitorare le risorse di backup e ripristino, inclusi i tentativi di modificare i relativi controlli di protezione.

Il rapporto pubblico di Microsoft non indica se il tenant abbia ripristinato i propri dati, se la vittima sia stata avvisata o se una qualsiasi delle chiavi raccolte sia stata usata in seguito. Tali esiti non figurano nel resoconto. Ciò che il resoconto riporta è un contrasto misurabile: i blocchi delle risorse e la protezione dall'eliminazione hanno impedito alcune eliminazioni anche nei confronti di identità con privilegi ampi, mentre i database SQL sono stati salvati da un errore di versione API anziché da una decisione di un difensore. Il resoconto di Microsoft non dice cosa abbia fatto il tenant in seguito. Dice però che l'attore ha trascorso più di 15 ore a leggere prima di impiegare sette minuti a eliminare.