Le identità applicative Azure rubate hanno permesso a JadePuffer di trasformare l’accesso al cloud in un’operazione distruttiva

Microsoft ha attribuito a JadePuffer attività distruttive all’interno di tenant Azure. L’azienda monitora questo attore con il nome Storm-3168. In un incidente descritto nel dettaglio, l’attaccante ha preso il controllo di due service principal e li ha usati per individuare risorse, raccogliere credenziali, eliminare servizi cloud e compromettere le protezioni per il ripristino.

Microsoft ha pubblicato il resoconto dell’incidente il 25 settembre 2026, descrivendo attività risalenti ai primi di giugno. Secondo fonti separate, a giugno Microsoft ha osservato due attacchi, anche se il resoconto dettagliato documenta principalmente una singola sequenza.

L’operazione ha causato danni ingenti senza sfruttare una vulnerabilità software resa nota. JadePuffer ha invece agito attraverso identità applicative compromesse, dotate di autorizzazioni che consentivano di eseguire operazioni simili a quelle di una normale amministrazione del cloud.

Due service principal hanno suddiviso le attività dell’attacco

I service principal di Azure sono identità applicative usate da software e processi automatizzati per autenticarsi e accedere alle risorse. È possibile assegnare loro autorizzazioni Azure RBAC senza ricorrere a un account utente interattivo.

JadePuffer ha compromesso due identità di questo tipo all’interno dello stesso tenant. La prima è stata usata soprattutto per mappare l’ambiente nell’arco di circa 15,5 ore, completando con successo oltre 300 operazioni di lettura su macchine virtuali, sottoscrizioni, gruppi di risorse e altre risorse Azure.

La seconda identità si è mossa molto più rapidamente. Circa 90 minuti dopo l’inizio della ricognizione più ampia, ha enumerato macchine virtuali e gruppi di risorse in due sottoscrizioni in appena cinque secondi.

Questa suddivisione suggerisce un flusso di lavoro organizzato: una prima identità ha creato un inventario dettagliato, mentre la seconda ha condotto attività di ricognizione mirate e azioni distruttive. Le prove disponibili, tuttavia, non permettono di stabilire se questa divisione fosse gestita dall’IA, da un’automazione tradizionale o da istruzioni impartite direttamente da un operatore.

I ricercatori di Microsoft Yossi Weizman e Tushar Mudi hanno affermato che un’attività di ricognizione di questo livello può offrire all’attaccante visibilità sull’intero ambiente Azure della vittima. L’operazione non si è limitata a individuare singoli carichi di lavoro.

Il secondo service principal ha inoltre interrogato gli archivi di configurazione di Azure App Service, forse alla ricerca di credenziali incorporate nelle impostazioni delle applicazioni. Ha cercato senza successo risorse Azure OpenSearch e ha tentato un’operazione ListKey su un account di archiviazione inesistente.

Meno di un secondo dopo quella richiesta non riuscita, sono iniziate le eliminazioni.

Account di archiviazione e servizi di supporto eliminati in pochi minuti

L’attaccante ha tentato di eliminare gli account Azure Storage per oltre 100 volte e la maggior parte delle operazioni è riuscita. Nello stesso gruppo di risorse sono stati rimossi anche un Azure Key Vault, una Function App e un piano App Service.

Secondo le notizie sugli attacchi osservati in Azure, la fase distruttiva è durata circa sette minuti e ha preso di mira macchine virtuali e App Service, oltre ad account di archiviazione, Key Vault e Function App. La descrizione più dettagliata di Microsoft riferisce che sono state individuate macchine virtuali, ma non conferma che siano state eliminate.

JadePuffer ha anche tentato di eliminare diversi database Azure SQL. I tentativi non sono riusciti perché l’attore ha specificato una versione dell’API non supportata: un esempio di come anche una sequenza automatizzata e rapida possa fallire se le richieste non sono compatibili con il servizio preso di mira.

L’operazione è quindi tornata a concentrarsi sull’archiviazione. Circa 30 minuti dopo la fase di eliminazione, il service principal compromesso ha richiesto un inventario degli account Azure Storage, compresi quelli associati ad Azure Site Recovery.

In seguito ha completato con successo oltre 30 richieste ListKeys, ottenendo chiavi di accesso agli account di archiviazione. A seconda della configurazione, queste chiavi possono consentire l’accesso diretto agli account, indipendentemente dalle autorizzazioni Azure RBAC originariamente assegnate al service principal.

L’attaccante ha anche tentato di indebolire le misure di backup e ripristino. I tentativi di rimuovere i blocchi di Azure Site Recovery sono falliti, mentre i blocchi delle risorse e le protezioni a livello di account di archiviazione hanno impedito l’eliminazione di alcuni account presi di mira.

Queste misure hanno fatto la differenza. Non hanno fermato l’operazione, ma ne hanno limitato la portata.

Una chiave GitHub esposta potrebbe spiegare l’accesso, ma l’attribuzione resta incompleta

Microsoft non è riuscita a determinare con esattezza come siano stati compromessi i due service principal. Ha però individuato una potenziale esposizione significativa che riguardava una delle identità.

Un dipendente dell’organizzazione colpita aveva pubblicato in chiaro, in una segnalazione pubblica su GitHub, il client ID, il client secret e il tenant ID del service principal. In seguito la segnalazione è stata modificata per rimuovere il secret, ma il valore originale è rimasto disponibile nella cronologia pubblica delle modifiche.

Microsoft non ha potuto confermare che JadePuffer abbia ottenuto o utilizzato quella credenziale esposta. Si tratta quindi di una possibile via d’accesso, non di un accesso iniziale dimostrato.

