From Sidhant Tamrkar | Product & Market Analysis
JadePuffer Wiped Azure With 2 Service Principals: Controls by Step
On this page
Microsoft's 25 September 2026 report on Storm-3168, the operator also tracked as JadePuffer, describes 2 compromised Azure service principals. They mapped one tenant for about 15.5 hours, then made more than 100 storage account deletion attempts in roughly 7 minutes. Service accounts security decided the outcome, not model capability. Every destructive call the attacker made was authorised by a role the victim had already granted.
Key takeaways
- The attacker needed no exploit inside Azure, only two identities with existing roles. Microsoft found the deletions matched the second service principal's Storage Account Contributor, Contributor and SQL DB Contributor assignments, so every call was authorised.
- The deletion burst ran about 44 times faster per minute than the reconnaissance. Our arithmetic on Microsoft's published floors: 300+ reads across 15.5 hours against 100+ deletion attempts in about 7 minutes. Detection pays in the slow phase only.
- Preventive resource controls held where they existed. Azure resource locks and storage deletion protection blocked some deletions, and every attempt to remove Site Recovery and Backup protection locks failed, according to Microsoft's report.
- The AI-agent label is the least proven part of the story. Microsoft's evidence says automated or scripted execution, and the Cloud Security Alliance notes the Azure activity lacks the self-narrating payloads that grounded Sysdig's July agentic finding.
The short answer. Storm-3168 did not break Azure. It used one service principal to read the tenant slowly and a second, with Contributor-family roles, to delete storage, a Key Vault and app resources in minutes. The controls that would have changed the outcome are secretless credentials, Conditional Access for workload identities, narrower roles, and delete locks on recovery assets.
What Microsoft reported about Storm-3168 and JadePuffer
Microsoft Security Research published the report on 25 September 2026, written by Yossi Weizman and Tushar Mudi of the Defender for Cloud team. It links the activity to JADEPUFFER, the operator Sysdig described in July 2026 as the first documented agentic ransomware operation. Microsoft tracks the same actor as Storm-3168.
The victim was a single Azure tenant, and the activity began in early June 2026. That puts the report roughly 3.5 months behind the events it describes. It is a reconstruction for defenders, not an alert about an ongoing campaign.
The outcome was destructive. Most of the targeted storage accounts were deleted, along with a Key Vault, a Function App and the App Service plan behind it. Microsoft did not observe a ransom note and did not confirm data exfiltration. The ransomware reading rests on the targeting pattern: storage accounts with Terraform-themed and backup-themed names, recovery locks, and storage access keys.
Microsoft does not say an AI model executed these Azure operations. Its technical finding is that the timing and division of labour "strongly indicates automated or scripted execution". The agentic framing comes from the link to JadePuffer's earlier campaign. We return to that gap in the limitations section.
The Azure service principal compromise, step by step
Microsoft gives relative times rather than clock times. The elapsed column is our own arithmetic on those relative times, so treat it as approximate. Every "+" figure is Microsoft's published floor, not an exact count.
| Step | Identity | What happened | Elapsed from first read (our estimate) |
|---|---|---|---|
| 1. Reconnaissance | Principal 1 | Enumerated VMs, subscriptions, resource groups and resources: 300+ successful reads | 0 to about 15h30m |
| 2. Fast enumeration | Principal 2 | Enumerated VMs and resource groups across 2 subscriptions in 5 seconds | About 1h30m |
| 3. Credential hunting | Principal 2 | Enumerated App Service configuration stores; failed to find OpenSearch resources | About 17h30m |
| 4. Probe | Principal 2 | Failed ListKey call against a storage account that did not exist | 70 seconds later |
| 5. Destruction | Principal 2 | 100+ storage deletion attempts; Key Vault, Function App and App Service plan deleted; SQL deletions failed; lock removals failed | Starts under 1 second later, lasts about 7 minutes |
| 6. Key harvest | Principal 2 | Storage inventory, then 30+ successful ListKeys requests, including Site Recovery storage | About 30 minutes after the last deletion |
Microsoft also counts 150+ destructive or credential collection operations within 35 minutes. It does not state exactly where that window starts. We have not tried to reconcile it with the 7-minute and 30-minute figures above.
The two-hour lull is the defender's window
By our arithmetic, the destructive burst began about 2 hours after the slow reconnaissance ended and about 17.5 hours after the first read. That lull, plus the reconnaissance, is the only stretch long enough for a human to read an alert and revoke a credential. Everything after the failed ListKey probe ran faster than any on-call rotation can answer a page.
Seven minutes is not a response window
More than 100 deletion attempts in about 7 minutes is at least 14 per minute, or roughly one every 4 seconds. The reconnaissance ran at about 0.32 reads per minute on the same published floors, 300 reads across 930 minutes. On those numbers the destructive phase ran about 44 times faster per minute. That ratio is the design brief: detection earns its keep in the slow phase, and only preventive controls work in the fast one.
Why two service principals beat one
Splitting reconnaissance from destruction is an old pattern in human intrusions. A principal that only reads looks like inventory tooling, which most Azure estates run all day. The principal that deletes appears late, acts briefly and finishes before anyone reviews a weekly report. Neither identity looks alarming on its own.
Microsoft maps the destructive principal's permissions precisely. A Storage Account Contributor assignment, granted through a group, authorised the storage deletions. A direct Contributor assignment authorised deleting the Key Vault, the Function App and the App Service plan. A direct SQL DB Contributor assignment authorised the SQL deletion attempts. Those failed only because the requests used an unsupported API version.
Luck saved those databases, not a control. A correctly formed request from the same principal would have been authorised. The broader problem of counting and owning these identities is covered in the analysis of non-human identity access.
Five tokens, two at once
Microsoft counted 5 unique tokens issued 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 period, one working on storage and the other on storage and SQL. Parallel sessions under one service principal, both issuing deletes, are a pattern you can write an alert for today.
Both principals also used the user agent string python-requests/2.34.2 from infrastructure Microsoft links to Storm-3168. If your principals normally call Azure through Terraform or an SDK, a bare HTTP library from a new address deserves a page. It is a weak signal alone and a strong one next to a cross-subscription read pattern.
Service accounts security starts with the secret in the GitHub issue
Microsoft could not determine how the principal was first compromised. It did find that the client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the victim organisation. The issue was later edited to remove the secret, but the value stayed readable in the issue's public edit history.
Microsoft is careful to say it could not confirm that this secret was used in the attack. You should be less careful about your own tenant. A secret that has ever been public is compromised, and editing the post does not retract it. Microsoft's own guidance says to treat publicly exposed credentials as compromised and investigate their historical use.
Rotation is the floor, removal is the goal
Rotating the exposed secret fixes yesterday's leak. Removing client secrets as a class fixes the next one. For a risky workload identity, Microsoft's ID Protection guidance is to add a new credential, preferably an x509 certificate, and remove the compromised one. If the account is at risk, remove all existing credentials.
The stronger move is to stop issuing secrets to pipelines at all. Workload identity federation lets an app registration or user-assigned managed identity trust tokens from GitHub Actions, Kubernetes clusters, Google Cloud, AWS and other issuers. A pipeline configured that way holds no secret for an engineer to paste into an issue.
Make the tenant refuse new secrets
Entra app management policies can block new password credentials outright or cap their lifetime, tenant-wide or per application. Our position: if your pipelines can federate, switch the block on. Make every exemption a ticket with a named owner and an expiry date. Whether automation should hold its own credential or borrow a person's is argued in the comparison of agent credentials and user impersonation.
ID Protection also runs a Leaked Credentials risk detection for workload identities. Microsoft's documentation says it checks credentials gathered from GitHub, the dark web and paste sites against valid credentials in Entra ID. Neither source says whether it would catch a secret sitting only in an issue's edit history. Do not assume coverage you have not tested. Tenants without Workload Identities Premium still receive the detections, with limited reporting detail.
Workload identity protection with Conditional Access, and its gaps
Conditional Access for workload identities can block a service principal's token from outside known public IP ranges, or when ID Protection rates it risky. Block is the only grant control available. The policy applies at token request, exactly the step an attacker holding a stolen secret must pass first.
In this incident the malicious Resource Manager requests came from an IP address Microsoft lists as Storm-3168 infrastructure. A location policy pinning the principal to your pipeline's egress ranges would have refused the token, provided the principal was in scope. That is our inference from the documented control, not a finding in Microsoft's report.
Four scope limits decide whether the policy applies
Read these before you buy anything. Policies cover single-tenant service principals registered in your tenant, so multitenant and third-party SaaS apps are out. Managed identities are not covered. A policy assigned to a group containing a service principal is not enforced for that principal, which must be assigned to the policy directly. Creating or modifying these policies requires Workload Identities Premium licences.
The group limitation is the one most likely to catch a team out. Microsoft found that the destructive principal's storage rights arrived through a group. Teams that manage access by group will tend to scope Conditional Access the same way. For service principals, the documentation says that does nothing. Run new policies in report-only mode first and check which tokens they would have refused.
Delete locks and recovery windows for the 7-minute burst
Once the destructive token was issued, only controls on the resources themselves mattered. Microsoft's report shows they work. Some storage deletions were blocked by Azure resource locks and storage account-level deletion protection. Repeated attempts to remove Site Recovery and Azure Backup protection locks failed. Those are the only points where the defender won.
A CanNotDelete lock, shown as Delete in the portal, lets authorised users read and modify a resource but not delete it. Creating or removing a lock requires the Microsoft.Authorization/locks/* or Microsoft.Authorization/* actions, which the Owner and User Access Administrator roles hold. An automation identity should never hold either role on the scopes it operates in. That turns the lock back into a speed bump.
What a ReadOnly lock buys, and what it costs
The 30+ ListKeys requests are the step most likely to cause a second incident. Storage account keys grant data access without going back through Entra. A ReadOnly lock on a storage account prevents listing the account keys. It also blocks every update and any RBAC assignment scoped to the account. It suits backup and recovery storage that rarely changes, not busy production accounts.
Locks act on the control plane only. Microsoft's lock documentation says a lock on a storage account does not protect the data inside it. If the next attacker uses harvested keys against blobs, the lock is irrelevant. Rotate storage keys after any incident where ListKeys succeeded.
Know your recovery clock before you need it. A deleted storage account can be recovered within 14 days if no new account has taken its name and the resource group still exists. The person recovering needs Microsoft.Storage/storageAccounts/write, and Microsoft calls recovery best effort. Key Vault soft delete retains a deleted vault for 7 to 90 days, set at creation and fixed afterwards. Purge protection is optional and off by default. If a storage account used customer-managed keys from a deleted vault, restore the vault first. Write that order into the runbook now.
Detecting an AI agent attack toolchain at machine speed
Microsoft recommends Defender for Cloud plans across Resource Manager, Storage, Key Vault, App Service and Databases. The report lists relevant alerts, including "Azure Resource Manager operation from suspicious proxy IP address", "High volume of operations in a key vault" and "Unusual application accessed a key vault". It publishes 3 IP indicators and no hunting queries, so the detection logic for your own estate is yours to write.
The useful question is which phase each detection can catch in time. An alert that fires during the 15.5-hour reconnaissance can lead to a revoked credential and nothing lost. An alert that fires during the 7-minute burst produces a well-documented loss. ID Protection lists its Anomalous service principal activity and Suspicious API Traffic detections as offline. Expect them to inform the investigation, not stop the burst.
From the report, four behaviours separate this activity from normal automation. One principal read across everything it could see for hours. A second principal enumerated 2 subscriptions in 5 seconds. A ListKey call targeted a storage account that did not exist. More than one token for the same principal issued deletes at once. None of the four needs a model to detect. The fields worth logging per identity are set out in the agent audit log specification.
The control checklist, mapped to each step
The table below is the checklist we would run against any tenant whose automation identities hold Contributor-family roles. Each row links to the defining documentation. The last column states the catch.
| Attack step | Control | Documentation | The catch |
|---|---|---|---|
| Secret exposed in a public issue | Treat as compromised, rotate, then move pipelines to federated credentials and block new secrets | Workload identity federation | Not every tool your teams run supports federation yet |
| Token requested from attacker infrastructure | Conditional Access location and risk policies for workload identities | Conditional Access for workload identities | Single-tenant principals only, direct assignment, Premium licence |
| Slow cross-subscription reconnaissance | Scope roles to resource groups; alert on read volume and new user agents | Workload identity risk detections | Several risk detections are offline, not real time |
| Deletion burst | CanNotDelete locks on storage, Key Vault and backup resources; no Owner or User Access Administrator on automation identities | Azure resource locks | Locks protect the control plane only, not the data |
| Storage and Key Vault deleted | Rehearse 14-day storage recovery; set Key Vault retention and purge protection at creation | Storage account recovery | Recovery is best effort and needs the resource group to survive |
| ListKeys harvest | ReadOnly locks on recovery storage; rotate keys after any successful ListKeys | Azure resource locks | ReadOnly blocks every change, so it breaks active workloads |
Two adjacent problems share its root cause. Agent OAuth grants are examined in the review of agent OAuth scopes. How third-party tool servers widen the same credential surface is covered in the analysis of MCP server supply chain risk.
Where this argument is weakest
The AI part is the least proven part. Sysdig's July report grounded its agentic finding in self-narrating payloads and a failed login corrected within 31 seconds, observed in a compromised Langflow host. The Cloud Security Alliance's 28 September note says the Azure evidence includes no such payload text. Its agentic label rests on tempo and division of labour. A plain script holding the same secret would leave the same trail, so this post treats the incident as a service principal failure first.
Initial access is unconfirmed. Microsoft says it could not confirm the GitHub-exposed secret was used. It also reports Storm-3168 infrastructure probing App Services, including Langflow's code validation endpoint. Those targets did not overlap with the affected subscriptions. If the real entry route was something else entirely, secret hygiene is necessary and still not sufficient.
It is one tenant, described by one vendor. Every count here comes from Microsoft's account of a single victim, published with relative times and floor figures. Microsoft also sells several of the recommended controls, including Defender for Cloud plans and Workload Identities Premium. Resource locks and least-privilege roles, which cost nothing extra, did more measurable work here than any paid detection.
The controls carry real friction. ReadOnly locks break deployments. Location policies break when pipeline egress addresses change. Federation needs every tool in the chain to support it. Apply all six rows at once and the broken builds will get them rolled back. Sequence them, starting with locks on recovery assets.
Stress-test whichever controls you adopt the way an attacker would; the guide to running an agent red-teaming programme covers how to scope that work.
Frequently asked questions
What is Storm-3168 JadePuffer?
Storm-3168 is the name Microsoft uses for the threat actor Sysdig called JADEPUFFER in July 2026, describing it as the first documented agentic ransomware operation. Microsoft's 25 September 2026 report says the actor used two compromised Azure service principals in one tenant to map resources, delete storage accounts, a Key Vault and app resources, and collect storage account keys. No ransom note was observed.
How did JadePuffer compromise Azure service principals?
Microsoft says it is unclear how the service principal was first compromised. It found that the client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the victim organisation. The secret stayed visible in the issue's edit history after removal. Microsoft could not confirm that this secret was the one used.
Can Conditional Access block a compromised service principal?
Yes, within limits. Conditional Access for workload identities can block token issuance from outside known IP ranges or when ID Protection rates the principal risky. It covers single-tenant service principals only, excludes managed identities, is not enforced through group assignment, and needs Workload Identities Premium licences to create or change policies. Block is the only grant option.
Do Azure resource locks stop a Contributor from deleting resources?
A CanNotDelete lock blocks deletion for any authorised identity until the lock is removed. Removing it requires Microsoft.Authorization/locks permissions, which the Owner and User Access Administrator roles hold. In the Storm-3168 incident, resource locks and storage deletion protection blocked some storage deletions, and attempts to remove Backup and Site Recovery locks failed. Locks do not protect data inside a storage account.
How long do you have to recover a deleted Azure storage account?
Microsoft documents a 14-day window to recover a deleted storage account, provided it used the Resource Manager model, no new account has taken the same name, and the resource group still exists. The person recovering needs the storageAccounts write permission. Microsoft describes recovery as best effort and not guaranteed, and recommends locking resources to prevent deletion in the first place.
Was the JadePuffer Azure attack really run by an AI agent?
Not proven. Microsoft's technical evidence, including sub-second gaps, parallel tokens and split roles across two identities, points to automated or scripted execution. The Cloud Security Alliance notes the Azure activity lacks the self-narrating payloads that supported Sysdig's July agentic finding. Defensively the distinction matters little, because a simple script with the same credentials would have done the same damage.
Where to start this week
Pull one list before you change anything. Export every service principal that holds a client secret and any Contributor-family role at subscription scope. Mark which of them authenticate from a pipeline that could federate instead. That list is your attack surface for a Storm-3168 style incident.
Then protect the recovery path, because that is what this attacker went for. Put CanNotDelete locks on the resource groups holding backup, Site Recovery and Terraform state storage. Confirm that no automation identity holds Owner or User Access Administrator over them. Then time a test restore of one deleted storage account inside the 14-day window.
Related in this cluster
Machine identities are the common thread. Start with who owns your non-human identities, then how to review the scopes your agents hold.
References
- Microsoft Security Research (Yossi Weizman, Tushar Mudi), Storm-3168: Agentic-driven cloud attacks using compromised service principals, 25 September 2026. Used for the timeline, counts, roles, tokens, initial access findings and indicators.
- Sysdig (Michael Clark), JADEPUFFER: Agentic ransomware for automated database extortion, 1 July 2026. Used for the original agentic evidence and the Langflow entry point.
- Cloud Security Alliance AI Safety Initiative, Storm-3168: Agentic cloud attacks on Azure identities, 28 September 2026. Used for the limits of the agentic attribution.
- Microsoft Learn, Conditional Access for workload identities, retrieved 5 November 2026. Used for conditions, scope limits and licensing.
- Microsoft Learn, Securing workload identities with ID Protection, retrieved 5 November 2026. Used for risk detections and remediation steps.
- Microsoft Learn, Lock your Azure resources, retrieved 5 November 2026. Used for lock types, removal permissions and storage key behaviour.
- Microsoft Learn, Recover a deleted storage account, retrieved 5 November 2026. Used for the 14-day window and conditions.
- Microsoft Learn, Workload identity federation, retrieved 5 November 2026. Used for supported external identity providers.
Weakest point in the source base: every incident figure comes from one vendor's account of one tenant, given as relative times and floor counts. The elapsed-time and rate figures are our arithmetic on them. Last verified 5 November 2026; recheck control scope and licensing every 90 days.
Related reading