Security1 publisher2 min readPublished
Storm-3168 used a second stolen service principal to delete most targeted Azure storage in about seven minutes
Microsoft says Storm-3168, the JADEPUFFER group, tried more than 100 Azure storage deletions in seven minutes with a stolen service principal. Resource locks saved a few accounts, and the SQL databases survived on the attacker's own API error.
The Watch · Security desk
What happened
- Microsoft tracks JADEPUFFER, the group Sysdig found in July 2026 and reported as the first documented agentic ransomware operation, as Storm-3168 and has now detailed its Azure activity.
- Two compromised service principals in one Azure tenant split the work, one running reconnaissance and the other running discovery, deletion and credential collection.
- In early June 2026 the first principal spent about 15.5 hours enumerating VMs, subscriptions and resource groups, logging more than 300 successful reads.
- More than 100 storage account deletion attempts over about seven minutes removed most of the storage accounts the actor targeted.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Hardening workload identities and protecting recovery resources are separate spending decisions, and in this tenant the identities fell while locks and deletion protection held against their admin rights.
- exposure A service principal secret that has leaked stays usable until someone revokes or rotates it, so taking down the repo or post that exposed it leaves the tenant open.
- exposure The Azure SQL databases' defenses against a corrected run are untested, because what stopped this one was the attacker's own API version error.
- capability About 17 hours separated first read from first delete, time in which revoking the two service principals would have cut the access Microsoft saw used.
The first delete came about 17 and a half hours after the first read [1]. That total adds Microsoft's intervals: 90 minutes to the second principal's five-second sweep of two subscriptions, 16 hours to its App Service inventory, 70 seconds to a failed ListKey call, and under a second to destruction [5][7][8]. It counts Microsoft's "16 hours later" from the five-second sweep. Both identities came from Storm-3168-linked infrastructure, shared a network fingerprint and sent the user agent python-requests/2.34.2 [6].
Before deleting anything, the second principal looked for secrets. It enumerated App Service configuration stores, possibly for exposed credentials in Microsoft's reading, and failed to find Azure OpenSearch resources [7]. Microsoft says the credentials the actor collected could support exfiltration later [16]. The ListKey call that came just before the destruction targeted a storage account that did not exist [8].
More than 100 storage deletion attempts in about seven minutes is one attempt every 4.2 seconds or faster [2]. Alongside the storage accounts, a Key Vault, a Function App and an App Service plan from one resource group were deleted [13], inside a run of more than 150 destructive or credential-collection operations in 35 minutes [9]. A five-second sweep, a sub-second handoff to deletion and a Python HTTP library in the user agent point to software issuing the calls [5][6][8]. The agentic label comes from Sysdig's July reporting on JADEPUFFER [1]. Microsoft places the case in a broader move toward AI-orchestrated attacks and pairs that framing with its own Project Perception and MDASH efforts for AI-assisted response [19].
What survived did so for two different reasons. Microsoft wrote that the storage accounts saved by locks and deletion protection show the value of "independent safeguards that remain effective even when a compromised identity has broad administrative permissions" [11][12]. The SQL outcome came from the attacker's side. Every deletion call used an API version the Azure SQL database resource type does not support [14]. Microsoft also lists recovery protection locks among the resource types the actor went after [15].
Microsoft does not say how the two service principals were compromised. Its remediation list covers workload identities and secrets, least privilege, recovery resources and the relevant Defender for Cloud protections [18].
The documented destruction is in one tenant [20], and it dates to early June 2026, before Sysdig's July discovery of the group [3]. Microsoft calls its findings an evolution in Storm-3168's cloud operations [2].
What to watch
- Further Azure tenants attributed to Storm-3168 by Microsoft or Sysdig; the destruction documented so far is in one environment.
- Whether Microsoft says how the two service principals were compromised, including whether their secrets had been publicly exposed.
- A later Storm-3168 run that calls a supported SQL API version, the error that spared the databases in this tenant.