A compromised machine identity deleted most of the storage it targeted in about seven minutes, and the only things that held were protections its own permissions could not remove.
—
Microsoft’s account of the Storm-3168 intrusion, published on 25 September 2026 on the Microsoft Security Blog, is the first detailed public view of the Azure activity of the actor Sysdig identified in July 2026 as JADEPUFFER, reported to be the first documented agentic ransomware operation. In one affected tenant in early June 2026, two compromised service principals (application identities, not people) belonging to that tenant were used: one for reconnaissance, one for discovery, destruction and credential collection. The destructive sequence ran for about seven minutes and involved more than 100 storage account deletion attempts. Most of the targeted storage accounts were deleted, along with a Key Vault, a Function App and an App Service plan. Azure resource locks and storage-account-level deletion protection blocked deletion of a few storage accounts. Parallel attempts to delete multiple Azure SQL databases all failed, because the attacker used an unsupported API version for that resource type.
That last detail deserves more weight than it usually gets. The SQL databases survived by accident. The storage accounts that survived did so because someone, at some earlier point, applied a control that the compromised identity’s permissions did not let it remove. Those are different categories of outcome, and a board reading a summary of this incident would be wrong to treat them as equivalent. The signal reaches well beyond Azure and beyond one unnamed victim, because the pattern applies to every cloud estate that runs workloads under machine identities: the size of the loss was settled by permission design long before the attack, not by anything that happened during the seven minutes.
What actually decided the loss
The timeline is worth setting out precisely, because the speed is the point. The first identity spent about 15 hours 30 minutes enumerating virtual machines, subscriptions, resource groups and resources, with more than 300 successful read operations. About 90 minutes after it started, the second identity enumerated VMs and resource groups across two subscriptions in five seconds. Sixteen hours later that second identity enumerated App Service configuration stores, possibly looking for exposed credentials. Less than one second after a failed ListKey call against a non-existent storage account, destruction began. The second identity attempted more than 150 destructive or credential-collection operations in 35 minutes. About 30 minutes after the destruction, it made more than 30 successful ListKeys requests, retrieving storage account access keys, including for Site Recovery related storage accounts.
Nothing in that sequence required privilege escalation. Microsoft’s analysis is explicit that the operations followed the identity’s existing role assignments: a group-granted Storage Account Contributor role authorised the storage deletions, direct Contributor access authorised the three application-resource deletions, and direct SQL DB Contributor access authorised the SQL attempts. The identity already held the rights. It used them at machine speed and then went back for the keys to much of what remained.
Two further details sharpen the picture. Multiple attempts to delete Azure Site Recovery locks and Azure Backup protection locks failed, and storage accounts with terraform- and backup-themed names were targeted, which Microsoft says was potentially intended to impair the victim’s ability to recover. The actor was not only destroying production; it was reaching for the recovery path and the controls protecting it. Microsoft draws the lesson directly, pointing to “the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions.” Where the SQL databases survived, the cause was an unsupported API version, which is luck, not a control.
The distinction matters because of what it implies about detection and response. When the destructive phase runs for about seven minutes, the interval between the first deletion and the loss is shorter than most human escalation paths. Detection still matters for scoping, for the credential theft that followed, and for whatever extortion attempt might come next (Microsoft observed no ransom note and could not confirm data exfiltration, while describing the activity as consistent with tactics that support ransomware and extortion). But detection cannot be what decides the loss. What decides it is whether the compromised identity can, with the permissions it already holds, both destroy production and remove the protection on its recovery copies.
The exposure that looked like remediation
Initial access is not confirmed. What is documented is that the service principal’s client ID, client secret and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the affected organisation. The issue was later edited to remove the secret, but the secret stayed accessible in the issue’s public edit history. Microsoft could not confirm whether that secret was used in the attack. Its broader point stands regardless: “Removing or redacting an exposed secret does not invalidate it”, and publicly exposed credentials “remain usable until revoked or rotated”.
This is the second decision point in the incident, and the quieter one. The cleanup looked like remediation and was not. Ross Filipek, CISO at Corsica Technologies, put the operational lesson plainly in Dark Reading on 28 September 2026: the exposure “is a useful warning about how a routine cleanup can leave an account exposed”, and “once attackers hold an application identity, their activity can look like ordinary cloud administration.” That second sentence is the one for anyone whose detection logic is tuned to human behaviour. A service principal enumerating resources and calling management APIs can be hard to tell apart from routine automation, because routine automation does exactly that.
There is a live disagreement about how much of this was AI-directed. Nick Tausek, lead security automation architect at Swimlane, told Dark Reading that “the Azure evidence shows coordinated automation rather than proving AI directed each step.” That disagreement is real and worth holding open. For the decision at hand, it is also immaterial. Whether the operator was an AI agent choosing its next action or a script executing a playbook, the window in which a human could have intervened was minutes long. The control question is the same either way.
The question to take to the next review
Service principals and other workload identities tend to accumulate standing Contributor-level rights and are reviewed far less rigorously than human administrators. In practice they behave like unaccompanied administrators: often no joiner-and-leaver process, no periodic access review signed off by a named manager, and sometimes no owner who can say what the identity is for. The question senior management should put to cloud platform owners and to whoever owns resilience is narrow and answerable: does any single non-human identity hold, at the same time, the right to destroy production and the right to remove the protection on its recovery copies? If the answer is yes, or unknown, that is the finding. Answering it honestly usually takes the engineers who built the role assignments in the room, not only a posture dashboard, because a group-granted role like the one used here is easy to miss in a review that looks only at direct assignments.
From there the follow-on questions are for CIOs, CISOs, heads of resilience and business continuity, and audit and board risk committees to press on. Which workload credentials and secrets are assessed, and when was each last rotated? When an exposure is found, is the response rotation, or redaction? Which services still rely on long-lived secrets, and what would it take to move them off? Has least privilege been applied to service principals with the same discipline as to human administrators? Are backup and recovery resources restricted to a separate set of identities, and is any attempt to modify or remove their protection controls monitored and alerted on? The recovery point extends an earlier argument that multi-AZ is not the last copy: provider redundancy is not the same as a copy the organisation controls and can recover from. In this incident, the copies that survived deliberately were the ones whose deletion controls sat outside the compromised identity’s reach.
The decision this supports is not a tooling decision. It is a permission design decision, taken once and enforced continuously, about whether the identity that can delete the production estate can also delete the means of recovering it. In this case, for a handful of storage accounts, the answer was no, partly by design and partly by good fortune. For most of the storage accounts it targeted, the answer was yes.