JadePuffer Azure Attacks Turn Compromised Identities Into Destructive Access

JadePuffer’s Azure attacks show how quickly compromised cloud identities can become destructive. Microsoft Security Research observed two attacks in June by the operator it tracks as Storm-3168: the destructive stage lasted seven minutes and targeted more than 100 Storage accounts, along with Key Vaults, Function Apps, Virtual Machines and App Services (Microsoft’s observations).

Two service principals, different roles

Storm-3168 used two compromised service principals in the same Azure tenant. These identities let applications and automated tools authenticate and access assigned resources. One principal handled reconnaissance and resource discovery; the other was used for discovery, destructive operations and credential collection (the incident account).

Microsoft could not determine how the attackers first gained access. However, credentials for one of the service principals had appeared in a public GitHub issue before the attacks (Microsoft’s findings). That detail makes exposed secrets a concrete part of this incident, rather than a hypothetical entry point.

The report describes JadePuffer’s Azure activity as agent-driven. It does not establish that Microsoft verified every action as autonomously performed by an AI agent. The distinction matters: the observed damage came through compromised identities and their Azure permissions, while the precise degree of AI autonomy in these attacks is not specified (the report on the Azure activity).

Deletions were fast, but not uniform

Storm-3168 deleted most of the targeted Storage accounts. Some remained unaffected because Azure resource locks and storage account-level protections blocked deletion (the reported outcomes). The attackers also attempted to delete Azure SQL databases, but those attempts failed because they used an unsupported API version. That failure was specific to the API version, not evidence that SQL databases were generally protected.

About half an hour after the wipe attempts, the attackers made more than 30 requests for Storage account keys, most of which succeeded (Microsoft’s account of the follow-up activity). The sequence shows that the activity included credential collection as well as resource deletion. A fast destructive burst can therefore sit inside a broader effort to discover resources and gather access credentials.

Recovery protections were part of the target

The attackers removed Azure Site Recovery locks, which could make restoration harder, while other attempts to remove recovery protection locks failed (the reported recovery activity). Protections mattered in more than one way: some storage resources resisted deletion, and recovery safeguards were also directly tested or targeted.

Microsoft recommends enabling cloud workload protections, checking public repositories for exposed secrets, and reviewing Azure RBAC permissions against least-privilege principles (its mitigation guidance). The incident gives those steps a clear operational rationale: a service principal’s assigned access can determine how much damage follows credential exposure, while preconfigured resource protections can change which deletions succeed.

Microsoft did not confirm data theft or report financial demands in the two observed cases (the incident report). The activity could support ransomware extortion, but the evidence establishes destructive operations and successful key requests, not that extortion or data theft occurred.