JadePuffer: 7 Minutes of Azure Destruction, but the AI Label Remains Unproven

JadePuffer, the threat actor Microsoft tracks as Storm-3168, executed a destructive attack on Azure in early June 2026. Two compromised service principals with elevated privileges mapped the environment for over 15 and a half hours, then deleted more than 100 storage accounts, a Key Vault, a Function App, and an App Service plan in roughly 7 minutes. Microsoft published the forensic analysis on September 25, 2026. The case exposes a tension between Microsoft's marketing, which labels the attack "agentic-driven," and expert assessments that see sophisticated automation but no proof of AI step-by-step direction.

FACTS: How the Attack Unfolded

The core mechanism is the abuse of workload identities—the non-human identities that govern automation in Azure cloud. The compromised service principals operated within existing Azure roles: Storage Account Contributor, Contributor, and SQL DB Contributor. This allowed the attacker to move within the tenant's legitimate permissions, making activity indistinguishable from normal administration until the final phase.

The first service principal conducted reconnaissance for approximately 15 hours and 30 minutes with over 300 successful read operations, enumerating virtual machines, subscriptions, resource groups, and resources. The second completed mapping in 5 seconds across two subscriptions, then pivoted to destructive operations.

The destructive sequence lasted roughly 7 minutes with over 100 storage account deletion attempts, most successful. An Azure Key Vault, a Function App, and an App Service plan were also hit. Attempts to delete Azure SQL databases failed due to an unsupported API version. Attempts to remove Azure Site Recovery locks and Azure Backup protection failed.

Post-destruction, the attacker executed over 30 ListKeys requests to retrieve storage account keys, including Site Recovery accounts. Microsoft documented 5 unique tokens issued for the destructive service principal: 4 for deletion, 1 for inventory and keys. Two deletion tokens were active simultaneously for a 70-second window, one on storage, the other on storage and SQL.

Microsoft observed no ransom note and confirmed no data exfiltration in the Azure incident. The activity is consistent with tactics supporting ransomware or extortion operations.

FACTS: Exposed Credentials and the Limits of Confirmation

Microsoft identified that the client ID, client secret, and tenant ID had been exposed in plaintext in a public GitHub issue. Even after the content was removed or redacted, the credentials remained accessible via the repository's edit history.

Microsoft Security Research warns: "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."

However, the same source specifies that Microsoft "could not confirm that the exposed credential was used in the attack." The source does not specify the initial compromise vector.

ANALYSIS: The "Agentic-Driven" vs. Automation Debate

Microsoft labeled the attack "agentic-driven." The label sits within the broader discourse on JadePuffer: Sysdig identified it in July 2026 as the first documented fully LLM-driven ransomware operation, in a separate incident involving Langflow and MySQL. For this specific Azure attack, the forensic evidence does not support the same reading.

"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, quoted by Dark Reading, agrees with Microsoft's general warning but clarifies that the technical evidence shows coordinated automation. The distinction is not semantic: for defenders, it changes what to look for and how to prioritize.

Yossi Weizman and Tushar Mudi of Microsoft Security Research describe the "breadth of activity" that would have given the threat actor "visibility across the organization's Azure environment." This total visibility is the prerequisite for targeted destruction.

ANALYSIS: What Worked in Cloud Controls

The incident provides an empirical measure of the resilience of certain cloud controls. Resource locks on Azure Site Recovery and Azure Backup blocked attempts to remove protection. The unsupported API version for Azure SQL made deletion of relational databases impossible. These conventional controls limited the damage.

The attacker operated within existing Azure roles, not bypassing role limitations as a defense. The pre-existing roles were sufficient for destruction.

What to Do Now

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

The source does not specify further operational actions.

Editor's Closing Note

The JadePuffer incident on Azure documents sophisticated automation with measurable precision: overlapping tokens, divided roles, calibrated timing. Microsoft's "agentic-driven" framing is marketing that a qualified expert disputes for this specific case. For defenders, the concrete lesson is that workload identities require monitoring for token patterns and anomalies in management APIs, regardless of the label affixed to adversarial automation.

Information verified against cited sources and current as of publication.

Sources

• 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