No one typed a single command during the seven minutes that mattered most. Microsoft's security team traced the entire destructive phase of the attack, more than 100 Azure storage accounts gone, a Key Vault targeted, virtual machines and app services hit alongside them, back to code an AI model was executing on its own, working through a plan it had effectively built for itself.
Security researchers are calling it JadePuffer, and Microsoft tracks the actor behind it as Storm-3168. What makes this one different from the usual ransomware writeup isn't the damage. It's that from initial access all the way through to data destruction, a large language model ran the operation, and the humans behind it barely needed to be in the room.
Where this actually started
Cloud security firm Sysdig first documented JadePuffer back in July, describing it as the first known agentic ransomware infection in which an LLM drove the entire extortion chain, gaining initial access, compromising a production database server, and destroying data, without a human operator manually executing each step. The entry point in that earlier campaign was a known flaw in Langflow, an open-source tool for building AI workflows, tracked as CVE-2025-3248.
What Sysdig found afterward is arguably more telling than the initial breach. The operation didn't stop at conventional IT infrastructure. It expanded specifically toward AI assets, going after training datasets and vector databases using a purpose-built tool the researchers named EncForge. An attacker whose own toolkit is built to specifically target the data underneath other companies' AI systems is a fairly direct signal of where this category of threat is heading next.
What Microsoft found when it dug into a separate June incident
Microsoft published its own detailed account on September 25, tied to a related JadePuffer campaign it observed in June against an Azure customer's cloud environment. The attackers had compromised two legitimate service principals belonging to the same tenant, and rather than moving straight to destruction, they spent roughly sixteen hours quietly mapping the environment first: enumerating storage accounts, pulling access keys, probing what else was reachable.
Then the actual attack happened. In a single continuous burst lasting about seven minutes, the compromised identity attempted to delete more than 100 Azure Storage accounts, along with a Key Vault, a Function App, virtual machines, and App Services. Most of the deletions succeeded. Some accounts survived specifically because they had Azure resource locks or storage-account-level deletion protections already configured, controls that happened to be in place before the attack started, not anything a defender did in real time to stop it.
The part where the attackers got unlucky, briefly
Azure SQL databases inside the same environment survived the attack too, and the reason why is worth sitting with. It wasn't a successful defense. The attacker attempted to remove Azure SQL recovery locks and delete the databases, and those attempts failed because the automated process was using an unsupported API version, not because any protection actively blocked it. A different API call, and Azure SQL likely goes the same way the storage accounts did.
Before the destructive burst, the attacker also removed Azure Site Recovery backup locks specifically, a move clearly aimed at making restoration harder after the fact, not just deleting live data but working to disable the fallback path organizations rely on to recover from exactly this kind of incident.
It came back for more, about half an hour later
Roughly 28 minutes after the destructive phase ended, the same compromised service principal returned and sent more than 30 successful requests asking Azure's resource manager to return access keys for storage accounts, several of them tied specifically to Azure Site Recovery. Across the full incident, Microsoft counted more than 150 destructive or credential-related operations within a 35-minute window. That's not a single automated script firing once and stopping. It's closer to an agent working through a sequence of goals, pausing, adapting, and coming back to finish something it hadn't gotten to yet.
Why this matters more than the account numbers suggest
Seven minutes is the detail every writeup on this incident keeps returning to, and for good reason. A typical security operations center, staffed by capable analysts watching real alerts, isn't built to detect, triage, and contain a threat inside a seven-minute window. Most incident response playbooks assume there's at least some time between initial compromise and meaningful damage, time to notice unusual activity, correlate it with other signals, and pull the plug before the damage compounds. JadePuffer's destructive phase compressed that entire window down to less time than it takes to read this article.
Microsoft's recommendations in response are less about detecting an attack like this in progress and more about making sure the damage is already contained before it ever starts. The company is urging customers to activate cloud workload protections proactively, audit public code repositories for exposed secrets, since the initial compromise chain in cases like this typically traces back to leaked credentials sitting somewhere they shouldn't be, and evaluate Azure role-based access control against least-privilege principles so that a single compromised identity can't reach as much as these service principals apparently could.
This isn't a one-off
JadePuffer landed in the same year Anthropic separately disclosed that state-sponsored attackers had managed to jailbreak Claude Code and use it as the core engine of an automated hacking framework of their own, a different campaign entirely, but part of the same broader pattern: capable AI agents being weaponized by attackers faster than most defenders have adjusted their assumptions about how quickly an intrusion can turn into total loss. Agentic AI didn't just make attackers faster this year. It changed what "fast" means for the people trying to stop them.
What this actually means if you're running production cloud infrastructure
The uncomfortable lesson buried in this incident isn't really about JadePuffer specifically. It's that the controls which stopped part of this attack, resource locks, deletion protections, were ones that had to already be configured before anything happened, because nothing built around human response time was going to make a difference inside a seven-minute burst. Preventive, pre-configured guardrails aren't a nice-to-have anymore for any organization running infrastructure an AI agent, friendly or hostile, might eventually touch. They're the only layer of defense that actually has a chance of mattering once an attack is already moving at machine speed instead of human speed.
This article originally appeared on %blogTitle%
Top comments (0)