What Microsoft's Jadepuffer Azure attacks mean for builders

What Microsoft's Jadepuffer Azure attacks mean for builders

If you run apps on Azure, the story that landed this week is not about a clever new zero-day in your framework. It is about what happens when an attacker already holds a workload identity, then moves at machine speed.

Microsoft Security Research published a deep dive on Storm-3168, also known as JadePuffer. Sysdig first called it out in July 2026 as an agentic ransomware-style operation. Microsoft's write-up, covered widely around September 25-28, 2026, shows how that actor used compromised service principals to map an Azure tenant, delete core resources in roughly seven minutes, and then collect storage account keys.

For builders shipping SaaS, internal tools, or agentic workflows on Azure, this is less a headline and more a checklist. The attack path looks a lot like ordinary cloud administration until the deletes start landing.

What Microsoft actually observed

Microsoft says two compromised service principals in the same tenant split the work.

One spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups, and other resources. That run alone produced more than 300 successful read operations. About 90 minutes after that first identity started, a second principal enumerated virtual machines and resource groups across two subscriptions in about five seconds. Both used Storm-3168-linked infrastructure and the same user agent fingerprint.

Later, the second principal poked at App Service configuration stores (possibly hunting for exposed credentials) and tried a ListKeys call against a storage account that did not exist. Less than a second after that failed ListKeys call, destructive activity began.

In about 35 minutes Microsoft counted 150+ destructive or credential-related operations. The main wipe window lasted about seven minutes and included more than 100 storage account deletion attempts. Most of those storage accounts were deleted. An Azure Key Vault, a Function App, and an App Service plan in the same resource group also went away.

Not everything worked for the attacker:

• Azure resource locks and storage account-level deletion protection blocked some storage deletions.
• Attempts to delete Azure SQL databases failed because the calls used an unsupported API version.
• Attempts to remove Azure Site Recovery locks and Azure Backup protection locks also failed.

About 30 minutes after the wipe sequence ended, the same principal inventoried storage accounts and made 30+ successful ListKeys requests, including accounts tied to Site Recovery. Microsoft did not observe a ransom note or confirm data exfiltration in this case, but the pattern (destroy data paths, interfere with recovery, then collect keys) lines up with ransomware and extortion playbooks.

How the door may have opened

Microsoft could not confirm the exact initial access path. It did find that one service principal's client ID, client secret, and tenant ID had previously appeared in plaintext in a public GitHub issue filed by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained visible in the public edit history.

That detail matters more than it sounds. Removing a leaked secret from a post does not revoke it. Caches, forks, scrapers, and GitHub's own history can keep it alive. Until you rotate or revoke the credential, it is still a valid key.

Microsoft also noted broader probing from Storm-3168-linked infrastructure against Azure App Services for other customers (WordPress admin paths, PHP-CGI, LangFlow's /api/v1/validate/code endpoint, and similar). Those App Service targets did not overlap with the wiped subscriptions in this case, but they show the actor is hunting cloud app footholds, not only leaked ARM secrets.

Why this is different from a classic break-in

Classic intrusion stories often center on a human operator clicking through a portal or running a custom script over hours. Here, Microsoft highlights coordinated automation: multiple tokens for the same principal, overlapping deletion windows, and role-following behavior that stayed inside existing RBAC grants.

In other words, once the identity was valid, the rest looked like aggressive ops automation. A group-granted Storage Account Contributor role authorized the storage wipes. Direct Contributor access covered the application-resource deletions and one key retrieval. Direct SQL DB Contributor access authorized the (failed) SQL deletes.

That is the uncomfortable part for builders. You do not need a novel Azure privilege escalation if a service principal already has Contributor-class rights over the things that matter. Agentic or heavily scripted tooling simply compresses the time between "recon done" and "storage gone."

Practical takeaways for Azure builders

1. Treat public secret exposure as a full compromise

If a client secret, connection string, or storage key ever lands in a public issue, gist, CI log, or screenshot, rotate it immediately. Editing the post is cleanup theater. Assume copies exist.

Prefer short-lived credentials and managed identities where the platform allows it. Long-lived client secrets in app registration settings are a standing invitation.

2. Least privilege is not a slogan when deletes are this fast

Review every service principal and managed identity that can delete storage, Key Vaults, Function Apps, or App Service plans. Split read-only inventory roles from write/delete roles. If a CI bot only needs to deploy one Function App, it should not be able to wipe every storage account in the subscription.

Ask a blunt question in your next design review: if this identity were stolen tonight, what is the blast radius in seven minutes?

3. Put locks and deletion protection in front of the important stuff

In Microsoft's case, resource locks and storage deletion protection actually stopped some deletes even when the identity had broad permissions. That is a rare kind of good news. Use CanNotDelete locks on production resource groups, enable storage soft delete and immutable where appropriate, and treat backup vaults as crown-jewel resources with their own tighter RBAC.

Also monitor attempts to remove those locks. Storm-3168 tried. Failed attempts are useful signals.

4. Protect recovery paths like production data

The actor went after Site Recovery locks, Backup protection locks, and storage accounts with terraform or backup-themed names. If your recovery plane shares the same overpowered identity as your app plane, ransomware-aligned automation will try to cut both at once.

Separate the identities that run apps from the identities that manage backups. Alert on Delete or Modify operations against Recovery Services and Site Recovery resources.

5. Hunt for agent-speed identity abuse, not only malware

Hundreds of read ops over many hours, then a seven-minute burst of deletes, then ListKeys half an hour later is a timeline your SOC should be able to surface. Enable Defender for Resource Manager, Storage, Key Vault, App Service, and Databases if you rely on those workloads. Watch for unusual ListKeys volume, mass delete sequences, and ARM traffic from unexpected IPs or user agents.

Microsoft also frames this as part of a wider shift toward AI-orchestrated attacks that move with more speed and scale. Whether every step was LLM-directed or tightly scripted, the defensive lesson is the same: human-paced playbooks will lose races measured in minutes.

A short builder FAQ

Is this only an Azure problem? No. The pattern is cloud-identity abuse plus automated post-compromise. AWS roles, GCP service accounts, and Kubernetes service accounts can all become the same kind of blast radius if secrets leak and privileges are wide.

Did Microsoft confirm AI agents ran every step? Microsoft describes coordinated automation and situates JadePuffer in the agentic ransomware conversation started by Sysdig. Timing, token use, and role-following strongly indicate automated or scripted execution. Treat the operational speed as the fact that matters for your controls.

What should I do this week?

1. Search GitHub, issue trackers, and CI logs for Azure client secrets and storage keys.
2. Rotate anything that was ever public.
3. Audit Contributor and Owner grants on service principals.
4. Add resource locks to production storage and recovery resources.
5. Turn on the relevant Defender for Cloud plans and alert on mass deletes and ListKeys spikes.

The bottom line

JadePuffer's Azure activity is a reminder that the most valuable "vulnerability" in many cloud estates is still a leaked workload identity with delete rights. Microsoft's case shows how quickly that can turn into missing storage accounts, a deleted Key Vault, and a pile of freshly retrieved access keys.

If you build on Azure, assume attackers will automate the boring middle of the kill chain. Your job is to shrink what any one identity can destroy, make recovery hard to sabotage, and notice the seven-minute window before it finishes.