JadePuffer Agents Used Stolen Azure Identities to Wipe Storage in a Seven-Minute Burst

An automated attacker spent more than 15 hours reading its way through a company's Azure cloud, then deleted most of the victim's storage accounts in roughly seven minutes. The weapon was not malware. It was two stolen machine identities that already had permission to do the damage.

Microsoft laid out the attack in a detailed write-up on September 25. It tracks the actor as Storm-3168, the same group Sysdig named JADEPUFFER in July and described as the first documented agentic ransomware operation.

Fifteen quiet hours, then a burst

The intrusion ran about 18 hours inside a single tenant in early June. Two compromised Azure service principals, the app and machine identities companies use for automation, shared the same infrastructure fingerprint and the same user agent, python-requests/2.34.2.

The first identity did the scouting. Over about 15 and a half hours it made more than 300 successful reads across virtual machines, subscriptions and resource groups.

The second identity moved fast. It enumerated VMs and resource groups across two subscriptions in five seconds. Sixteen hours later it went through App Service configuration stores, likely hunting for credentials, and then fired off more than 150 destructive or credential operations in 35 minutes.

What got destroyed, and what survived

The core of the wipe lasted about seven minutes and included more than 100 storage account deletion attempts. Most of the targeted accounts were deleted. A Key Vault, a Function App and an App Service plan in the same resource group went too.

Some things held. Azure resource locks and storage-level deletion protection saved a few storage accounts, and attempts to strip Site Recovery and Backup protection locks failed. Parallel attempts to delete Azure SQL databases all failed for a mundane reason: the agent called an unsupported API version.

About 30 minutes after the destruction, the attacker made more than 30 successful ListKeys requests for storage account access keys, including accounts tied to Site Recovery. That pattern of destroying data, crippling recovery and collecting keys fits ransomware, the same playbook seen in the n0n backup-destruction attacks. Microsoft found no ransom note and no confirmed data theft in this case.

Every step was allowed

Nothing here needed an exploit. The identities already held Storage Account Contributor through a group, plus direct Contributor and SQL DB Contributor roles, so each deletion was an authorized API call.

The way in may have been embarrassingly simple. An employee of the victim organization had pasted a client ID, client secret and tenant ID into a public GitHub issue. The post was later edited, but the secret stayed visible in the edit history. Microsoft says it could not confirm that this secret was the one used.

Storm-3168 IPs have also been probing App Services since early 2026, going after WordPress admin pages, PHP-CGI and LangFlow's code validation endpoint, The Hacker News reported. Those targets did not overlap with the subscriptions that were wiped.

The lesson Microsoft draws is blunt: an over-privileged service principal is a loaded weapon, and an agent can pull the trigger faster than any human on call can react. The only things that survived this one were the resources someone had bothered to lock.