Storm-3168 Azure Attack: Compromised Service Principals Delete Storage Accounts

Microsoft Security Research published the findings on September 25, 2026. It ties the activity to JADEPUFFER, the group that Sysdig reported in July. Microsoft tracks the group as Storm-3168. Microsoft says this is its first detailed look at the group's Azure activity, and that it shows the group's cloud operations are changing.

This isn't a Windows desktop story. It is an identity story, and anyone who runs Azure subscriptions, CI/CD pipelines or app registrations with client secrets should read it.

Who is JADEPUFFER?​

Sysdig coined the name. Its Threat Research Team called it what it assesses to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM). In that case, Sysdig said the operator gained initial access to an internet-facing Langflow instance through CVE-2025-3248. It then pivoted to a production database server and ran a destructive database-extortion playbook.

Sysdig's claim is more nuanced than "the robots did it." Michael Clark, Sysdig's senior director of threat research, told CyberScoop that "A human still set up and pointed the operation and provisioned the infrastructure behind it, the command-and-control server, the staging server used for the stolen data and chose a victim". CyberScoop also reported that the actor's origins are unknown and it doesn't overlap with any established ransomware group or nation state.

That matters for reading Microsoft's report. Sysdig's "agentic" label describes what Sysdig saw in its own case. Microsoft's Azure evidence shows automation. It does not show that an AI agent was making the decisions.

Section summary: Storm-3168 is Microsoft's name for JADEPUFFER, which Sysdig describes as the first documented agentic ransomware operator. Microsoft's report adds the actor's Azure activity.

The timeline: 15 hours of looking, 7 minutes of deleting​

Microsoft saw two compromised service principals in the same tenant. One did reconnaissance only. The other did reconnaissance, deletion and credential collection.

1. Broad enumeration. In early June 2026, the first principal listed virtual machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes. It completed more than 300 successful read operations, enough to map the organization's Azure estate.
2. A fast second pass. About 90 minutes after that started, the second principal listed VMs and resource groups across two subscriptions in five seconds. Both principals used Storm-3168-linked infrastructure, the same network fingerprint and the user agent python-requests/2.34.2.
3. Searching for secrets. Sixteen hours later, the second principal listed Azure App Service configuration stores. Microsoft says it was possibly looking for exposed credentials. It also tried, and failed, to find Azure OpenSearch resources.
4. The trigger. Seventy seconds after that last inventory call, it attempted a ListKey operation against a storage account that didn't exist. Less than one second later, the deletions began.
5. Destruction. Over 35 minutes, the principal attempted more than 150 destructive or credential-collection operations. The destructive part lasted about seven minutes and included more than 100 storage account deletion attempts. Most of those accounts were deleted.
6. Key collection. About 30 minutes after the last deletion, the same principal listed storage accounts again. It then made more than 30 successful ListKeys requests, asking ARM to return each account's access keys. Some of those accounts were related to Azure Site Recovery.

A sub-second gap between reconnaissance and a flood of deletions doesn't look like a person clicking through the Azure portal.

Section summary: The attack went from slow mapping to rapid deletion to key collection. The timing points strongly to automation.

What was destroyed, what survived, and why​

Microsoft's accounting of successes and failures is useful for defenders.

The SQL result is the uncomfortable one. The databases survived because of a bug in the attacker's requests, not because the principal lacked permission. Microsoft says direct SQL DB Contributor access authorized every SQL deletion attempt. With a correct API version, the outcome would likely have been different.

The resource locks, by contrast, worked as designed. Microsoft says they show the value of safeguards that still hold "even when a compromised identity has broad administrative permissions."

One more detail: in the resource group where the Key Vault, Function App and App Service plan were deleted, a similarly named storage account was left alone. The same principal later retrieved that account's keys. Microsoft doesn't say why it was spared.

Section summary: Locks and deletion protection saved some resources. The SQL databases survived on luck. Every successful deletion used a role the organization had already granted.

The GitHub secret that didn't go away​

Microsoft doesn't know how the principal was first compromised. It did find that the principal's client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the affected organization. The issue was later edited to remove the secret, but the secret was still readable in the issue's public edit history.

Microsoft is careful here: it could not confirm that this secret was used in the attack. Its guidance is still clear. Editing or deleting a disclosure doesn't invalidate a credential. Anything exposed on the public internet should be treated as compromised and revoked or rotated.

Many engineers assume a quick edit fixes a leak. It doesn't. The secret stays valid until you rotate it, and copies can survive in edit history, caches, archives and logs.

Microsoft also saw repeated probing from Storm-3168-linked infrastructure since the start of the year. It targeted Azure App Services belonging to several customers, on paths tied to WordPress administration, PHP-CGI, web-shell-like URLs and LangFlow's code validation endpoint (/api/v1/validate/code). That fits Sysdig's finding that JADEPUFFER got in through Langflow. However, Microsoft says the probed App Services didn't overlap with the affected subscriptions, and it found no path from App Service to ARM credentials in the victim tenant. The probing is a separate observation, not a confirmed way in.

Section summary: A leaked service principal secret is a plausible entry point but not a confirmed one. Rotate any exposed credential; editing the post doesn't count.

