The Storm-3168 Azure attack is about credential hygiene, not agentic AI

On 25 September Microsoft Security Research published its first detailed account of what the group it tracks as Storm-3168 did inside one customer’s Azure tenant. The post, written by Yossi Weizman, senior security researcher at Microsoft Defender for Cloud, and Tushar Mudi, security researcher, links the activity to JadePuffer, an actor that Sysdig discovered in July 2026 and that Microsoft says has been reported as the first documented agentic ransomware operation.

In early June 2026, according to the post, one compromised service principal spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions and resource groups, with more than 300 successful read operations. A second service principal from the same tenant then attempted more than 150 destructive or credential-collection operations in 35 minutes. The destructive burst itself lasted about seven minutes and included more than 100 attempts to delete storage accounts, most of which succeeded. A Key Vault, a Function App and an App Service plan went with them. Roughly 30 minutes later the same identity made more than 30 successful ListKeys requests, pulling the access keys for storage accounts, including some tied to Azure Site Recovery.

Microsoft found no ransom note and could not confirm that any data left the tenant. What it describes is destruction, an attempt to reach the backups and a harvest of keys that could support a later extortion.

The label the industry will attach to this is ‘agentic ransomware’. Security leaders should resist it, because nothing in Microsoft’s own evidence for the Azure activity requires an AI agent. The post says the timing and the division of labor between the two identities “strongly indicates automated or scripted execution”. The user agent was python-requests/2.34.2, a stock Python library. The agentic claim belongs to Sysdig’s earlier reporting. Microsoft puts it in its title and introduction, then spends the analysis on something far older: a leaked secret and over-generous permissions.

The secret was in a GitHub issue

Microsoft cannot say how the service principal was first compromised. It does know that the identity’s client ID, client secret and tenant ID had been posted in plain text in a public GitHub issue by an employee of the victim. The issue was later edited, but the value stayed visible in its public edit history. Microsoft adds that it could not confirm this secret was the one used. The lesson it draws does not depend on that. “Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted,” the post says.

Service principals and app registrations are how applications and automation act inside an Azure tenant, whether the software is run in-house or by a supplier. Their secrets can leak from wherever they are stored, and Microsoft’s own list of places to keep them out of is source code, configuration files, public repositories and issues. Suppliers that hold service principals across many customer tenants face the same exposure at scale: a leaked secret for an identity with access to several tenants puts each of them at risk, with the supplier’s access rights attached.

Every deletion was authorized

The second detail matters more than the first. Microsoft says the destructive operations “followed the identity’s existing Azure role assignments”. A Storage Account Contributor role, granted through a group, authorized the storage deletions. Direct Contributor access authorized the application-resource deletions and one key retrieval. A direct SQL DB Contributor assignment authorized the attempts on the databases. Nothing was escalated. The attacker did not need a flaw in Azure, only the permissions someone had already decided this application should have.

The good news in the post concerns guardrails that did not depend on the identity behaving. Azure resource locks and storage-level deletion protection blocked the removal of a few storage accounts. Attempts to delete the Site Recovery and Azure Backup protection locks failed. The database deletions failed too, but only because the scripts called an unsupported version of the deletion interface, which is luck rather than design. Microsoft’s conclusion is that independent safeguards kept working even when the compromised identity held broad administrative rights. Luck does not scale. Locks do.

What to do now

The post’s mitigations recommend a list of Microsoft Defender for Cloud plans, Project Perception agents and a product codenamed MDASH. Those are Microsoft’s claims for Microsoft’s products. The non-product recommendations bear directly on what happened here, and they come down to three questions for the board of any organization that runs on Azure.

First, where do the organization’s service principal secrets live, and who can see them? The answer should be a managed vault with rotation, never a script or a ticket, and the security team should be able to show a scan of its repositories, pipelines and support systems, including edit histories, since Microsoft’s point is that deleting a leak does not revoke it. The same question goes to every supplier holding a credential for the tenant.

Second, what can each of those identities actually delete? The identity in this case held Contributor rights directly and Storage Account Contributor through a group. The post shows what those roles mean when the identity is hostile. Least privilege for workload identities can be reviewed identity by identity, and a board should ask when that was last done, including for the identities suppliers hold.

Third, which controls still hold when the identity itself is the attacker? Resource locks, deletion protection on storage, immutable backups and separate credentials for recovery infrastructure are the difference between a seven-minute outage and a seven-minute extinction. The victim here had some of them, which is why some storage accounts survived.

None of this needs an AI budget. The attackers may or may not have used one; the defenses that worked certainly did not. A security team that cannot answer those three questions does not need agentic defenses. It needs to rotate its secrets and ask the same of every supplier that holds them.