Seven Minutes, 100 Azure Accounts Gone. Here Is How JadePuffer Did It.

Key points

• Microsoft's security team found that JadePuffer, tracked internally as Storm-3168, deleted more than 100 Azure cloud storage accounts in a single seven-minute burst in June 2026.
• The attackers got in using a valid credential that had been posted publicly in a GitHub issue before the attack, not through any novel hacking technique.
• Sysdig first identified JadePuffer in July 2026 as the first documented ransomware operation to use AI agents, software that takes a goal and figures out the steps itself, to carry out attacks.
• Microsoft saw no ransom note and confirmed no data theft in the two incidents it examined, but the attackers did strip out recovery locks, the controls that stop victims restoring from backup.
• One AI agent called an outdated cloud programming interface when trying to delete SQL databases, causing those deletions to fail, a mistake a human attacker would likely have caught and corrected.

As first reported by ThreatVectr, a criminal group called JadePuffer spent roughly seven minutes in a victim's Azure cloud environment in June 2026 and deleted over 100 storage accounts before anyone could stop it. Microsoft's Security Research team has now published the first detailed inside view of that attack, and the findings deserve close attention.

This is our third story tagged to JadePuffer since we first covered the group on 29 July 2026, with our earlier piece on AI agents accessing real systems without permission now reading as context for exactly the kind of damage those agents can cause.

How did the attackers get in?

Through a door someone left open. The attackers logged in with two legitimate Azure service principals, the non-human accounts that apps and automation scripts use to talk to cloud services. Microsoft found that the secret key for one of those accounts had been posted in a public GitHub issue before the attack, the digital equivalent of writing a building's alarm code on the front door.

Service principal accounts are frequently over-privileged and rarely rotated, which makes them a favourite target. There was nothing novel about the entry point. What came next is what makes this case different.

What did the AI agents actually do?

Once inside, they moved fast. An AI agent, a program that takes a goal and works out the individual steps on its own, mapped the cloud environment, collected storage account keys, then began deleting resources in bulk. Microsoft logged destruction attempts across Azure Storage Accounts, SQL databases, Key Vaults (secure storage for passwords and encryption keys), Function Apps, Virtual Machines and App Services. The agents also tried to remove recovery protection locks, the controls that normally prevent someone from wiping backups.

The SQL database deletions failed. The agent called an Azure programming interface version that Microsoft no longer supports. A human operator would almost certainly have noticed the error and retried with a current version. This agent moved on.

No ransom note appeared. Microsoft confirmed no data was exfiltrated in either of the two incidents it examined, and no victim has appeared publicly on JadePuffer's leak site.

Should this change how companies protect their cloud accounts?

Yes, and the fix isn't complicated. The agentic framing grabs headlines, but the actual way in was a secret that should never have been public. Speed and automation are genuinely new risks: wiping 100 accounts in seven minutes is something most incident-response teams aren't built to match. The underlying cause, though, is familiar.

Microsoft's guidance points to four concrete actions: protect workload identities and treat service principal secrets like master passwords, enforce least privilege so non-human accounts can only do exactly what they need, keep resource locks and backup protections on, and enable Microsoft Defender for Cloud's relevant alerts.

In these two incidents, the resource locks that survived were the only reason any data was saved at all. That's the practical lesson here, and it has nothing to do with AI.

If your team has ever pasted a cloud credential into a GitHub issue or a shared document, treat that credential as compromised and rotate it now. Watch for automated alerts about bulk resource deletions, service principal logins from unusual locations, and any notification that a recovery lock has been removed.