An AI Agent Deleted Over 100 Azure Storage Accounts in Seven Minutes
Microsoft's Storm-3168 report describes an attacker hijacking two Azure service principals and reading more than 300 resources over 15 hours before deleting over 100 Storage Accounts in about seven minutes. The activity links to JadePuffer, the agentic ransomware campaign Sysdig first documented in July. Resource locks and deletion protection blocked some deletions, and no ransom note or confirmed data theft followed.
On this page
Eighteen hours of recon, seven minutes of deletion
Microsoft's threat intelligence team published details on 25 September of an Azure attack it attributes to Storm-3168, the actor behind the JadePuffer agentic ransomware campaign. Over an 18-hour window in early June, two hijacked service principals in a single tenant split the work: one handled reconnaissance, the other destruction and credential collection. Both identities shared a network fingerprint and used the user agent python-requests/2.34.2.
The discovery phase ran for roughly 15.5 hours and logged more than 300 successful read operations across virtual machines, subscriptions, and resource groups. About 90 minutes in, the second identity started work, reading VMs and resource groups across two subscriptions in five seconds. Then the tempo flipped. The same identity made over 150 destructive or credential-stealing requests in 35 minutes, and the active destruction took about seven of them: attempts to delete more than 100 Azure Storage Accounts, most of which succeeded. An Azure Key Vault, a Function App, and an App Service plan went too. Parallel attempts against Azure SQL databases all failed on an unsupported API version.
Where the identities came from
Microsoft does not know the initial access vector, and the report is candid about that gap. What it does note: an employee at the targeted organization had previously posted client IDs, client secrets, and tenant IDs in plaintext in a public GitHub issue, and Storm-3168 had spent months probing Azure App Services across multiple customers. A cloud identity is only as strong as its secret. Once a service principal's credentials leak, the permission scope attached to it becomes the attacker's permission scope, and Azure's own audit trail is the only witness.
It is worth being precise about the agentic label here. Sysdig's July report on JadePuffer documented an LLM driving the full extortion chain, from exploiting exposed Langflow and Nacos servers to destroying a production database. Microsoft's Azure writeup describes the same automation-first playbook and classifies the operation as agentic, but it does not claim a language model made each decision in this specific incident. The documented facts are speed and autonomy: five seconds to enumerate two subscriptions, seven minutes to attempt 100-plus deletions.
What actually stopped the deletions
Two unglamorous Azure controls blocked parts of the attack. Resource locks and storage account-level deletion protection stopped some deletion attempts outright, and protection locks on Site Recovery and Backup survived targeted deletion attempts afterwards. The attacker also ran a storage inventory pass and issued more than 30 successful ListKeys requests after the destruction phase, which suggests credential collection was a goal in its own right.
Microsoft assesses the destruction, the interference with recovery mechanisms, and the credential collection as tactics consistent with ransomware and extortion operations. No ransom note appeared and no exfiltration was confirmed, which makes this a rehearsal that partially succeeded rather than a completed extortion. For anyone running agents or automation with cloud credentials, the lesson list is short: pin least-privilege scopes on service principals, treat secrets that ever touched a public repository as burned, turn on deletion protection before you need it, and keep the blast radius of any single identity small enough that seven minutes cannot erase it.