An Agent Wiped 100 Azure Storage Accounts in Seven Minutes. It Never Had to Escalate a Single Permission.

The version of this story that travelled this week is simple and loud. An AI agent broke into Microsoft's cloud and destroyed a company's infrastructure. Sysdig named the operator JADEPUFFER and called it the first documented ransomware crew to let an LLM drive the whole extortion chain. Microsoft tracks the same actor as Storm-3168. On 25 September, Microsoft's security research team published the first detailed look at what that actor did inside Azure, and the part worth your attention is quieter than the headline.

Nothing was escalated. Every destructive call ran on permissions the identity already had.

What Microsoft's timeline actually shows

Two service principals from the same Azure tenant were compromised before the activity began. Service principals are the machine identities applications use to authenticate to Azure, and they are often the least-watched credentials in a tenant, because no human ever signs in with them.

One of the two spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups and resources, and completed more than 300 successful read operations. Researchers Yossi Weizman and Tushar Mudi put the value of that plainly. "This breadth of activity would give the threat actor visibility across the organization's Azure environment."

About 90 minutes into that run, the second service principal swept virtual machines and resource groups across two subscriptions. It took five seconds. Both identities used Storm-3168-linked infrastructure and carried the same user agent, python-requests/2.34.2.

Sixteen hours later, the second identity enumerated App Service configuration stores, which Microsoft reads as a hunt for exposed credentials. Seventy seconds after that, it tried a ListKey call against a storage account that did not exist. Less than a second after the failure, the deletion started.

The Register, which reported the research on 28 September, characterises the whole operation as spanning about 18 hours.

Seven minutes, more than a hundred deletions

The destructive sequence lasted roughly seven minutes and involved more than 100 attempts to delete Azure Storage accounts. Most succeeded. An Azure Key Vault, a Function App and an App Service plan in the same resource group, all apparently supporting the same application, went with them. Across the wider 35-minute window, Microsoft counted more than 150 destructive or credential-collection operations.

Three things survived, and each one tells you something different.

Azure resource locks and storage account-level deletion protection blocked a handful of the deletion attempts. Microsoft's conclusion is the line to keep: resource locks and deletion protection "remain effective even when a compromised identity has broad administrative permissions."

The parallel run at Azure SQL databases failed completely, and not because a defender stepped in. The attacker's tooling used an unsupported API version for the SQL database resource type, so the platform rejected every call. A bug in the attacker's own script protected those databases better than any control in the environment.

The third survivor is not good news. A storage account in the same resource group that the deletion pass skipped over was later hit with a successful ListKeys call. About 30 minutes after the destruction ended, the same identity inventoried storage accounts and fired more than 30 successful ListKeys requests, asking Azure Resource Manager to hand back access keys. Those accounts included ones tied to Azure Site Recovery.

That is the detail Ross Filipek, CISO at Corsica Technologies, says moves the recovery problem. "The recovery question here goes beyond rebuilding what was deleted," he said. "The attackers later requested storage account keys, potentially giving them another route to data."

The permissions were the whole attack

Here is what should reshape how you read the phrase AI-orchestrated attack. Microsoft traced every destructive operation back to role assignments the identity already held. A group-granted Storage Account Contributor role authorised the storage deletions. Direct Contributor access covered the three application resource deletions. Direct SQL DB Contributor covered the failed database attempts. The attacker never needed to escalate, because the standing permissions were broad enough to finish the job unaided.

The evidence for automation is timing and parallelism rather than a smoking gun. Microsoft observed five unique tokens issued for the destructive identity, four of them handling deletion, two of them active inside the same 70-second window, one working storage while the other worked storage and SQL. The researchers write that the division of work and the overlapping token streams "strongly indicates automated or scripted execution."

Not everyone reads it as AI-directed. Nick Tausek, lead security automation architect at Swimlane, draws the distinction carefully. "I agree with Microsoft's warning about AI-orchestrated attacks, though the Azure evidence shows coordinated automation rather than proving AI directed each step," he said. His point about response speed survives that caveat intact: "At that speed, an AI SOC needs to connect identity activity with cloud changes before the damage spreads."

