Microsoft details Storm-3168: an Azure secret left in a GitHub issue led to 15.5 hours of recon, then a 7-minute run deleting storage and Key Vault.
Microsoft has detailed an Azure intrusion in which a single service principal secret, exposed in a public GitHub issue, led to roughly 15.5 hours of quiet reconnaissance and then a 7-minute run of deletions. The actor, tracked as Storm-3168, is linked to JADEPUFFER, the operation Sysdig documented in July as the first reported agentic ransomware campaign. ThreatFrontier covered that earlier case in JadePuffer AI Ransomware Marks First Fully Agentic Extortion Campaign. This follow-up moves the same actor from a vulnerable application into the cloud control plane.
The affected organisation is not named. Microsoft says the activity began in early June 2026. Most of the targeted storage accounts were deleted, along with one Key Vault, one Function App and one App Service Plan. No ransom note was observed and no data exfiltration was confirmed.
How the attacker got in
An employee had posted a service principal's client ID, client secret and tenant ID in plaintext in a public GitHub issue. The secret was later redacted, but it remained readable through the issue's public edit history. Microsoft's point is blunt: removing or redacting an exposed secret does not invalidate it. Only rotation does.
What the activity looked like
The first principal ran read-only enumeration across virtual machines, subscriptions, resource groups and resources. Over about 15 hours 30 minutes it made more than 300 successful read calls. About 90 minutes after that began, a second principal started enumerating across two subscriptions, and later queried App Service configuration stores. Both principals used the same client, python-requests/2.34.2.
The second principal held Storage Account Contributor, direct Contributor and SQL DB Contributor access. About 70 seconds after its inventory calls, destruction began. Over a 7-minute sequence it made more than 100 storage account deletion attempts, and across about 35 minutes it made more than 150 destructive or credential-collection calls. Roughly 30 minutes after the last deletion it issued more than 30 successful ListKeys requests, including against storage accounts tied to Azure Site Recovery.
Not everything worked. Every Azure SQL database deletion failed because of an unsupported API version. Resource locks and storage account deletion protection stopped some storage deletions, and attempts against Site Recovery and Azure Backup protection locks were unsuccessful.
How firmly this is "agentic"
Microsoft's evidence is tempo and structure: five unique tokens issued in sequence, parallel deletions across Storage and SQL, and behaviour that stayed inside the permissions the principal held. It says these indicators strongly indicate automated or scripted execution. The post itself does not prove autonomous reasoning. The agentic label comes from the link to Sysdig's JADEPUFFER research. Some press coverage goes further, saying a database was destroyed; Microsoft's own account says the SQL deletions failed. Treat the AI-agent framing as credible but inferred.
Separately, infrastructure tied to the actor probed several customers' App Services for WordPress administration paths, PHP-CGI and Langflow's code validation endpoint (/api/v1/validate/code). Microsoft lists these addresses:
45.131.66[.]106 App Service probing and malicious ARM requests
34.153.223[.]102 App Service probing
64.20.53[.]230 App Service probing
Microsoft maps the activity to T1190, T1078.004, T1526, T1485 and T1490.
What defenders should do
Microsoft's guidance, with our reading of what it means in practice:
- Rotate exposed credentials immediately. Assume any secret that ever appeared in a public issue, commit or paste is burned, whatever the edit history now shows.
- Protect and continuously assess application credentials and secrets. Scan repositories and issue trackers for client secrets, and prefer managed identities or workload identity federation over long-lived secrets.
- Apply least privilege to service principals. The second principal could delete storage because it was allowed to. Review which principals hold Contributor-level roles.
- Protect backup and recovery infrastructure. Resource locks, storage deletion protection and Backup and Site Recovery locks demonstrably blocked part of this attack. Treat them as ransomware resilience controls.
- Enable Defender for Cloud plans for Resource Manager, Storage, Key Vault, App Service and Databases, so suspicious ARM operations and mass deletions raise alerts.
Hunting leads that follow from the report (our reading, not Microsoft's list): service principal sign-ins from the listed IPs, python-requests user agents on ARM calls, bursts of ListKeys, and long read-only enumeration followed by delete calls.
The gap that matters is time. Fifteen and a half hours of recon is a long window for detection, and 7 minutes is far too short for a human response once deletions begin. Controls have to be in place before the first delete call.