AI Ransomware JadePuffer Is Deleting Azure Data
The ransomware operator JadePuffer is running AI agent-driven attacks against Microsoft Azure tenants that map the environment, steal credentials and destroy core cloud resources, according to Microsoft Security Research.
Key facts
Who: JadePuffer, tracked by Microsoft as Storm-3168, first documented by Sysdig in July 2026 as the first reported agentic ransomware operation
How they got in: Two compromised service principals belonging to the same Azure tenant
What was destroyed: Azure Storage accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines and App Services
The reconnaissance: One service principal enumerated resources for about 15 and a half hours with over 300 successful read operations before destruction began
Ongoing: Microsoft says JadePuffer-linked infrastructure has been probing Azure App Services across multiple customers since the start of the year
What is a service principal, and why does this matter?
A service principal is a machine identity — a security credential that lets an application, hosted service or automated tool authenticate to Azure and access assigned resources. It is how software logs in without a human.
Service principals are attractive to attackers because they often have broad permissions, rarely have multifactor authentication, and almost never get reviewed. Nobody notices when one logs in at 3 a.m., because that is normal behavior for automation.
Microsoft said the destructive operations were facilitated by compromising service principals, and that exposed credentials may have provided the way in.
What did the attack actually look like?
Patient, then fast. In early June 2026, one compromised service principal spent roughly 15 hours and 30 minutes enumerating Azure Virtual Machines, subscriptions, resource groups and resources, logging more than 300 successful read operations. About 16 hours after those initial reads, a second service principal discovered Azure App Service configuration stores — likely hunting for exposed credentials — and unsuccessfully searched for Azure OpenSearch resources.
Then came deletion of storage accounts, Key Vaults and Function Apps, plus attempts to remove Site Recovery disk locks and an Azure Backup protection lock.
That last detail is the significant one. Targeting recovery mechanisms before or alongside destruction is a deliberate move to prevent the victim restoring from backup. Microsoft said the resource destruction, interference with recovery, and credential collection together are consistent with tactics supporting ransomware and extortion, though it did not report financial demands or confirm data theft in these cases.
Sysdig previously noted JadePuffer expanded its focus to AI assets, training datasets and vector databases using a tool called EncForge.
Is this really an AI-directed attack?
Contested, and worth stating honestly. Microsoft describes the activity as reflecting a broader shift toward AI-orchestrated attacks, where threat actors coordinate across cloud environments with greater speed and scale.
Nick Tausek, lead security automation architect at Swimlane, is more cautious — he agrees with Microsoft's warning about AI-orchestrated attacks, but says the Azure evidence shows coordinated automation rather than proving AI directed each step. He noted JadePuffer's earlier database attack did show an AI agent working through an extortion playbook and adjusting when steps failed.
The distinction matters less than the practical outcome: whether directed by a model or a script, the attack moved faster than human response.
What should Azure customers do this week?
Three things.
Inventory your service principals and app registrations, and find out which have permissions nobody can justify. Most organizations have more than they think, created for projects that ended.
Protect backup and recovery infrastructure as its own security problem, with separate credentials and deletion protections that a compromised tenant identity cannot remove.
Monitor identity activity against cloud configuration changes, not separately. The tell in this attack was 300 read operations from a machine identity over 15 hours — visible in logs, meaningless unless someone is connecting identity behavior to what follows.
Sources: BleepingComputer; Microsoft Security Blog; Dark Reading; The Register.