JadePuffer: 7 minuti di distruzione Azure, ma l'AI resta un'ipotesi non provata

JadePuffer, il threat actor tracciato da Microsoft come Storm-3168, ha condotto un attacco distruttivo su Azure in early June 2026. Due service principal legittimi, compromessi con privilegi elevati, hanno mappato l'ambiente per oltre 15 ore e mezza, poi cancellato in circa 7 minuti oltre 100 storage account, un Key Vault, una Function App e un App Service plan. Microsoft ha pubblicato l'analisi forense il 25 settembre 2026. Il caso solleva una tensione tra il marketing di Microsoft, che etichetta l'attacco come "agentic-driven", e la valutazione di esperti che vedono automazione sofisticata ma non prova di direzione AI step-by-step.

FATTI: Come si è svolto l'attacco

Il meccanismo centrale è l'abuso di workload identities, le identità non umane che governano l'automazione nel cloud Azure. I service principal compromessi operavano seguendo i ruoli Azure esistenti: Storage Account Contributor, Contributor e SQL DB Contributor. Questo ha permesso all'attaccante di muoversi all'interno dei permessi legittimi del tenant, rendendo l'attività indistinguibile dalla normale amministrazione fino alla fase finale.

Il primo service principal ha condotto ricognizione per circa 15 ore e 30 minuti con oltre 300 operazioni di lettura riuscite, enumerando macchine virtuali, subscription, resource group e risorse. Il secondo ha completato la mappatura in 5 secondi su due subscription, passando poi alle operazioni distruttive.

La sequenza distruttiva è durata circa 7 minuti con oltre 100 tentativi di cancellazione storage account, la maggior parte riusciti. Sono stati colpiti anche un Azure Key Vault, una Function App e un App Service plan. Tentativi di cancellare database Azure SQL sono falliti per unsupported API version. Tentativi di rimuovere lock di Azure Site Recovery e protezione Azure Backup sono falliti.

Post-distruttivamente, l'attaccante ha eseguito oltre 30 richieste ListKeys per recuperare chiavi di storage account, inclusi account Site Recovery. Microsoft ha documentato 5 token unici emessi per il service principal distruttivo: 4 per cancellazione, 1 per inventory e chiavi. Due token di cancellazione erano attivi nello stesso periodo di 70 secondi, uno su storage, l'altro su storage e SQL.

Microsoft non ha osservato ransom note né confermato esfiltrazione dati nell'incidente Azure. L'attività è consistente con tattiche che supportano operazioni ransomware o estorsione.

FATTI: Le credenziali esposte e il limite della conferma

Microsoft ha identificato che il client ID, il client secret e il tenant ID erano stati esposti in plaintext in un issue GitHub pubblico. Anche dopo la rimozione o la redazione del contenuto, le credenziali erano rimaste accessibili tramite l'edit history del repository.

Microsoft Security Research avverte: "Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated".

Tuttavia, la stessa fonte specifica che Microsoft "non ha potuto confermare che la credenziale esposta sia stata usata nell'attacco". La fonte non specifica il vettore di compromissione iniziale.

ANALISI: Il dibattito su "agentic-driven" contro automazione

Microsoft ha etichettato l'attacco come "agentic-driven". L'etichetta si colloca nel più ampio discorso su JadePuffer: Sysdig lo aveva identificato nel luglio 2026 come il primo ransomware operation completamente LLM-driven documentato, in un incidente separato su Langflow e MySQL. Per l'attacco Azure specifico, la prova forense non sostiene la stessa lettura.

"I agree with Microsoft's warning about AI-orchestrated attacks, though the Azure evidence shows coordinated automation rather than proving AI directed each step" — Nick Tausek, lead security automation architect at Swimlane

Tausek, citato da Dark Reading, concorda con l'allarme generale di Microsoft ma precisa che l'evidenza tecnica mostra automazione coordinata. La distinzione non è semantica: per i difensori, cambia cosa cercare e come priorizzare.

Yossi Weizman e Tushar Mudi di Microsoft Security Research descrivono la "ampiezza dell'attività" che avrebbe dato al threat actor "visibility across the organization's Azure environment". Questa visibilità totale è il prerequisito della distruzione mirata.

ANALISI: Cosa ha funzionato nei controlli cloud

L'incidente offre una misura empirica della resilienza di alcuni controlli cloud. I resource locks su Azure Site Recovery e Azure Backup hanno bloccato i tentativi di rimozione della protezione. L'unsupported API version per Azure SQL ha reso impossibile la cancellazione dei database relazionali. Questi controlli convenzionali hanno limitato il danno.

L'attaccante ha operato seguendo i ruoli Azure esistenti, non aggirando limitazioni di ruolo come difesa. I ruoli pre-esistenti erano sufficienti per la distruzione.

Cosa fare adesso

Microsoft Security Research raccomanda esplicitamente: le credenziali esposte in qualsiasi luogo pubblico di internet devono essere trattate come compromesse e revocate o ruotate prontamente. La rimozione o la redazione di un secret esposto non lo invalida.

La fonte non specifica ulteriori azioni operative.

Chiusura editoriale

L'incidente JadePuffer su Azure documenta automazione sofisticata con precisione misurabile: token sovrapposti, ruoli divisi, tempistiche calibrate. Il framing "agentic-driven" di Microsoft è marketing che un esperto qualificato contesta per questo caso specifico. Per i difensori, la lezione concreta è che le workload identities richiedono monitoraggio sui pattern di token e sulle anomalie nelle API di gestione, indipendentemente dall'etichetta che si appone all'automazione avversaria.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.darkreading.com/cloud-security/jadepuffer-ai-actor-azure-tenant-destructive-cloud-attack
• https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/
• https://cyberupdates365.com/jadepuffer-storm-3168-azure-attack/
• https://www.darkreading.com/cyberattacks-data-breaches/jadepuffer-first-complete-llm-driven-ransomware-attack
• https://www.darkreading.com/threat-intelligence/microsoft-disrupts-ransomware-abusing-azure-certificates
• https://www.darkreading.com/cloud-security/how-to-build-sase-framework