Someone stole an Azure service principal and wiped storage in seven minutes

Microsoft says the JADEPUFFER operator, tracked as Storm-3168, used two compromised Azure service principals in the same tenant to map a cloud estate, then delete more than 100 storage accounts in about seven minutes. Key Vaults, Function Apps, Virtual Machines, and App Services were in the blast radius. Resource locks and storage deletion protection were the only things that saved a few of the targets.

If your Azure apps authenticate with long-lived client secrets, especially ones that ever appeared in a public GitHub issue or repo, treat this as a morning inventory, not a research paper.

A service principal with Contributor rights is a remote wipe button you forgot you issued.
The 5-Minute Cyber Brief
Don’t Miss the Policy Changes That Affect Security Decisions
Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.
Email address
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.

What happened

Sysdig first described JADEPUFFER in July 2026 as an agentic ransomware operation that automates reconnaissance, credential theft, lateral movement, and encryption. Microsoft Security Research published a Sep 25, 2026 investigation that expands that picture into Azure Resource Manager abuse.

In the observed tenant, one service principal spent more than 15 hours on discovery across VMs, subscriptions, and resource groups. A second principal then ran a compressed destructive window: more than 100 storage account deletion attempts in seven minutes, plus deletions of a Key Vault, Function App, and App Service plan. Parallel Azure SQL deletion attempts failed only because the actor used an unsupported API version. Attempts to remove Azure Site Recovery and Backup protection locks mostly failed too.

About half an hour later the same identity collected storage account keys with more than 30 successful ListKeys calls. Microsoft could not prove the exact initial access path, but one of the principals had its client ID, secret, and tenant ID posted in a public GitHub issue. Editing the issue did not revoke the secret. Storm-3168 linked infrastructure also probed Azure App Service paths related to WordPress, PHP-CGI, and LangFlow across other customers.

Why it matters

This is not a niche edge appliance story. Azure service principals sit under CI/CD pipelines, automation runbooks, and SaaS integrations. When they hold broad Contributor or Storage Account Contributor rights, an attacker who steals the secret can wipe recovery paths and then harvest keys for whatever remains.

The seven-minute clock matters for response design. If your playbook still assumes a human-paced ransomware dialogue, agentic cloud destruction will finish before the war room dials in. Independent resource locks and least-privilege workload identities are what actually bought time here.

What to do first

Inventory workload identities. List every service principal and managed identity with Contributor, Owner, Storage Account Contributor, or Key Vault privileges across subscriptions.
Rotate exposed secrets. Treat any client secret that ever appeared in GitHub, CI logs, tickets, or chat as burned. Revoke it, issue a new credential or switch to federated/managed identity, and review sign-in logs.
Lock recovery. Turn on resource locks and storage deletion protection for backup, Site Recovery, and critical data stores. Confirm Backup and Site Recovery roles are not held by the same automation identity that can delete production storage.
Enable Defender for Cloud signals. Prioritize Defender for Resource Manager, Storage, Key Vault, App Service, and Databases, and alert on unusual ARM deletes and ListKeys spikes.
Hunt the IOCs. Review ARM activity from Storm-3168 linked addresses Microsoft published, and look for python-requests user agents on service principal token use.

Forward this

If you own Azure subscriptions or the CI/CD that deploys into them: please confirm this week that no service principal with broad Contributor rights still uses a long-lived client secret, especially anything that ever landed in GitHub. Microsoft documented Storm-3168 deleting more than 100 storage accounts in seven minutes after stealing workload identities. Ask for a yes or no on resource locks for backup storage and on rotating any leaked app secrets.

Details

Actor: JADEPUFFER / Storm-3168 (Microsoft); first public agentic ransomware write-up by Sysdig, July 2026
Initial access pattern: compromised Azure service principals; one observed secret exposed in a public GitHub issue (edit history retained the value)
Observed impact: 100+ storage account deletion attempts in ~7 minutes; Key Vault, Function App, App Service plan deleted; SQL deletion attempts failed on API version; later ListKeys collection
Defensive saves: Azure resource locks and storage account deletion protection blocked some deletes
IOCs (Microsoft): 45.131.66.106, 34.153.223.102, 64.20.53.230; user agent python-requests/2.34.2
Microsoft guidance: Defender for Cloud workload protections, least-privilege RBAC, secret hygiene, protect backup/recovery controls

Hunt / verify

Query Azure Activity Log for Delete Storage Account, Delete Key Vault, Delete sites/serverfarms, and high-volume ListKeys by service principals in the last 90 days.
Search Entra ID sign-in and audit logs for the three Microsoft-published IPs and for unexpected token issuance on automation apps.
Grep public GitHub (org + personal forks) and internal ticket attachments for azure client_secret, tenant_id, and application_id pairs.
Confirm which identities can modify Backup vaults, Site Recovery locks, and resource locks; remove standing delete rights where possible.

Slack paste: Azure: inventory service principals with Contributor/Storage rights, rotate any client secret that ever hit GitHub, enable resource locks + storage deletion protection on backup stores, alert on ARM deletes/ListKeys spikes (Storm-3168 / JADEPUFFER).

Sources

George Bailey

George Bailey is a cybersecurity researcher and writer at CyberExperts, covering cyber threats, AI, cloud security, vulnerabilities, and defensive strategies. His goal is to help security professionals quickly understand what matters most and how it impacts their organizations.