Azure & Entra workload identity
User multifactor authentication still matters. It does not automatically protect every non-human identity in a Microsoft tenant. A service principal is the app or workload identity behind an app registration. It can hold Contributor-class access to storage, databases, Key Vaults, and recovery controls without anyone signing in with a password and a phone prompt.
Microsoft Security Research (September 25, 2026) detailed Azure-focused destruction tied to JADEPUFFER, which Microsoft tracks as Storm-3168, using compromised service principals. For Mid-Michigan Microsoft 365 and Azure shops, the practical response is inventory and hygiene – not another user-MFA poster.
MFA can look fine. An unused service principal can still burn Azure. Lock down workload identities the same way you lock down people.
What Microsoft observed
Sysdig discovered JADEPUFFER in July 2026 and reported it as the first documented agentic ransomware operation. Microsoft later described extensive Azure resource destruction using compromised service principals, plus cloud credential collection that could support future exfiltration.
In the activity Microsoft described, two service principals in the same tenant were abused. One mapped the environment. The other drove discovery, destruction, and credential collection. Targeted resources included Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.
Microsoft placed the activity in early June 2026. One principal enumerated virtual machines, subscriptions, resource groups, and resources for about 15 hours and 30 minutes, with 300+ successful read operations. The second enumerated virtual machines and resource groups across two subscriptions in about five seconds. Both used Storm-3168-linked infrastructure and the user agent python-requests/2.34.2.
The same principal then attempted 150+ destructive or credential-collection operations in about 35 minutes. This was not a slow, manual click-path through the Azure portal. It was scripted cloud abuse of identities the tenant already trusted.
Seven minutes of storage deletion
In the destructive burst Microsoft observed, there were 100+ storage account deletion attempts in about seven minutes – and most of the targeted storage accounts were successfully deleted. An Azure Key Vault, a Function App, and an App Service plan were also deleted. Multiple Azure SQL deletion attempts failed because the API version used was not supported for that resource type.
Microsoft framed the pattern as consistent with ransomware-aligned tactics: destroy data, impair recovery, and collect credentials. Microsoft did not observe a ransom note, and did not confirm successful data exfiltration, in that write-up. Do not treat the incident as proof of a completed extortion. Treat it as proof that a hijacked workload identity can move faster than a helpdesk ticket.
Locks still mattered
Azure resource locks and storage account-level deletion protection still blocked a few deletions, even when the compromised identity had broad permissions. That is the useful operational lesson. Broad roles are dangerous; a lock that the everyday app identity cannot remove is still a speed bump worth keeping.
The actor also made multiple unsuccessful attempts to remove Azure Site Recovery locks and Azure Backup protection locks. About 30 minutes after the final destructive activity, Microsoft observed inventory plus 30+ successful ListKeys requests against storage accounts, including Site Recovery-related accounts. Recovery infrastructure was in scope – not an afterthought.
Redacting a secret is not rotating it
Microsoft noted that client ID, client secret, and tenant ID values for a related service principal had previously appeared in plaintext in a public GitHub issue. After the post was edited, the secret remained reachable through the issue’s public edit history. Microsoft could not confirm that this secret was the one used for the activity it described. The operational point still stands: removing the text does not invalidate the credential. Rotate or revoke any secret that has ever been exposed – in a repo, a ticket, or a chat log.
Microsoft’s mitigation themes for this class of activity include Defender for Cloud workload protections, assessing and protecting app credentials, rotating exposed secrets, least privilege on service principals and workload identities, and protecting backup and recovery infrastructure.
What to do
For app owners
- Name every app registration you still need – and the secret or certificate it uses
- Tell IT when a project ends so the principal can be disabled, not left “just in case”
- Never paste client secrets into tickets, chat, or public issues; if you already did, ask for a rotation
- Prefer a managed identity when the platform allows it, instead of a long-lived secret
For organizations
- Inventory app registrations and service principals, not only interactive user accounts
- Disable or delete unused principals; rotate secrets that were ever exposed, including repo history
- Review Contributor-class roles on storage, Key Vault, SQL, and backup scopes
- Tighten who can grant admin consent to applications
- Keep resource locks, deletion protection, and Backup / Site Recovery controls out of easy reach of everyday app identities – and watch for attempts to remove them
Practical checklist
Inventory app registrations and service principals (workload identities) – not only interactive user accounts.
Disable or delete unused principals. Rotate secrets that have ever been exposed, including tickets, chat, and repository history.
Apply least privilege. Contributor-class roles on storage, Key Vault, SQL, and backup scopes should be intentional and reviewed.
Tighten who can grant admin consent to applications.
Protect recovery: keep Azure resource locks, deletion protection, and Backup / Site Recovery controls out of easy reach of everyday app identities, and monitor attempts to remove them.
Prefer managed identities over long-lived client secrets where the platform allows it.
Bottom line for Mid-Michigan teams
User MFA protects people. Storm-3168 shows why that is not the whole identity story. Compromised service principals were used for fast Azure destruction and credential collection. Locks and deletion protection still stopped some deletions. A secret left in Git history is not cleaned up by editing the page. Inventory unused app registrations, apply least privilege, tighten admin consent, and treat recovery locks as ransomware-critical controls.
KW Corporation is part of your team. Our Managed IT practice helps Mid-Michigan and statewide clients review Entra and Azure workload identities, clean up unused app registrations, tighten consent and role assignments, and keep backup and recovery controls in the same conversation as identity hardening.
Ready to review workload identities?
KW’s Managed IT team can help Mid-Michigan organizations inventory app registrations, tighten roles and consent, and keep recovery controls in the ransomware conversation.
Microsoft documentation used for educational commentary. See original pages for full guidance:
Microsoft Security Blog – Storm-3168 (September 25, 2026) –
The Register – JadePuffer coverage (September 28, 2026)
Technology @ Your Service
KW Corporation – 307 W. Grand River Ave, Fowlerville, MI 48836 – 517-223-3610 – support@kw-corp.com