Storm-3168: Agentic-driven cloud attacks using compromised service principals

What it is

Microsoft's technical writeup of Storm-3168 (JADEPUFFER) activity in a single compromised Azure tenant, built on timestamped telemetry: two compromised service principals, five distinct OAuth tokens issued to the destructive identity, and specific RBAC role assignments that authorized each stage of the attack.

How it works

Two service principals split roles. SP1 ran reconnaissance for ~15.5 hours (300+ read operations across VMs, subscriptions, resource groups). SP2 started 90 minutes later, enumerating two subscriptions in 5 seconds, then 16 hours later probed App Service config stores (likely hunting for embedded credentials) and unsuccessfully searched for OpenSearch resources. 70 seconds after a failed ListKey call against a non-existent storage account, SP2 began destruction: 150+ destructive/credential operations in 35 minutes, with the core deletion burst lasting 7 minutes. Five unique tokens were issued to SP2 — four for deletion, one for storage inventory/key retrieval; two deletion tokens overlapped for the same 70-second window, one doing pure storage deletion, the other mixing storage and SQL deletion, indicating parallel scripted execution rather than a single serial script. Each destructive action mapped directly to an existing RBAC grant: a group-granted Storage Account Contributor role authorized the storage deletions, direct Contributor access authorized the Key Vault/Function App/App Service plan deletions, and direct SQL DB Contributor access authorized the (failed) SQL deletion attempts. A sibling storage account in the same resource group as the deleted Key Vault/Function App was deliberately spared and instead targeted later via a successful ListKeys call — suggesting the actor distinguished between resources to destroy versus resources to harvest.

Preconditions / Affected

Exploits an Azure tenant where service principal credentials (client ID, client secret, tenant ID) had been posted in plaintext in a public GitHub issue by an employee; the secret was later redacted, but remained retrievable via the issue's public edit history. Requires the compromised identity to hold Storage Account Contributor, direct Contributor, and SQL DB Contributor roles for the full blast radius observed.

What to do

• Treat any credential ever posted publicly as compromised permanently — editing/deleting the post does not invalidate it; rotate/revoke immediately and audit historical use.
• Audit and restrict RBAC grants to service principals to least privilege (the group-granted Storage Contributor role was the single biggest enabler of mass deletion).
• Apply resource locks and storage-account-level deletion protection — these were the only controls that blocked some deletions in this incident.
• Monitor/restrict modification of Azure Site Recovery and Backup protection locks specifically, since removing them was a targeted step.
• Enable Defender for Resource Manager, Storage, Key Vault, App Service, and Databases plans.

Caveats

Microsoft could not confirm the leaked GitHub secret was actually the initial access vector. SQL database deletion attempts all failed due to an unsupported API version — not a security control. No ransom note or confirmed data exfiltration was observed; the ransomware/extortion framing is inferred from the pattern (deletion + recovery-lock targeting + key harvesting), not demonstrated.