JadePuffer Azure Attack: Stolen Service Principals Wiped Cloud

What happened

Microsoft has published a detailed account of a destructive cloud intrusion attributed to Storm-3168, its name for the actor that Sysdig tracks as JADEPUFFER. Sysdig identified the group in July 2026 and described it as the first documented agentic ransomware operation.12 Microsoft Security Research released its findings on September 25, 2026.23

The attack took place in early June 2026 and lasted about 18 hours.45 The intruders did not need malware on endpoints. They used two compromised Azure service principals, which are non-human identities that applications use to authenticate, and both belonged to the same tenant.14 Each identity had a separate job.

The first identity handled reconnaissance. Over roughly 15.5 hours it completed more than 300 successful read operations, mapping virtual machines, subscriptions, resource groups and individual resources.14 Microsoft suggests a later inventory of App Service configuration stores was a search for exposed credentials.2

The second identity carried out the damage. In about 35 minutes it attempted more than 150 destructive or credential-collection operations.12 The deletion phase took about seven minutes. It included more than 100 attempts to delete storage accounts, most of which succeeded, plus the removal of a Key Vault, a Function App and an App Service plan.2 Microsoft researchers Yossi Weizman and Tushar Mudi list the targets as storage accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, virtual machines and App Services.5 The actor also retrieved storage keys, which Microsoft says could support future exfiltration.14

The missing ransom

The ransomware label fits this incident poorly. Microsoft did not observe a ransom note. It also could not confirm that any data was successfully exfiltrated.3 Some protective controls blocked deletion attempts.3 Microsoft calls the activity an evolution of the group's tradecraft, not a repeat of its earlier playbook.5

This distinction matters. The "agentic ransomware" description comes from Sysdig's earlier characterization of JADEPUFFER.12 None of the reporting on the Azure incident cites specific evidence of autonomous AI tooling. What the timeline does show is a clear split: slow, patient discovery followed by a very fast teardown. Whether the speed came from an AI agent or a well-prepared script, defenders had minutes, not hours, once destruction began.

In practice, this incident looks like a cloud wiper combined with credential harvesting. Victims who lose more than 100 storage accounts face the same outcome whether or not a ransom note appears.

How the attackers got in

Microsoft does not know how Storm-3168 first obtained the service principals. The Register highlighted a key detail from the report: an employee of the victim organization had previously posted client IDs, client secrets and tenant IDs in plaintext in a public GitHub issue.4 Microsoft is careful on this point. It could not confirm that the leaked secret was the credential actually used.3

The sources mostly agree on the facts, but they frame them differently. The Register treats the GitHub exposure as the most plausible entry point.4 A cloud-focused analysis stresses Microsoft's uncertainty and turns the discussion toward recovery controls.3 An identity vendor goes further and argues that the core risk is long-lived client secrets on any platform, including Keycloak, and that organizations should retire them altogether.2

Why it matters

The broader point holds even with caveats about the entry vector. Workload identities often have wide permissions and receive less monitoring than human accounts. Their secrets can sit unchanged for years. A single leaked credential in a public issue tracker gives an attacker a ready-made identity that can delete production infrastructure through normal management APIs.

The two-identity design also deserves attention. Separating reconnaissance from destruction makes each identity's activity look less unusual on its own.2 Detection rules that look for one principal doing everything could miss this pattern.

Ransomware activity remains high elsewhere. For example, the suspected China-linked group Warlock continues to exploit SharePoint flaws to disable security tools and deploy conventional ransomware.5 Storm-3168 stands out because it apparently skipped encryption completely and worked only through the cloud control plane.

The takeaway

Storm-3168 is best understood as a warning about cloud identity hygiene, not as proof that AI-driven ransomware has arrived. The practical lessons are concrete:

• Replace static service-principal secrets with federated or managed identities where possible.
• Scan code and issue trackers for leaked credentials.
• Enforce resource locks and soft-delete protections.
• Alert on bursts of deletion calls from machine identities.

The protections that blocked some deletions in this case show that these controls can work when they are in place.3