News Date: 2026-09-25
Microsoft has documented a destructive Azure intrusion in which compromised service principals were used to inventory a cloud environment, collect credentials and delete resources at machine speed. The activity is associated with Storm-3168, Microsoft's name for the threat actor also known as JADEPUFFER.
Workload Identities Became the Attackers' Operators
Two compromised service principals were observed inside the same tenant. One conducted broad reconnaissance across subscriptions, resource groups and virtual machines. The second performed discovery, credential collection and destructive actions against Azure Storage, Key Vault, Function Apps, App Services and other resources.
The most damaging sequence lasted approximately seven minutes and included more than 100 attempts to delete storage accounts. Most targeted storage accounts were reportedly removed. The attackers also attempted to delete Azure SQL databases and protections associated with backup and recovery, although some actions failed because of technical errors or independent safeguards.
Microsoft said the timing, overlapping tokens and division of tasks strongly indicated automated or scripted execution. The operations remained constrained by the permissions already granted to the compromised identities, making excessive Azure role assignments a major factor in the potential impact.
A Public Secret May Have Created Risk
Microsoft could not conclusively determine the initial access route. However, credentials belonging to one service principal had previously appeared in a public GitHub issue and remained visible through its edit history after the original text was changed. This is a crucial reminder that deleting an exposed secret does not revoke it.
How Azure Customers Should Respond
- Immediately revoke and rotate any credential exposed in code, issues, logs or configuration files.
- Replace long-lived secrets with managed identities or short-lived authentication where possible.
- Review Azure role assignments for service principals and remove unnecessary contributor access.
- Use resource locks and deletion protections for critical data and recovery infrastructure.
- Alert on bulk deletion, unusual ListKeys activity and attempts to weaken backup controls.
- Keep recovery resources isolated from identities used for routine application administration.
I believe this incident should change how organizations think about cloud ransomware. The critical identity may not be a human administrator. It may be an application credential that never receives phishing training, rarely changes and quietly holds access across an entire subscription.
The speed of the destructive activity also makes manual response unrealistic. By the time an analyst reviews an alert, storage and application resources may already be gone. Defenders need automated containment, protected recovery layers and identity-focused monitoring that can interrupt abnormal control-plane operations before a compromised workload identity completes its task.