La distinzione è importante: eliminare un secret dalla versione corrente di un post non rimuove copie, contenuti memorizzati nella cache, cronologia del repository o registrazioni delle modifiche della piattaforma. Quando una credenziale finisce in un sistema pubblico, i difensori devono considerarla compromessa e sostituirla, anziché affidarsi alla rimozione del contenuto.

Come ha osservato Ross Filipek, CISO di Corsica Technologies, le operazioni eseguite tramite un’identità applicativa possono sembrare normali attività di amministrazione del cloud. Rilevarle può quindi essere più difficile se il monitoraggio si concentra sugli accessi non riusciti o sulle sessioni sospette degli utenti, anziché sul comportamento anomalo delle API usate dalle identità dei carichi di lavoro.

Dall’inizio dell’anno Microsoft ha inoltre osservato infrastrutture collegate a JadePuffer sondare Azure App Service presso più clienti. Tra i percorsi testati figurano quelli di amministrazione di WordPress, PHP-CGI, l’endpoint di convalida del codice di LangFlow /api/v1/validate/code e percorsi simili a quelli usati dalle web shell.

Non è noto se queste attività di scansione abbiano portato alla compromissione descritta.

Lo schema del ransomware è chiaro, ma il ruolo dell’IA è meno certo

Microsoft ha descritto le attività come compatibili con tattiche di ransomware o estorsione. L’eliminazione di risorse di produzione, i tentativi di ottenere chiavi di accesso agli account di archiviazione e gli sforzi per ostacolare il ripristino corrispondono a una strategia distruttiva volta a esercitare pressione.

Gli investigatori, tuttavia, non hanno trovato alcuna richiesta di riscatto, non hanno confermato alcuna pretesa economica e non hanno accertato che sia avvenuta un’esfiltrazione di dati. Definire l’incidente un attacco ransomware descrive quindi lo schema operativo apparente, non un’estorsione conclusa e verificata.

A luglio, secondo le notizie sulle conclusioni di Microsoft e sulle attività precedenti dell’attore, Sysdig aveva identificato JadePuffer come la prima operazione ransomware documentata condotta da un modello linguistico di grandi dimensioni. La sua analisi descriveva agenti di IA capaci di automatizzare varie fasi, tra cui ricognizione, furto di credenziali, movimento laterale, persistenza e cifratura.

Secondo quanto riferito, in seguito JadePuffer ha esteso i propri obiettivi alle risorse di IA, ai set di dati usati per l’addestramento e ai database vettoriali, servendosi di uno strumento chiamato EncForge.

L’incidente Azure dimostra un’automazione altamente coordinata. Non prova, però, che un agente di IA abbia selezionato o diretto ogni chiamata API.

Nick Tausek, lead security automation architect di Swimlane, ha sottolineato questa distinzione, concordando al contempo con l’avvertimento più ampio di Microsoft: l’IA agentica potrebbe consentire agli attaccanti di eseguire operazioni più rapidamente e su un numero maggiore di risorse, ma la rapidità e il coordinamento, da soli, non dimostrano che l’intera sequenza sia stata gestita dall’IA.

Per chi si occupa di difesa, il rischio pratico è simile in entrambi i casi. Le identità cloud possono eseguire centinaia di richieste di ricognizione ed eliminazione molto più rapidamente di quanto un team di risposta agli incidenti possa esaminarle manualmente.

I difensori dovrebbero sostituire le credenziali esposte e limitare i permessi delle identità applicative

Le organizzazioni che usano Azure dovrebbero innanzitutto individuare i service principal con ampi privilegi su archiviazione, sistemi di ripristino, Key Vault, configurazioni delle applicazioni e operazioni di eliminazione delle risorse. Le assegnazioni Azure RBAC andrebbero verificate in base al principio del privilegio minimo, soprattutto quando una singola identità può operare su più sottoscrizioni.

Microsoft raccomanda diverse misure:

• Abilitare i piani Microsoft Defender for Cloud più adatti ai carichi di lavoro Azure critici.
• Verificare con continuità che le credenziali e i secret delle applicazioni non siano stati esposti.
• Sostituire immediatamente qualsiasi credenziale pubblicata o di cui si sospetti la compromissione.
• Definire controlli sul ciclo di vita dei secret, dalla creazione alla revoca, includendo archiviazione e scadenza.
• Limitare le autorizzazioni dei service principal e delle identità dei carichi di lavoro allo stretto necessario.
• Controllare repository pubblici, segnalazioni, commenti e cronologie delle modifiche per individuare credenziali esposte.

È inoltre opportuno applicare blocchi delle risorse e protezioni per gli account di archiviazione, laddove compatibili con le esigenze operative. In questo incidente, tali misure hanno impedito direttamente alcuni tentativi di eliminazione, compresi quelli contro risorse di archiviazione e ripristino protette.

Il monitoraggio dovrebbe tenere conto delle sequenze di attività, non solo dei singoli eventi. Tra i segnali d’allarme utili figurano l’enumerazione rapida di più sottoscrizioni, l’accesso agli archivi di configurazione di App Service, raffiche di richieste ListKeys sugli account di archiviazione e numerose operazioni di eliminazione eseguite da un service principal.

Microsoft ha citato Project Perception e MDASH come iniziative pensate per aiutare i difensori a indagare e reagire in ambienti complessi con flussi di lavoro supportati dall’IA. Qualunque sia la tecnologia impiegata, la sfida immediata è chiara: le identità applicative devono essere monitorate come attori privilegiati, non trattate come processi di background affidabili.