Microsoft: a leaked Azure app secret let attackers wipe storage accounts in seven minutes

On September 25, 2026, Microsoft Threat Intelligence described an intrusion in which attackers used a stolen Azure application credential — posted in plaintext in a public GitHub issue by an employee of the affected organisation — to destroy cloud resources at machine speed: about 15 and a half hours of quiet reconnaissance, then roughly seven minutes in which more than 100 storage accounts were targeted for deletion. If your organisation uses Azure service principals, find every secret that has ever touched a public repository and rotate it. Editing the post does not revoke the key.

What happened, in plain English

A service principal is the Azure equivalent of a login for software rather than a person. A deployment script, a monitoring tool or a CI/CD pipeline uses one to talk to Azure. It authenticates with three values — a client ID, a client secret and a tenant ID — and it usually has no multi-factor authentication and no human watching it. Think of a spare key cut for the cleaning contractor: it opens the building, it is not tied to a face, and nobody notices it being used at 3 a.m.

According to Microsoft, an employee of the affected organisation had pasted those three values in plaintext into a public GitHub issue. The text was later edited, but GitHub keeps an issue's edit history publicly visible, so the secret stayed readable. Microsoft's note on this is the single most useful sentence in the report: removing or redacting an exposed secret does not invalidate it. Only rotation does.

In early June 2026 someone used that credential. The first compromised service principal spent about 15 hours and 30 minutes inventorying the tenant, with more than 300 successful read operations; a second started its own enumeration about 90 minutes later. Then the tone changed. Microsoft describes a destructive sequence lasting roughly seven minutes with more than 100 attempts to delete Azure Storage accounts, and more than 150 destructive or credential-collection operations inside 35 minutes. Most targeted storage accounts were deleted. Every SQL database deletion failed, because the script called an unsupported API version. Resource locks and storage deletion protection stopped several others.

Microsoft tracks the actor as Storm-3168 and associates it with JADEPUFFER, documented by Sysdig in July 2026. One Azure tenant was affected; no ransom note was found, and Microsoft says it did not confirm data exfiltration.

Are you affected? What to do now

You should care if your organisation has any Azure subscription with service principals or app registrations — which is essentially every organisation using Azure at scale. This was not a vulnerability in an Azure product, so there is no patch. It is a credential-hygiene and blast-radius problem, and the fixes are configuration work.

A checklist, roughly in the order worth doing it:

• Hunt for leaked secrets, including in history. Search your public GitHub, GitLab and Bitbucket presence for client secrets and connection strings — issue and pull-request edit histories, commit history, gists, wikis and CI logs, not just current file contents. Scanning that only looks at the tip of the default branch misses exactly this case.
• Rotate anything that was ever exposed, without waiting to confirm abuse. Deleting or editing the post does nothing. In Microsoft Entra ID, this means creating a new client secret or certificate on the app registration, cutting over, and deleting the old one.
• Inventory your service principals and cut their permissions. Look for principals holding Owner or Contributor at subscription or management-group scope; most need far less. Least privilege for service principals and workload identities is Microsoft's own recommendation here.
• Prefer credentials that cannot be pasted into a chat window. Managed identities and workload identity federation remove the long-lived client secret altogether. That is the structural fix.
• Turn on the brakes that actually worked here. Azure resource locks (CanNotDelete) and storage account deletion protection blocked part of this attack. Also enable soft delete and versioning on storage, and immutability on backup vaults.
• Protect backup and recovery separately. The attackers went after Azure Site Recovery and Backup protection locks, and harvested storage keys — 30 or more successful ListKeys requests, including on Site Recovery storage accounts. Backups that share an identity and a blast radius with production are not backups.
• Alert on the pattern, not just the indicators. A burst of ListKeys calls, a spike in delete operations in the Azure Activity Log, or a service principal suddenly enumerating a whole subscription are all cheap alerts. Seven minutes is shorter than most on-call escalation paths, so this calls for automated containment — disabling the principal — rather than a ticket.
• Check exposure to opportunistic probing. Microsoft observed Storm-3168 infrastructure probing WordPress administration paths, PHP-CGI and LangFlow's code-validation endpoint (/api/v1/validate/code). If you run Langflow, patch it and keep that endpoint off the internet.
• IOCs published by Microsoft (IPs used for App Service probing and malicious Azure Resource Manager requests): 45.131.66[.]106, 34.153.223[.]102, 64.20.53[.]230. Worth a retrospective search; not worth blocking as a long-term control.
• Awareness point for developers and support staff: a credential pasted into a public issue, a screenshot or a support ticket is burned the moment it is posted. The reflex should be "rotate it, then tidy the post" — not the other way round.

