In early June 2026, an AI-driven operator tracked as JadePuffer (Microsoft: Storm-3168) used two compromised Azure service principals to map a tenant, then made 100+ storage account deletion attempts in about seven minutes. Most succeeded. It also deleted a Key Vault, a Function App and its App Service plan, tried to delete SQL databases and backup locks, and pulled storage account keys with 30+ ListKeys calls.
There was no malware and no exploit inside Azure. Every action was a normal Azure Resource Manager (ARM) call, allowed by roles the identities already held.
Who is JadePuffer / Storm-3168
JadePuffer is an agentic threat actor: its attack capability is run by an LLM agent, not a human at a keyboard. Sysdig named it in July 2026 and called it the first documented agentic ransomware operation. Microsoft tracks the same operator as Storm-3168 and matched the Azure activity to the same infrastructure and tooling.
Why it matters: the whole chain ran at machine speed. The agent wrote its own payloads, fixed its own errors (in one case, a failed login to a working fix in 31 seconds), and ran many actions in parallel. The destructive phase was faster than any human SOC could detect, triage, and respond. The only Azure resources that survived were the ones protected before the attack started.
Separate intrusions; only the Azure credential-exposure path is hypothetical.
Sysdig’s first case and Microsoft’s Azure case are two different campaigns by the same operator. This post focuses on the Azure campaign and uses the first case for background.
Attack Chain
Every step is a normal ARM API call made with a stolen identity. The agent never needed to escalate privilege; it inherited over-broad RBAC roles and ran deletes in parallel. Only resources protected before the attack survived.
1. Initial Access
Microsoft could not confirm how the service principal was first compromised and gives two possible paths:
- Credential exposure (most likely). An employee of the victim had posted the service principal’s client ID, client secret, and tenant ID in plaintext in a public GitHub issue. The issue was later edited to remove the secret, but it stayed readable in the issue’s public edit history. Editing or deleting a post does not invalidate the secret. Any credential seen in public must be treated as compromised and rotated.
- Application probing. Since early 2026, Storm-3168 infrastructure has probed Azure App Service apps for sensitive paths (WordPress admin, PHP-CGI, and Langflow’s code-validation endpoint
/api/v1/validate/code). But those App Service targets did not overlap with the affected subscriptions, and Microsoft found no App Service-to-ARM credential path in this tenant.
2. Privilege Escalation
The Azure report documents abuse of existing privileges, with no new role assignment or privilege-escalation exploit reported. Two service principals were compromised in one tenant. One performed discovery; the other also destroyed resources and collected credentials. Microsoft traced the second principal’s actions to these permissions:
| Existing Azure role | Assignment | Authorized activity |
|---|---|---|
| Storage Account Contributor | Through a group | Storage-account destruction |
| Contributor | Direct | Application-resource deletions and one additional key retrieval |
| SQL DB Contributor | Direct | SQL database deletion attempts |
3. Lateral Movement (Discovery)
In early June 2026, the first service principal enumerated virtual machines, subscriptions, resource groups, and resources for about 15 hours 30 minutes, with 300+ successful read operations. This gave near-complete visibility into the tenant. About 90 minutes in, the second service principal swept VMs and resource groups across two subscriptions in five seconds. Both used the same Storm-3168 infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.
4. Command & Control
Microsoft did not observe a classic C2 channel in the tenant; the activity was API calls to ARM from attacker infrastructure. The agentic coordination was the signature. The destructive service principal held five unique OAuth tokens: four for deletion, one for storage inventory and key retrieval. Two deletion tokens were active in the same 70-second window, one on storage and one on a mix of storage and SQL. This parallelism across resource types, at this speed, supports automated execution.
Microsoft did not identify a specific AI model or a victim-host C2 implant in this Azure case. Sysdig’s AI assessment rests on richer evidence, including explanatory payload comments and a failed-login correction within 31 seconds. These observations support its agentic assessment; speed alone does not establish AI control.
5. Exfiltration
About 30 minutes after the final destructive activity, the second principal issued more than 30 successful ListKeys requests, including against recovery-related storage accounts. Each was the ARM operation Microsoft.Storage/storageAccounts/listKeys/action, which returns an account’s primary and secondary access keys; the inventory step before it used Microsoft.Storage/storageAccounts/read to list the accounts. Targets included keys for Azure Site Recovery storage.
This confirms credential collection, not data exfiltration. Microsoft did not confirm stolen data.
6. Impact
In total the second service principal ran 150+ destructive or credential-collection operations in 35 minutes, with the core destructive burst lasting about 7 minutes:
- 100+ storage account deletion attempts; most succeeded.
- A Key Vault, a Function App, and its App Service plan deleted (one resource group).
- SQL database deletions attempted in parallel, but all failed, because the agent used an unsupported API version for the SQL resource type. This was the agent’s own mistake, not a defense.
- Multiple failed attempts to delete Azure Site Recovery locks and Azure Backup protection locks, aimed at the victim’s recovery path.
What survived was protected before the attack: storage accounts with Azure resource locks or storage-level deletion protection. Locks are enforced by the ARM control plane independently of RBAC, so the lock check blocks deletion even when the identity has Contributor rights. No ransom note was seen and no exfiltration confirmed, but the mix of destruction, attacks on recovery, and key collection lines up with ransomware and extortion goals.
MITRE ATT&CK Mapping
| ID | Technique | Tactic |
|---|---|---|
| T1078.004 | Valid Accounts: Cloud Accounts | Initial Access / Defense Evasion |
| T1526 | Cloud Service Discovery | Discovery |
| T1485 | Data Destruction | Impact |
| T1490 | Inhibit System Recovery | Impact |
| T1486 | Data Encrypted for Impact | Impact |
| T1552.001 | Unsecured Credentials: Credentials in Files | Credential Access |
Detection and Hardening
The destructive burst was ~7 minutes, so a human SOC cannot win that window. The real defensive interval is the ~16 hours of reconnaissance before it, plus passive controls set up in advance.
Detection signals (the recon window):
- Bulk read operations on subscriptions and resource groups beyond an app’s normal pattern.
- Service principal sign-ins from IPs or ASNs not seen before for that identity.
- High-volume
ListKeysrequests against storage accounts. - Any attempt to delete Azure Site Recovery or Azure Backup protection locks. Treat as an active incident.
Hardening for non-human identities:
- Least privilege on service principals. The group-granted Storage Account Contributor role gave the blast radius. Scope RBAC to what the app needs, not what was convenient at deploy time.
- Resource locks and deletion protection, broadly. Apply them to production storage and to all backup and recovery infrastructure. They are enforced by ARM independently of RBAC, and they are what survived here.
- Rotate any exposed credential, immediately. Editing or deleting the post does not help; copies live in edit history, caches, and archives. Treat exposure as compromise.
- Protect recovery resources as part of ransomware resilience. Monitor and restrict changes to backup and recovery locks.
IOCs (Storm-3168 infrastructure, from Microsoft): 45.131.66[.]106, 34.153.223[.]102, 64.20.53[.]230.
Could an AI agent do this to you?
The service principal that wiped this tenant didn't need to escalate. It already had everything it needed through a group assignment nobody was watching. SlashID maps your non-human identities to show what they can reach and which ones can delete critical resources.
References
[1] Microsoft Security Research, “Storm-3168: Agentic-driven cloud attacks using compromised service principals,” September 25, 2026. https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/
[2] Sysdig Threat Research Team, “JADEPUFFER: Agentic ransomware for automated database extortion.” https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion
[3] BleepingComputer, “JadePuffer agentic AI attacks target Azure, destroy cloud resources.” https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/
[4] BleepingComputer, “JadePuffer ransomware used AI agent to automate entire attack.” https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack/
[5] Aviatrix Threat Research Center, “JadePuffer Storm-3168 Azure Agentic AI Attacks.” https://aviatrix.ai/threat-research-center/jadepuffer-storm-3168-azure-agentic-ai-attacks-2026/
[6] Tech Times, “AI Ransomware Wiped 100 Azure Accounts in 7 Minutes.” https://www.techtimes.com/articles/328096/20260928/ai-ransomware-wiped-100-azure-accounts-7-minutes-only-pre-configured-locks-survived.htm