Ransomware-aligned, but no ransom note​

Microsoft calls the activity consistent with tactics that support ransomware and extortion. Its reasons:

• Deletions spread across more than one data service (storage and SQL)
• Attacks on recovery controls, including Site Recovery locks and storage accounts with Terraform- and backup-themed names
• Collection of storage keys that could give access to data

Microsoft also says plainly that it did not observe a ransom note and did not confirm successful data exfiltration. Sysdig's July case ended in encryption, dropped tables and a ransom demand. SOCFortress, summarizing Sysdig's research, noted that the agent created a README_RANSOM table containing a Bitcoin address and a Proton Mail contact. The Azure incident, as documented so far, didn't get that far.

Section summary: The Azure activity looks like ransomware preparation or disruption. Microsoft hasn't confirmed extortion or data theft.

How much of this is "agentic"?​

Microsoft's report is titled "agentic-driven," and it frames the activity as part of a shift toward AI-orchestrated attacks. The evidence it presents is narrower: timing, work split across two principals, and overlapping tokens. Microsoft saw five tokens for the destructive principal. Four supported deletion and the fifth handled inventory and key retrieval. Two deletion tokens were active in the same 70-second window, one deleting storage and the other deleting a mix of storage and SQL.

Microsoft says this "strongly indicates automated or scripted execution." That is not proof that an LLM was in control. A careful Python script could produce the same logs. The python-requests user agent and the unsupported SQL API version fit either explanation.

Microsoft's AI framing also leads into its defensive products: the report promotes Project Perception and Microsoft Defender for AI Security (codename MDASH). They may be useful. But nothing in this incident required AI-specific defenses. Standard hygiene would have limited the damage: rotating secrets, scoping roles narrowly and locking resources.

As Hard2bit put it in its analysis of Sysdig's findings, agents do not need zero-days to cause serious damage. They only need to find what was already exposed, unpatched or full of secrets.

Section summary: The attack was automated, whether by an agent or a script. The defenses that matter are the same either way.

What to do now: an Azure hardening checklist​

Based on Microsoft's recommendations and its Learn documentation:

1. Find and rotate exposed service principal secrets.

• Search repos, issues, wikis, pipeline logs and config files for client secrets. Check edit history too.
• Treat any public exposure as a compromise. Rotate or revoke the credential, then review how it has been used.
• Where possible, replace long-lived secrets with mechanisms that don't depend on them.

2. Shrink service principal permissions.

• Look for broad Contributor assignments on workload identities. In this case, one principal held group-granted Storage Account Contributor, direct Contributor and direct SQL DB Contributor at the same time.
• Include group-based assignments in the review; they're easy to miss.

3. Lock critical storage accounts. Microsoft Learn recommends ARM locks on all storage accounts. For example, with Azure CLI:

az lock create \
  --name <lock> \
  --resource-group <resource-group> \
  --resource <storage-account> \
  --lock-type CanNotDelete \
  --resource-type Microsoft.Storage/storageAccounts

PowerShell users can use New-AzResourceLock -LockLevel CanNotDelete. Know the limits:

• A CanNotDelete lock blocks deletion of the account but not reads or configuration changes.
• A storage account lock does not protect the containers or blobs inside it from being deleted or overwritten. Use blob data protection features as well.
• A ReadOnly lock also blocks the List Keys operation, which would have stopped the key-harvesting calls in this incident. It also blocks all POST operations and can break clients that use keys, including Azure Files and Table workloads. Test before applying it widely.

4. Stop relying on shared keys. Microsoft Learn recommends Microsoft Entra ID authorization with managed identities over storage account keys. Where compliance allows, disable Shared Key authorization entirely. Where keys are unavoidable, rotate them on a schedule; Microsoft documents a dual-key pattern using Key Vault and Event Grid. Note that rotating a key invalidates any account-level SAS tokens created from it.

5. Protect recovery infrastructure. Restrict who can change Azure Backup and Site Recovery resources, and alert on attempts to remove their locks.

6. Turn on relevant Defender for Cloud plans. Microsoft names Defender for Resource Manager, Storage, Key Vault, App Service and Databases. Its listed detections include ARM operations from suspicious proxy IP addresses, unusual Key Vault operation patterns, and unusual volumes of blob or file-share data being extracted. Microsoft doesn't claim these plans would have stopped this attack; treat them as detection coverage, not a guarantee.

7. Hunt for the published indicators. Search ARM activity logs and App Service logs for:

• 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

Also look for bursts of storage ListKeys calls, mass delete operations from a single service principal, and the python-requests user agent coming from workload identities that don't normally use it.

Section summary: Rotate leaked secrets, narrow roles, lock storage, move off shared keys, protect backups, and hunt for the published IPs and behaviors.

The bottom line​

The Storm-3168 incident is ordinary cloud security failures run at machine speed. Microsoft says the attack followed the victim's own role assignments exactly, and deleting most of the targeted storage took about seven minutes. Whether an LLM or a script was driving, the lessons are the same. Every workload identity is a potential admin account for an attacker. A secret posted in a GitHub issue stays valid until it's rotated. And controls like resource locks and deletion protection, which don't depend on permissions, still worked after the identity was compromised.