Storm-3168 Agentic Cloud Attacks: Compromised Service Principals, Seven Minutes, Too Much Access

Every tenant I have ever inherited has at least one service principal named something like deploy-automation-final2, created in a hurry, granted Contributor “just until the pipeline works,” and never looked at again. It is the IT equivalent of the spare key under the doormat, except the doormat is the internet and the key opens every room. That habit is exactly what the newly documented Storm-3168 agentic cloud attacks ran on: service principals that already had more permission than anyone remembered giving them, used against the tenant that created them.

On September 25, Microsoft published its analysis of Storm-3168 and its Azure-focused destruction, the first detailed look at this actor inside Azure. It’s worth reading in full. It’s also worth reading carefully, because the headline and the evidence aren’t quite the same size.

Who Storm-3168 Is

Storm-3168 is Microsoft’s name for JADEPUFFER, an operator Sysdig’s threat research team documented in July. Sysdig’s report, JADEPUFFER: Agentic ransomware for automated database extortion, assessed that campaign to be “the first documented case of agentic ransomware,” an extortion operation driven end-to-end by a large language model. JADEPUFFER got in through an exposed Langflow instance (CVE-2025-3248), harvested credentials, pivoted to a production MySQL and Nacos server, and encrypted 1,342 configuration items before dropping a ransom table.

Sysdig’s case for an AI at the controls was specific: payloads full of self-narrating comments, a failed login fixed with a corrected multi-step payload in 31 seconds, and behavior that only made sense if the operator actually read the natural-language text it found. That is real evidence, and it is about the Langflow and database campaign.

What Happened in Azure

Microsoft’s investigation covers a single impacted tenant and two compromised service principals from that tenant, each with a job. Starting in early June 2026, the first one spent about 15 and a half hours enumerating virtual machines, subscriptions, resource groups and resources, with more than 300 successful reads. Roughly 90 minutes after that started, the second one enumerated VMs and resource groups across two subscriptions in five seconds. Both used Storm-3168-linked infrastructure, the same network fingerprint and the same python-requests/2.34.2 user agent.

Sixteen hours later, the second identity went through App Service configuration stores, likely looking for credentials, and tried a ListKey against a storage account that did not exist. Less than a second after that failed, the demolition started:

• More than 150 destructive or credential-related operations attempted over 35 minutes.
• A destructive burst of about seven minutes, including 100+ storage account deletion attempts, most of which succeeded.
• A Key Vault, Function App and App Service plan deleted, all supporting the same application.
• Failed attempts to remove Azure Site Recovery and Azure Backup protection locks.
• About 30 minutes after the last deletion, 30+ successful ListKeys calls to collect storage account access keys, including Site Recovery storage.

Microsoft calls the pattern consistent with ransomware and extortion tactics, but it says plainly that it saw no ransom note and could not confirm data exfiltration.

How Agentic Were the Storm-3168 Agentic Cloud Attacks on Service Principals?

Here is where the framing matters. Microsoft’s headline says “agentic-driven,” and the post describes a broader shift toward AI-orchestrated attacks. But its technical evidence for the Azure activity is narrower. Microsoft says the timing, the split of work across service principals and the overlapping token streams “strongly indicates automated or scripted execution.” It saw five tokens on the destructive identity, and two deletion tokens were active in the same 70-second window. That is machine speed. It is not, on its own, proof of a language model making choices.

The agentic label comes from the attribution to JADEPUFFER, and there is solid connective tissue there. Two IP addresses in Microsoft’s indicators, 45.131.66[.]106 and 64.20.53[.]230, also appear in Sysdig’s July report, and Microsoft saw Storm-3168 infrastructure probing Langflow’s code validation endpoint on App Services. So “an actor previously assessed as agentic, doing automated destruction in Azure” is fair. “AI attack crew” is a step further than the Azure evidence goes, which is why this post isn’t titled that way.

The funniest detail supports that caution. Every Azure SQL database deletion failed because the tooling used an unsupported API version for that resource type. Whatever was driving this, it got stopped by the same versioning trap that has eaten a few of my Friday afternoons.

The Part That Is Actually Our Fault

No privilege escalation shows up in this story. As Security Affairs summarized it, the attackers didn’t need to escalate anything because the access was already there. Microsoft lays out the plumbing: a group-granted Storage Account Contributor role authorized the storage deletions, direct Contributor covered the Key Vault, Function App and App Service plan, and direct SQL DB Contributor covered the failed database attempts.

Nobody hacked those permissions. Somebody assigned them, probably for a pipeline, probably with good intentions, and possibly through a group nobody audits because groups feel safer than direct assignments. They aren’t. A group is just a direct assignment with fewer witnesses.

How the principal was first compromised is unclear, and Microsoft is careful here. It found that the client ID, secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the victim organization. The issue was later edited, but the secret stayed visible in the edit history. Microsoft could not confirm that this secret was the one used. The lesson holds either way: redacting a secret is not rotating it.

What I Would Do This Week

1. Inventory service principals with Contributor or broader roles, including roles inherited through groups. If a principal can delete a storage account, ask why.
2. Scope automation to the resource group it actually touches. Deployment identities rarely need subscription-wide delete rights.
3. Put resource locks and storage deletion protection on anything you can’t rebuild. In this incident, those controls held when RBAC did not.
4. Rotate anything that has ever touched a public issue, repo or paste. Deleting the post doesn’t count. Prefer managed identities or federated credentials over long-lived client secrets.
5. Keep backup and recovery out of reach of the identities that run production. Microsoft specifically called out attempts to remove Site Recovery and Backup locks.
6. Alert on non-human identities that suddenly start enumerating everything or calling ListKeys in bulk. Service principals are creatures of habit, so a break in routine is signal.

Whether the thing at the keyboard was a language model or a very fast Python script, the outcome was decided months earlier, by whoever granted that Contributor role and moved on. Attackers are getting faster. Our permission hygiene is the part we actually control.