Microsoft is just as careful about the ending. The activity is "consistent with tactics that can support ransomware and extortion operations," the researchers write, followed immediately by the caveat that "we did not observe a ransom note or confirm successful data exfiltration in the activity described here."

The credential that stayed live

Microsoft could not confirm how the identities were first taken. It did find that the client ID, client secret and tenant ID for one of them had been posted in plaintext in a public GitHub issue by an employee of the affected organisation. The issue was later edited to remove the secret. The edit did not remove the exposure, because GitHub keeps public edit history.

"As a practical matter, publicly exposed credentials remain usable until revoked or rotated," Microsoft writes, and "removing the original disclosure alone does not remediate the exposure." The firm also states it could not confirm whether that secret was the one used here, which is an important limit on the story rather than a footnote.

Filipek's framing is the one to carry into your own environment. "Once attackers hold an application identity, their activity can look like ordinary cloud administration," he said. There is no odd login to trip an alert, no unfamiliar user to investigate. There is a service account doing exactly what its role permits.

What the operator does next matters more than this incident

This is the same actor Sysdig documented in July, and its trajectory has been published step by step. The July campaign used CVE-2025-3248 in Langflow, a missing-authentication flaw in the /api/v1/validate/code endpoint that CISA added to its exploited-in-the-wild catalog in May 2025, and encrypted 1,342 Nacos configuration records with a key that was never stored, so the data was unrecoverable even for a victim willing to pay.

The follow-up research is the part that should interest anyone running AI on their own metal. Sysdig found the same operator staging ENCFORGE, a compiled Go locker built specifically for machine learning infrastructure, targeting roughly 180 file extensions that include model checkpoints, vector indexes, and training datasets in parquet, arrow and NumPy formats. Sysdig's estimate of what it costs to rebuild a single production-grade fine-tuned model runs from $75,000 to $500,000, and a single run encrypts every variant stored on the same host. If the training data sits on that host too, Sysdig notes, recovery is blocked until the dataset is reconstructed first.

Encrypted business files can be restored from backup. Encrypted model weights usually cannot, because restoring them means re-running weeks of training. That is a different kind of downtime than most continuity plans are written for.

Microsoft's own answer to machine-speed offence is more AI on the defensive side, through programmes it calls Project Perception and MDASH. That is a reasonable response to an 18-hour reconnaissance window. It is a weaker answer to a seven-minute deletion burst, which is why the boring controls did the real work here.

What this means if your product runs in somebody's cloud

Hardware companies no longer ship a box and walk away. The product line now extends into telemetry pipelines, digital twin data, test-bench results and PLM state, and most of that lands in object storage behind a set of machine identities that were provisioned once during integration and never reviewed again. Those identities are exactly the ones abused here, and the resource locks and backup protection that saved part of this environment are usually owned by a different team than the one shipping the product.

The uncomfortable arithmetic is that the attacker needed about 15 hours of discovery to find the resources, and only seven minutes to remove most of them, while the credential that opened the door may have been sitting in a public comment thread's edit history for months. That asymmetry does not get designed away at deployment time. It gets designed at specification, when somebody decides what the machine identities are allowed to touch, how long they live, and whether the recovery path has been tested against an attacker that has legitimate administrative rights.

At DMC, we work with hardware and electronics teams building exactly this kind of cloud-connected product infrastructure, and the questions that come up in those engagements are rarely about detection tooling. They are about identity sprawl across device fleets, standing permissions inherited from a pilot that nobody revisited, and recovery plans that assume the credentials are still trustworthy. If your cloud-connected roadmap is growing faster than your credential life-cycle, now is a reasonable moment to pressure-test the seven-minute scenario against your own architecture. Let's talk.

Sources: Microsoft Security Blog, "Storm-3168: Agentic-driven cloud attacks using compromised service principals," 25 September 2026 (Microsoft Security Research, Yossi Weizman and Tushar Mudi); Sysdig Threat Research Team, JADEPUFFER research, July 2026; The Register, 28 September 2026; CSO Online and Dark Reading, 28 September 2026, for the Tausek and Filipek commentary.