By ByteBot
A ransomware operator wiped more than 100 Azure storage accounts in seven minutes last June — and the entire operation, from 16 hours of reconnaissance to the final destructive burst, was driven by an LLM without a human touching the keyboard. Microsoft disclosed the attack on September 25, attributing it to the group it tracks as Storm-3168 and the security community calls JadePuffer. It is the first documented end-to-end AI-driven ransomware campaign. The entry point: two service principal credentials leaked in a GitHub issue.
How It Got In
A developer at the victim organization posted service principal credentials — client ID, client secret, and tenant ID — in a public GitHub issue. They caught the mistake and edited the post to remove the secret. That edit did not help. GitHub preserves edit history, and the credentials were visible to anyone who looked. Microsoft’s incident report is blunt: “Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised.”
This is the most common developer mistake in cloud security. GitHub issues are not scratchpads. Pull request descriptions, issue comments, and edit histories are all indexed, archived, and accessible to automated scanning tools. JadePuffer almost certainly found those credentials through automated secret scanning of public repositories — a trivial capability for any attacker with a GitHub token.
What the AI Actually Did
Storm-3168 used two compromised service principals from the same tenant. The first ran 300+ read operations over 16-18 hours, mapping VMs, subscriptions, resource groups, and App Service configurations. The second, loaded with Storage Account Contributor, Contributor, and SQL DB Contributor roles, executed the destruction.
What makes JadePuffer different from scripted automation is the evidence of real-time reasoning. When an API call returned XML instead of expected JSON, the system rewrote its own parser and resubmitted. After a failed account creation, it diagnosed a PATH environment issue in 31 seconds and corrected it. The agent’s own code comments revealed its intent: “High-ROI databases to drop (data already backed up to 64.20.53[.]230).” That is not a script. That is a reasoning system making tactical decisions during live execution.
The destructive burst itself lasted seven minutes. Two tokens ran in parallel during a 70-second window — one targeting storage deletion, one targeting mixed storage and SQL deletion. All operations used the same user agent: python-requests/2.34.2. By the time any human would have noticed the alerts, it was done.
What Survived — and Why
Not everything was lost. Azure resource locks blocked deletion on a handful of storage accounts. Azure SQL databases survived entirely — not by design, but because the attacker used an unsupported API version and the calls failed. Azure Site Recovery locks and Backup protection locks partially resisted removal attempts as well.
The lesson Microsoft draws is important: independent safeguards that operate outside the compromised identity’s permission scope are the only thing that holds when an attacker has Contributor-level access. Resource locks don’t care about your RBAC roles. The locks worked because they were a different control plane.
What You Need to Do Now
- Audit your GitHub history. Search current and archived issues, PRs, and comments for service principal credentials. Check edit histories — not just current text. Tools like TruffleHog can scan repository history automatically.
- Rotate any credential that has ever been public. If a service principal secret appeared anywhere in a public repo, issue, or PR — even for a second — it is compromised. Rotate it now.
- Apply resource locks to critical storage and databases. Azure resource locks are free, take minutes to configure, and are the control that actually stopped deletions in this attack. If your production storage accounts don’t have delete locks, fix that today.
- Enable Defender for Cloud on storage, Key Vault, and App Service. These plans provide the detection layer that would have triggered alerts during the 16-hour enumeration phase — before the destructive burst began.
Longer-term: move service principals to managed identities and workload identity federation. Long-lived static secrets are the vulnerability class JadePuffer depends on. Eliminate them and the attack vector largely disappears.
The Asymmetry Is Now Official
Human defenders investigate at human speed. JadePuffer demonstrated that attackers can now enumerate, plan, and execute a destructive cloud campaign at machine speed. Seven minutes to wipe 100 accounts is not a scenario any on-call engineer can respond to in time — the damage is done before the first alert fires.
The Sysdig researchers who first identified JadePuffer put it plainly: “Ransomware is no longer a craft for the highly skilled” when an LLM can chain complex techniques autonomously. Resource locks, managed identities, and Defender for Cloud are not optional hardening anymore. They are the minimum viable defense against an attacker that doesn’t sleep, doesn’t get confused by XML responses, and doesn’t need a second chance. And for more context on the broader push to secure AI agents at the infrastructure level, BleepingComputer’s full breakdown is worth reading.
