JadePuffer-Linked Storm-3168 Hijacks Azure Identities to Destroy Cloud Resources

Agentic Attack Wipes Over 100 Azure Storage Accounts in Minutes

Microsoft Security Research disclosed on September 25, 2026 that it observed Storm-3168 — the threat actor Microsoft tracks as being linked to JadePuffer, the group Sysdig identified in July 2026 as running the first publicly documented agentic ransomware operation — conduct a highly automated, destructive attack against a single Azure tenant. Using two compromised service principals (machine identities that let applications and automated tools authenticate to Azure), the actor spent roughly 15.5 hours quietly mapping the environment before pivoting into a 35-minute burst of over 150 destructive and credential-collection operations, including the deletion of more than 100 Azure Storage accounts in about seven minutes. Microsoft says it did not observe a ransom note or confirm successful data theft, but characterized the destruction, attempts to disable recovery mechanisms, and credential harvesting as consistent with tactics that support ransomware and extortion operations.

Incident Details

How the Attack Unfolded

Initial access through a leaked GitHub secret

Microsoft traced the intrusion back to a service principal's credentials — a client ID, client secret, and tenant ID — that an employee had pasted in plaintext into a public GitHub issue. The issue was later edited to remove the secret, but the original value remained visible in the public edit history. Microsoft used this as a case study to reiterate a point defenders often overlook: editing or deleting a GitHub comment does not invalidate the credential it exposed — only rotation does.

Fifteen and a half hours of quiet reconnaissance

Once armed with valid credentials, the first compromised service principal began enumerating the tenant: virtual machines, subscriptions, and resource groups, executing more than 300 successful read operations over roughly 15.5 hours. This phase generated no destructive activity — it was pure mapping, the kind of low-and-slow discovery that blends into normal automation traffic and rarely trips alerts tuned for obviously malicious behavior.

A second identity takes over in seconds

About 90 minutes after the first principal began its reconnaissance, a second compromised service principal — sharing the same infrastructure and the same python-requests/2.34.2 user agent as the first — enumerated virtual machines and resource groups across two subscriptions in just five seconds. Roughly 16 hours later, this second identity probed App Service configuration stores and Azure OpenSearch resources, then attempted a ListKey operation against a storage account that did not exist. Less than a second after that failed lookup, the destructive sequence began.

Seven minutes of destruction, then a credential grab

The second principal — which held group-granted Storage Account Contributor rights along with direct Contributor and SQL DB Contributor access — used those legitimate-looking permissions to delete more than 100 Azure Storage accounts in about seven minutes, part of a wider 35-minute window that totaled over 150 destructive or credential-collection operations. In the same resource group, the actor also deleted a Key Vault, a Function App, and an App Service plan that all supported the same application. About 30 minutes after the destructive burst, the actor issued more than 30 successful ListKeys requests, pulling storage account access keys — including keys tied to Azure Site Recovery — that could enable future data access even though no exfiltration was confirmed in this incident.

What failed — and why it mattered

Not every destructive attempt succeeded. Efforts to delete Azure SQL databases failed because the attacker's tooling called an unsupported API version for that resource type, despite the compromised identity actually holding sufficient permissions. Attempts to remove recovery-protection locks on backup infrastructure also failed. And critically, some storage accounts survived the deletion sweep entirely because Azure resource locks and storage-account-level deletion protection blocked the requests — a rare bright spot showing that basic hygiene controls can blunt even a fast, automated destruction campaign.

Microsoft also noted it has seen ongoing, repeated probing from Storm-3168-linked infrastructure against Azure App Services belonging to multiple, unrelated customers since January 2026, and assessed that the division of labor between the two service principals — and the tight timing between their actions — points to automated or scripted orchestration rather than a human operator clicking through each step manually.

Impact Assessment

Recommendations

For cloud and identity administrators

• Treat every service principal credential as a live secret: rotate and revoke immediately if it has ever appeared in a public repository, issue tracker, CI log, or chat message — and investigate its historical use, since editing or deleting a public post does not invalidate the credential.
• Apply least-privilege access to service principals; avoid broad Contributor or group-inherited roles when a narrowly scoped role would do.
• Apply and audit Azure resource locks and storage-account-level deletion protection across production subscriptions — Microsoft confirmed these locks blocked some deletion attempts outright.
• Extend delete-protection and access restrictions specifically to backup and recovery infrastructure (Azure Site Recovery, Backup vaults), since it was directly targeted.

For security teams

• Enable Microsoft Defender for Cloud plans covering Resource Manager, Storage, Key Vault, App Service, and Databases to catch anomalous management-plane activity from service principals.
• Hunt for long, low-volume read/enumeration activity from service principals preceding short, high-volume destructive bursts — this pattern (recon, then rapid parallel destruction) is the signature Microsoft describes.
• Watch for the shared python-requests/2.34.2 user agent and the IPs Microsoft disclosed (45.131.66[.]106, 34.153.223[.]102, 64.20.53[.]230) as a starting point for threat hunting, while expecting infrastructure to rotate.

For developers and DevOps teams

• Run repository secret scanning (GitHub secret scanning, gitleaks, or equivalent) across issues, comments, and wikis, not just committed source files — this leak originated in a GitHub issue, not a code file.
• Never paste client IDs, secrets, or tenant IDs into tickets, chat, or support requests, even temporarily; use a secrets manager and reference secrets by name.

Key Takeaways

1. Storm-3168/JadePuffer escalated from a single-server ransomware incident (Sysdig, July 2026) to tenant-wide Azure destruction, showing the group's agentic tooling is being adapted to cloud environments, not just on-premises servers.
2. The intrusion began with a plaintext credential leaked in a public GitHub issue — a mundane, common mistake, not a novel exploit or zero-day.
3. The attack split cleanly into a 15.5-hour reconnaissance phase and a 35-minute destructive phase, using two separate compromised identities — a division of labor Microsoft says points to automated, scripted orchestration.
4. Over 100 Azure Storage accounts, plus a Key Vault, Function App, and App Service plan, were destroyed in roughly seven minutes, with the attacker also targeting (but failing to disable) backup and recovery protections.
5. Azure resource locks and deletion protection saved some storage accounts outright — one of the few effective, low-cost defenses that worked against a fast, automated attacker.
6. Microsoft has observed continued probing from related infrastructure against other Azure customers since January 2026, suggesting this is an active, ongoing campaign rather than an isolated incident.

Sources

• BleepingComputer: JadePuffer agentic AI attacks target Azure, destroy cloud resources
• Microsoft Security Blog: Storm-3168: Agentic-driven cloud attacks using compromised service principals
• The Register: JadePuffer crims hijacked Azure identities and used them to blow up cloud resources
• The Hacker News: JADEPUFFER-Linked Attackers Used Compromised Service Principals
• CSO Online: Autonomous agents attack Azure using compromised identities and destroying resources