Storm-3168 / JADEPUFFER - Two Compromised Service Principals → 15 Hours of Reads → 100+ Storage Deletions in Seven Minutes → Recovery Locks Attacked → Storage Keys Collected
Microsoft published this account on September 25, 2026, describing activity from early June. It associates the activity with JADEPUFFER, the actor Sysdig reported in July, and tracks it as Storm-3168. Two compromised service principals in one Azure tenant did the work. One spent about 15 and a half hours on reconnaissance. The other ran discovery, then a destructive burst of about seven minutes covering more than 100 storage account deletion attempts plus a Key Vault, a Function App and an App Service plan, along with attempts to strip recovery locks. It then collected storage keys. The operations followed the identities' existing Azure role assignments. Two caveats belong next to the headline. Microsoft could not confirm how the principals were compromised: a service principal's client secret had been posted in a public GitHub issue, and Microsoft could not confirm that secret was used. And while Sysdig reports JADEPUFFER as the first documented agentic ransomware operation and Microsoft's title says agentic-driven, the evidence Microsoft publishes for this activity (timing, division of work, overlapping token streams) strongly indicates automated or scripted execution and does not directly show an AI agent at work. Microsoft did not observe a ransom note or confirm exfiltration.
An employee of the affected organization had posted a service principal's client ID, client secret and tenant ID in plaintext in a public GitHub issue. The secret was later removed from the issue, and it stayed in the public edit history.
Microsoft is careful here. It could not confirm that this secret was used, it does not say which of the two principals the secret belonged to, and it says it is unclear how the service principal was first compromised. Storm-3168 infrastructure also probed Azure App Services belonging to other customers, and Microsoft found no App Service to Azure Resource Manager credential path for this tenant.
Removed: from the issue, and still in the edit history
Confirmed as the source: no; Microsoft could not confirm it
The first service principal made more than 300 successful read operations over about 15 hours and 30 minutes, listing VMs, subscriptions, resource groups and resources. Both principals shared Storm-3168 infrastructure, a network fingerprint and the user agent python-requests/2.34.2.
About 90 minutes after the first principal started, the second enumerated VMs and resource groups across two subscriptions in five seconds. Microsoft cites timing like this, the division of work between principals, and overlapping token streams as strong indications of automated or scripted execution.
Second principal: two subscriptions enumerated in five seconds
Shared traits: same infrastructure and user agent, python-requests/2.34.2
About 16 hours after that discovery, the second principal listed App Service configuration stores, which Microsoft says was possibly a search for exposed credentials. An OpenSearch lookup failed. Seventy seconds later it attempted ListKey on a storage account that did not exist, and that failure came less than a second before the destruction began.
Failed: an OpenSearch lookup, and ListKey on a non-existent account
Next: destruction, less than a second later
The burst lasted about seven minutes and included more than 100 storage account deletion attempts, most of which succeeded, plus the deletion of one Key Vault, one Function App and one App Service plan in the same resource group. Multiple parallel SQL database deletion attempts all failed because the requests used an unsupported API version.
The principal held ordinary roles: group-granted Storage Account Contributor, direct Contributor, and direct SQL DB Contributor. It used five unique tokens, four for deletion and one for inventory and key retrieval, and two of the deletion tokens were active in the same 70-second window. Resource locks and deletion protection blocked deletion attempts for a few of the storage accounts, which makes them the controls that visibly worked in this incident.
Also deleted: 1 Key Vault, 1 Function App, 1 App Service plan
Failed: SQL deletions, unsupported API version
Blocked by: resource locks and deletion protection, for a few storage accounts
Roles: Storage Account Contributor, Contributor, SQL DB Contributor
The destruction targeted backup and recovery resources, which could impair recovery. Attempts to remove Azure Site Recovery locks and an Azure Backup protection lock were unsuccessful. In all, the second principal attempted more than 150 destructive or credential-collection operations in a 35-minute window.
Microsoft assesses this as consistent with tactics that can support ransomware and extortion, and it stops there: it did not observe a ransom note or confirm successful data exfiltration. Sysdig's earlier JADEPUFFER report describes something more complete in a different environment, a ransom table and encrypted Nacos configuration on a database server, after initial access through CVE-2025-3248 in Langflow.
Result: unsuccessful
Window: 150+ destructive or credential operations in 35 minutes
Not observed: a ransom note, or confirmed exfiltration
The final phase reversed the usual order. About 30 minutes after the last destruction, the second principal listed storage accounts and made more than 30 successful ListKeys requests, returning access keys for storage accounts including Site Recovery related ones. A similarly named account in the same resource group had been spared from deletion and was then targeted for key retrieval.
Those keys work independently of the service principal, so disabling it does not revoke them. Microsoft notes that the collection could enable future data access. It reports no Key Vault secret retrieval: the vault was deleted.
Calls: 30+ successful ListKeys requests
Why it matters: storage keys outlive the service principal
Key Vault: deleted, with no secret retrieval reported
🛡 How to Defend Against This Chain
CanNotDelete locks on storage accounts, and keep backups in a service such as Azure Backup under an identity that production service principals cannot touch. Blob soft delete does not protect against deletion of the whole account.ListKeys gave this actor credentials that survive the service principal. Where workloads allow it, disable shared key authorization and use Entra ID, and alert on ListKeys calls in bulk. If keys were listed in an incident, rotate them.