Seven minutes is enough to erase a cloud estate. Put recovery controls outside workload identity.

Microsoft observed a compromised Azure service principal execute a destructive sequence lasting about seven minutes. In that window, Storm-3168 attempted more than 100 storage-account deletions, and most targeted accounts were successfully deleted. The lesson is not simply that cloud attacks are getting faster. It is that recovery controls must survive the identity that administers the workload.

The same identity also targeted Key Vault, Function Apps, App Service resources, SQL databases and recovery-related locks. Microsoft linked the activity to JADEPUFFER and tracks it as Storm-3168, while noting that it did not observe a ransom note or confirm successful data exfiltration in this incident.

Broad workload identity turns automation into blast radius

Microsoft found that the destructive service principal operated through permissions it already had. Group-granted Storage Account Contributor authorised storage destruction, while direct Contributor access enabled deletion of application resources. SQL DB Contributor permitted database deletion attempts, although those failed because the attacker used an unsupported API version.

That makes the control problem concrete. A service principal is not safer than a human administrator merely because nobody signs in interactively. Long-lived secrets, broad role assignments and automation-friendly APIs can turn one compromised workload identity into a machine-speed control plane.

Recovery is not independent if the same compromised identity can administer both the workload and the controls meant to restore it.

The controls that survived were outside the attacker's effective authority

Some storage deletion attempts failed because Azure resource locks and storage-account deletion protection remained effective. The actor also tried to remove Site Recovery and Azure Backup protection locks. Those attempts show why ransomware resilience cannot be treated as another permission attached to the production workload.

The practical architecture is separation of authority. Workload identities should receive the narrowest resource actions they require. Backup, recovery and destructive-control changes should sit behind different identities, stronger approval paths and independently monitored policy. An application credential that can run production should not automatically be able to dismantle the recovery path.

Detect the transition from inventory to destruction

Microsoft saw extensive discovery before the destructive phase, including hundreds of successful read operations by one compromised service principal. The second identity moved from a final inventory operation to destructive activity in roughly 70 seconds, then later issued more than 30 successful storage ListKeys requests.

Cloud detection should therefore correlate workload-identity behaviour across phases rather than alert on isolated API calls. Baseline service-principal resource enumeration, flag abrupt expansion across subscriptions or resource types, and treat destructive operations or bulk key retrieval by an application identity as high-priority sequences.

For Azure teams, the release gate is straightforward: inventory every privileged service principal, remove standing permissions it does not need, rotate exposed secrets immediately, and test whether recovery protections still hold when that identity is assumed compromised. Seven minutes leaves little room for a human approval chain to compensate after destruction starts.

Written by the Devence Lab research team.