Duration of the deletion stage: 7 minutes (Source: Microsoft Security Research, via BleepingComputer (September 28, 2026))
The identity doing the work was a machine
The most useful detail in Microsoft's account of JadePuffer is not the speed. It is whose identity did the work. BleepingComputer reported on September 28, 2026 that Microsoft Security Research studied two June attacks by the actor it tracks as Storm-3168. Both ran on compromised service principals, the identities software uses to prove itself to Azure and to reach the resources assigned to it. The two identities belonged to a single tenant.
The lesson here is that this exposure sits outside the human-centred controls many programmes are built around. Access reviews, MFA rollouts and phishing training address people. A service principal has no inbox to phish and no phone to approve a prompt, so once its credentials leak, it can do whatever its permissions allow.
Microsoft could not establish how the intruder first got in. Its only pointer is timing: a public GitHub issue had carried the credentials of one of the two identities before the attacks began. That is a sequence, not a confirmed cause, and it should be read that way. It is still a concrete reason to ask where machine secrets end up.
Seven minutes, more than 100 storage accounts
Microsoft describes a split in roles. One identity scouted the environment. The second also scouted, then carried out deletions and gathered credentials. Between them, the attacker inventoried cloud resources, pulled storage account keys and deleted storage accounts. The target list reached past storage to compute and secrets services: App Services, Function Apps, Virtual Machines and Key Vaults.
The scale of the loss matters. As BleepingComputer reports Microsoft's findings, the attacker deleted most of the targeted storage accounts. Only some were left untouched.
Microsoft also says the attacker removed Azure Site Recovery locks, which it reads as an effort to make restoring harder. No ransom demand was reported and data theft was not confirmed in the observed cases, so any link to extortion remains an inference.
Where the human-speed assumption strains
Sysdig, a cloud security company, has described JadePuffer as a tool that uses AI agents across its whole operation, from reconnaissance through to encryption. The malware emerged in July, and Sysdig later noted a shift toward AI assets, training datasets and vector databases through a tool called EncForge. The sources do not say the seven-minute window was a product of AI automation, and we do not claim it was.
The question for a budget-holder is narrower. Many recovery plans assume an intruder who works at human pace, leaving hours to notice and respond. Seven minutes across more than 100 accounts leaves a person on call very little room. In that setting, protections that work without anyone intervening carry more weight.
Three outcomes that are easy to blur
Microsoft's account holds three separate results. The first is partial protection: some storage accounts came through untouched, which Microsoft attributes to Azure resource locks and storage account-level protections. The second is a failed attempt against Azure SQL databases. Those deletions failed because the attacker used an unsupported API version, so no defensive control deserves the credit. The third is that some attempts to strip recovery protection locks did not succeed, and the account offers no explanation. Because Site Recovery locks were also removed, the picture on recovery protections is mixed.
Only the first outcome is evidence that a control worked, and it saved only part of what was targeted. A plan cannot count on the second repeating, and the third is unexplained.
About thirty minutes after those attempts, Storm-3168 returned and asked for storage account keys more than 30 times. Most of the requests succeeded. The return visit suggests that restoring data is not enough; the identities themselves have to be revoked and keys rotated. That is our reading. Microsoft's account does not describe how the affected organisation responded.
Questions to put to your cloud team
Microsoft's guidance includes three steps: turning on cloud workload protections, searching public repositories for exposed secrets, and checking Azure RBAC permissions against least privilege. Here is how they translate into questions for your team.
First, how many service principals does the tenant have, who owns each one, and which can delete storage or remove recovery locks? Second, does any single identity both explore the environment and hold the rights to delete? In this case, the second identity did both discovery and deletion. Third, are public repositories and issue trackers scanned for secrets, including text pasted into support threads? Fourth, would anyone be alerted to repeated storage-key retrievals, and is there a defined step for rotating keys afterward? Fifth, which high-value resources have locks, and has anyone tested whether those locks hold when an authenticated identity tries to remove them?
A credential appeared in a public issue, and a configuration choice protected some storage accounts. Both are decisions an organisation makes long before an incident begins.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.
