150 destructive operations in 35 minutes
Microsoft published an analysis of a cloud intrusion in which an attacker it tracks as Storm-3168 attempted more than 150 destructive or credential-collection operations inside an Azure tenant in 35 minutes. The deletion phase itself lasted about seven minutes and included more than 100 attempts to delete storage accounts.
Sysdig, which first documented the group in July, tracks it as JADEPUFFER and describes it as the first documented ransomware operation driven by a large language model.
The targets were Azure Storage Accounts, where most deletions succeeded; Key Vaults; SQL databases, where deletion attempts failed because the API versions used were unsupported; Function Apps and App Service plans; and the Azure Site Recovery and Azure Backup protection locks — the controls that make restoration possible.
The way in was a public GitHub issue
The entry point is the part defenders should read twice. Microsoft says the attackers used two compromised service principals in the same tenant — the non-human identities that let applications and automated tools authenticate to Azure.
Their credentials, Microsoft writes, “had previously been exposed in plaintext in a public GitHub issue.” The secret was later edited out, but it “remained accessible through the issue’s public edit history.”
Nothing about that requires AI. What the speed suggests is orchestration: Microsoft’s timeline has the first service principal enumerating resources for 15.5 hours, the second starting 90 minutes later, an App Service configuration scan 16 hours in, then the seven-minute destruction phase and a credential-collection sweep 30 minutes after it.
No ransom note
The unusual detail is what did not happen. Microsoft says plainly: “We did not observe a ransom note or confirm successful data exfiltration in the activity described here.”
Yet the attacker removed the backup and recovery locks first, which is what an extortion operation does to make paying the only option. Either the demand came through a channel Microsoft did not see, or the destruction was the point.
Microsoft frames the case as an example of “AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale.” Its own blog does not detail which agentic system Storm-3168 used, and readers should note the distinction: the speed is documented, the attribution of that speed to a model is Sysdig’s characterisation of the group rather than something Microsoft demonstrates in this post.
What to do about it
Microsoft’s mitigations are unglamorous and mostly predate agents: enable Defender for Cloud, keep credentials out of repositories and issue threads, rotate exposed credentials immediately, apply least privilege to service principals, and protect backup infrastructure. It also recommends its own agentic defence tooling.
The transferable lesson is narrower. A secret pasted into a GitHub issue two years ago has always been a risk. What has changed is how little time a defender now has between the credential being found and the storage accounts being gone.
