# Storm-3168 Deleted Storage in Seven Minutes. No Note. > In early June 2026 two compromised Azure service principals, tracked as Storm-3168, read one tenant for 15.5 hours, then deleted most targeted storage in seven minutes. Locks blocked some deletes. SQL deletes failed. Microsoft saw no ransom note and no confirmed theft. A public GitHub edit history still held a client secret. Microsoft could not confirm that secret was used. Source: https://hackerlogs.com/blog/storm-3168-seven-minute-wipe Published: 2026-09-28 ## Key takeaways - In early June, two Storm-3168 service principals in one Azure tenant deleted most targeted storage accounts in about seven minutes, after about 15 hours and 30 minutes of reads. - Resource locks and account deletion protection stopped some storage deletes. SQL deletes failed on an unsupported API version. Attempts to remove recovery locks also failed. - Microsoft saw no ransom note and did not confirm theft. Sysdig's July JADEPUFFER case, with a ransom table, is a different body of evidence under the same actor name. - A client secret had been pasted into a public GitHub issue and later edited out. The edit history still held it. Microsoft could not confirm that secret was the one used. - Rotate secrets that ever hit a public issue. Put locks on backup resources. Split Storage Account Contributor, Contributor, and SQL DB Contributor. Alert on mass delete and ListKeys. US X trends on 28 September were Monday Night Football, Sonnet 5.5, and World Labs. Hacker News led with the Sonnet launch, not with Azure. The operator item was a Microsoft writeup from 25 September that [BleepingComputer](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/) and [The Hacker News](https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html) both ran on the 28th. The primary is Microsoft. The actor is Storm-3168, its name for the group Sysdig called JADEPUFFER in July. In early June, two compromised service principals in one Azure tenant deleted most of the storage accounts they targeted. The destructive sequence lasted about seven minutes. Microsoft did not see a ransom note. Workload-identity destruction in one tenant. High because most targeted storage accounts were deleted, not because a note or a confirmed theft was in the writeup. Three panels for Storm-3168's June Azure case: a seven-minute storage delete after hours of reads, no ransom note and an unconfirmed GitHub secret, and the operator moves to rotate, lock, and split roles. ## What Microsoft actually recorded. One service principal enumerated virtual machines, subscriptions, resource groups, and resources for about 15 hours and 30 minutes, with more than 300 successful reads. About 90 minutes after that principal started, a second principal in the same tenant enumerated virtual machines and resource groups across two subscriptions in five seconds. Both used Storm-3168 infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2. Sixteen hours later the second principal read Azure App Service configuration stores, failed to find Azure OpenSearch resources, and then tried ListKeys on a storage account that did not exist. Less than one second after that failed call, the deletes started. The destructive sequence was about seven minutes and included more than 100 storage-account deletion attempts. Most of those accounts were deleted. Azure resource locks and storage-account deletion protection blocked a few. The same principal also deleted an Azure Key Vault, a Function App, and an App Service plan in one resource group, the pieces that appeared to support the Function app. A similarly named storage account in that group was spared, then hit later with a successful ListKeys call. SQL database deletes ran in parallel and all failed. The caller used an unsupported API version for that resource type. Deletes aimed at Azure Site Recovery locks and Azure Backup protection locks also failed. About 30 minutes after the last destructive activity, the same principal inventoried storage accounts and sent more than 30 successful ListKeys requests, including accounts tied to Azure Site Recovery. Across the whole burst, Microsoft counts more than 150 destructive or credential-collection operations in 35 minutes. Five tokens were issued for the principal that deleted and collected keys. Four supported deletion. The fifth handled inventory and key retrieval. Two deletion tokens were active in the same 70-second window: one focused on storage, the other on storage and SQL. The operations followed roles the identity already had. A group-granted Storage Account Contributor role covered the storage deletes. Direct Contributor covered the three application-resource deletes and one extra key retrieval. Direct SQL DB Contributor covered the SQL attempts that the API version then rejected. > Microsoft says the client ID, client secret, and tenant ID had been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret. The secret remained available in the public edit history. Removing the text does not revoke the credential. Microsoft could not confirm this secret was the one used in June. That uncertainty is not an all-clear. The same paragraph says credentials exposed anywhere public should be treated as compromised and rotated. ## The secret clock and the delete clock. The package clock is the secret's public life. Microsoft does not date the GitHub issue. It does date the failure mode: an edit left the value in history, and history is still publication. This is the same shape as the [TanStack token](/blog/tanstack-token-lasted-months) that outlived the package pull. The registry clock, or the issue edit, is not the impact clock. Rotation is the only close. The impact clock is the seven minutes. The reads took about 15 hours and 30 minutes. The handoff from a failed ListKeys call to the first delete was under one second. Storage deletion itself was about seven minutes. The wider destructive and key-collection burst was 35 minutes. ListKeys resumed about 30 minutes after the deletes. A board that briefs "we would have noticed" needs a control that pages inside that window, not inside a business day. The disclosure clock is slower than both. Sysdig published JADEPUFFER on 1 July as an agentic extortion case against a database reached through Langflow. Microsoft's Azure writeup is 25 September. Trade press is 28 September. The deletes were early June. Three months sat between the impact and the Azure report operators are reading today. > Do not brief this tenant as the July ransom. Sysdig's July case describes an LLM-driven extortion run, a ransom table, and a Langflow entry. Microsoft's June Azure case describes service principals, a seven-minute delete, no ransom note, and no confirmed theft. Same actor name. Different evidence. The Langflow probing Microsoft mentions was against other customers' App Service apps, and those targets did not overlap the subscriptions in this wipe. ## What this is not. It is not a confirmed initial-access method. The GitHub secret is a candidate Microsoft will not certify. Probing of App Service paths from Storm-3168 infrastructure, since the start of the year, did not overlap this tenant, and Microsoft found no path from those App Service targets into this tenant's Azure Resource Manager. It is not a finished ransomware incident. Destruction, recovery-lock attempts, and key collection can support extortion. A note was not observed. Exfiltration was not confirmed. It is not a story that the identity was too weak to be dangerous. The deletes succeeded where the role allowed them and the API version was valid. The stops that worked were locks, deletion protection, and a bad API version. Least privilege would have narrowed the role. It would not have replaced the lock. ## What to do. If you hold Azure workload identities: 1. Rotate any secret that ever appeared in a public issue, pull request, gist, or log, including edit history. Editing the issue is not revocation. Then hunt historical use of that client ID. Microsoft could not prove the June link, and still told customers to rotate. 2. Put resource locks and deletion protection on storage, and put the same class of lock on backup and Site Recovery resources. Those locks are what stopped a few storage deletes and the recovery-lock deletes in this case. A Contributor principal does not outrank an independent lock. 3. Split the three roles this principal held: Storage Account Contributor, Contributor, and SQL DB Contributor. One identity that can both inventory keys and delete the account is the burst Microsoft recorded. 4. Alert on mass delete and on ListKeys bursts from a service principal, especially a new user agent and a new source network. The useful page is inside seven minutes, not at the next stand-up. Five tokens and a 70-second overlap are what scripted overlap looks like in the audit log. 5. Do not wait for a ransom note to open the incident. Microsoft did not see one. The storage accounts were already gone. The US board on 28 September was a model launch. The clock that mattered started in June, under a service principal, and it ran for seven minutes. ## Sources - [Storm-3168: Agentic-driven cloud attacks using compromised service principals](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/) (2026-09-25) - [JadePuffer agentic AI attacks target Azure, destroy cloud resources](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/) (2026-09-28) - [JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources](https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html) (2026-09-28) - [JADEPUFFER: Agentic ransomware for automated database extortion](https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion) (2026-07-01)