If you have no Azure footprint, there is nothing to do here beyond the general lesson about secrets in public places.

The expert view

The interesting part of this report is not the destruction; it is the timing profile, and the question of how much of it was AI.

Microsoft's own evidentiary claim is deliberately narrow. The blog's wording is that "the timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution." Five distinct tokens were issued for the service principal used for destruction and credential collection, two of them active within the same 70-second window; destruction began less than a second after a failed ListKeys call. That is a strong signal of parallel, programmatic execution. It is not, on its own, evidence that a language model was in the loop. A competent Bash script with xargs -P produces the same shape.

The "agentic" framing comes from the actor link rather than from this telemetry. Microsoft associates Storm-3168 with JADEPUFFER, which Sysdig described in a July 1, 2026 report as the first documented case of agentic ransomware — an extortion operation Sysdig assessed to be driven end-to-end by a large language model, entering through CVE-2025-3248, an unauthenticated code-execution flaw in Langflow, then pivoting to a production database host. Sysdig's most persuasive detail was adaptive: a failed backdoor login followed 31 seconds later by a corrected payload, which is the behaviour of something reasoning about an error rather than replaying a script. Sysdig did not name the model or tooling. So the honest reading of the September 25 report is: a threat actor previously observed using an LLM agent has now been seen running a fast, parallelised, destructive cloud operation — and Microsoft is inferring automation, not demonstrating autonomy.

The distinction matters less than it looks, because the defensive conclusion is the same either way. What has genuinely changed is the compression of the timeline. The skill and patience that used to separate "attacker has a valid credential" from "attacker has destroyed the estate" is exactly the part automation removes first. Enumerate-then-destroy against a cloud control plane is an almost ideal task to hand to a machine: the API is documented, failures are cheap, and stealth stops mattering once deletion begins. A 35-minute window is roughly the lower bound of a human-paced incident response.

The rest is familiar, and that is the point. Initial access was a leaked secret, not a novel exploit. The controls that worked were unglamorous ones from the last decade of cloud hardening: resource locks, deletion protection, and an API-version mismatch that happened to save the SQL databases. So the strategic response is not an AI-specific product but reducing what a single non-human identity can do in its first five minutes, and automating your own containment to run at attack speed.

What remains unknown: Microsoft offers no country or named-group attribution, no motive beyond the inference that deleting backup and recovery resources is consistent with impairing recovery, and neither confirms exfiltration nor reports a ransom demand. Whether a model, a script, or a person with good tooling drove the two service principals is not settled by the published evidence.

Official sources

• Microsoft Security Blog — "Storm-3168: Agentic-driven cloud attacks using compromised service principals", September 25, 2026
• Sysdig — "JADEPUFFER: Agentic ransomware for automated database extortion", July 1, 2026
• Coverage: The Hacker News — "JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources", September 28, 2026
• Coverage: Security Affairs — "Storm-3168, Linked to JADEPUFFER, Abused Stolen Azure Identities", September 28, 2026
• Coverage: CyberPress — "Storm-3168 Uses Compromised Service Principals to Launch Agentic Attacks on Azure Cloud", September 26, 2026