Seventeen hours of looking, seven minutes of deleting. The SQL databases survived because the attacker used the wrong API version

One tenant, two identities, one morning in June

Microsoft Security Research published its account of Storm-3168 on 25 September 2026. It is Microsoft's name for activity linked to JADEPUFFER, which Sysdig described in July as the first documented agentic ransomware operation. The post covers one Azure tenant, attacked in early June 2026 through two compromised service principals, the non-human identities that applications use to act in Azure.

The sequence, from Microsoft's timings:

• The first identity enumerated virtual machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes, with more than 300 successful read operations.
• Ninety minutes in, the second identity enumerated virtual machines and resource groups across two subscriptions in five seconds.
• Sixteen hours after that, it listed App Service configuration stores. Seventy seconds later it tried to list the keys of a storage account that did not exist.
• Less than one second after that, the destruction began.

That is roughly 17 and a half hours of looking. The destructive sequence itself lasted about seven minutes and included more than 100 storage account deletion attempts, roughly one every four seconds.

What survived, and why, is the part worth studying. Microsoft records three different outcomes, and each has a different cause.

Most storage accounts were deleted. The identity held Storage Account Contributor through a group, and that role permits deletion. Every destructive operation, Microsoft notes, "followed the identity's existing Azure role assignments".

A few storage accounts survived. Azure resource locks and storage account-level deletion protection blocked those attempts. Microsoft calls this "the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions".

Every Azure SQL database survived. Not because of a control. The identity had SQL DB Contributor, which allows deletion, and it tried to delete several databases in parallel with the storage accounts. Every attempt failed "because it used an unsupported API version for the Azure SQL database resource type". The attacker's automation had a bug.

From Microsoft's account of one tenant. Only one row of survivals is explained by a defender's control.

What was targeted	Outcome	What decided it
Most storage accounts, 100+ attempts	Deleted	The identity's role: Storage Account Contributor, granted through a group
A few storage accounts	Survived	Resource locks and deletion protection, configured beforehand
Azure SQL databases	All survived	The attacker's tooling used an unsupported API version
Key Vault, Function App, App Service plan	Deleted	Direct Contributor access
Site Recovery and Backup protection locks	Deletion attempts failed	Not stated by Microsoft
Storage account keys	30+ retrieved with ListKeys	The identity's role

What this does not establish

It does not establish how the identities were compromised. The client ID, secret and tenant ID of one service principal had been posted in plaintext in a public GitHub issue by an employee. The issue was edited to remove the secret, but it stayed visible in the public edit history. Microsoft says plainly that it could not confirm whether that secret was used here.

It does not establish that data was stolen or a ransom demanded. Microsoft saw no ransom note and did not confirm exfiltration. The 30 or more storage keys retrieved after the deletions would give access to data, which is why Microsoft calls the pattern consistent with ransomware and extortion.

And it does not, on its own, show an AI model at work. Microsoft's evidence is the timing and the division of labour: five tokens for one identity, two deleting in the same 70 seconds, one handling inventory and keys. It says this "strongly indicates automated or scripted execution". The agentic label comes from the JADEPUFFER attribution, which rests on Sysdig's earlier research rather than on anything in this tenant. Automation that fast is the point either way.

Why seven minutes changes the question

A seven-minute destructive sequence that starts less than a second after its last reconnaissance call does not leave time for anyone to respond. No alert is triaged, no ticket assigned, no identity disabled inside that window. So everything that mattered was decided before the first deletion.

There were two chances. The first was the 17 and a half hours of enumeration, which is a long time for a workload identity to spend reading across every subscription it can see. The second was the configuration: which resources had locks and deletion protection, and which identities held delete rights they did not need.

The tenant got one of those right for some storage accounts. It kept the SQL databases by luck.

What to do about it

The question this leaves

Three outcomes in one tenant: deleted because the role allowed it, saved by a lock someone had set up, and saved by the attacker's mistake. The third one will not happen twice. Tooling that fails on an API version gets fixed.

So the question for your own cloud estate: if an identity with delete rights went rogue for seven minutes tonight, which of your resources would survive because of something you configured, and which only because the attacker got something wrong?