JadePuffer/Storm-3168: an agentic actor deletes an Azure tenant's storage in a 7-minute destructive burst

Microsoft Security Research reported on 25 September 2026 that an actor using two compromised service principals operated inside an unnamed Azure tenant in early June 2026, beginning with more than 15 hours of reconnaissance, then in about seven minutes attempted to delete more than 100 storage accounts, succeeding against most of them, and deleted an Azure Key Vault, a Function App and an App Service plan. Microsoft attributes the intrusion to the actor it tracks as Storm-3168, which the security firm Sysdig calls JADEPUFFER and documented in July 2026 as the first ransomware operation run end to end by a large language model. Microsoft said it found no ransom note and did not confirm that any data was exfiltrated. The archive records this campaign as a high-severity incident with confirmed AI involvement and real harm, and the full entry in the Orca AI Incident Archive carries its sources, severity grade and confidence assessment.

The victim is not named. Microsoft's report describes a single Azure tenant, two compromised service principals that belonged to it, and a division of labour between them: one principal handled reconnaissance for about 15 hours and 30 minutes and made more than 300 successful read operations enumerating virtual machines, subscriptions, resource groups and resources; the other performed discovery, the destructive operations and the credential collection. Microsoft did not say how many organisations were affected, and it could not establish how the service principals were first compromised.

What the telemetry shows, in order

The second principal began about 90 minutes after the first started, and enumerated virtual machines and resource groups across two subscriptions in roughly five seconds, according to Microsoft. Both identities used infrastructure Microsoft ties to Storm-3168, shared the same network fingerprint and presented the same user agent, python-requests/2.34.2. Microsoft said the timing and the division of labour "strongly indicates automated or scripted execution."

About 16 hours later, the second principal checked Azure App Service configuration stores for exposed credentials and searched, unsuccessfully, for Azure OpenSearch. Seventy seconds after that, it tried a ListKey operation against a storage account that did not exist. Less than one second after that failed call, the destruction began. Over the following 35 minutes Microsoft counted more than 150 destructive or credential-collection operations; the core destructive phase lasted about seven minutes.

The seven minutes, and the controls that held

Microsoft says most of the storage accounts the actor targeted were successfully deleted. The actor also deleted an Azure Key Vault, a Function App and an App Service plan that sat in the same resource group and appeared to support the Function App. The targeting was not limited to storage: Microsoft recorded multiple attempts to delete Azure Site Recovery locks and Azure Backup protection locks, and reported that those attempts failed.

Microsoft says not every deletion worked, and the reasons differ in a way that matters for defenders. A few storage accounts survived because Azure resource locks and storage-account-level deletion protection blocked the operation. The parallel attempts to delete Azure SQL databases failed for a different reason: every one used an unsupported API version. The Cloud Security Alliance described that as an operational error rather than a blocked action. Microsoft summarised the combination of resource deletion, attempts to interfere with recovery, and credential collection as "consistent with tactics that can support ransomware and extortion operations."

Microsoft's account describes ordinary Azure role assignments rather than an exploit of Azure itself. It found that a group-granted Storage Account Contributor role allowed the storage destruction, a direct Contributor role allowed the deletion of the three application resources and another key retrieval, and a direct SQL DB Contributor role allowed the failed SQL attempts. Microsoft observed five unique tokens issued for the second service principal: four supported deletion and the fifth handled storage inventory and key retrieval. Two of the deletion tokens were active during the same 70-second period. The report also notes that storage accounts with terraform and backup-themed names were among the targets, potentially to impair recovery.

The return for storage keys

About 30 minutes after the destruction ended, the same principal came back. It inventoried storage accounts and made more than 30 successful ListKeys requests, including against storage tied to Site Recovery. A similarly named storage account in the same resource group had been spared during the deletion phase and was then successfully key-listed. Microsoft did not observe a ransom note and did not confirm successful data exfiltration, but it said the collected keys could support future exfiltration.

That sequence changes what recovery means, according to Ross Filipek, chief information security officer at Corsica Technologies, who spoke to CSO Online about the incident. Rebuilding deleted assets is not enough, he said, because the later requests for storage keys may create another path to data; responders have to establish which identities and keys were touched and review their use before trusting restored services. "Once attackers hold an application identity, their activity can look like ordinary cloud administration," Filipek told CSO Online.

How the credentials surfaced

Microsoft could not confirm the initial access vector. What it did find was an exposure: the client ID, client secret and tenant ID for one of the service principals had appeared in plaintext in a public GitHub issue, posted by an employee of the affected organisation. The issue was later edited, but Microsoft said the secret remained accessible through the issue's public edit history. The report states plainly that Microsoft could not confirm whether this secret was the one used.

The warning attached to that finding is the practical part. Microsoft says credentials that have been publicly exposed should be treated as compromised, revoked or rotated immediately, and investigated for prior use; removing or redacting an exposed secret does not invalidate it, and publicly exposed credentials remain usable until they are revoked or rotated.

Microsoft also described broader probing by Storm-3168-linked infrastructure since early 2026 against Azure App Services at WordPress administration, PHP-CGI, the Langflow endpoint /api/v1/validate/code, and webshell-like paths. Those targets did not overlap the victim's subscriptions, and Microsoft found no path from an App Service to Azure Resource Manager credentials. The report lists three indicators: 45.131.66[.]106 for probing and malicious ARM requests, and 34.153.223[.]102 and 64.20.53[.]230 for App Service probing.

The same actor, a different operation

Sysdig's 1 July 2026 report is the reason the word "agentic" attaches to this actor at all. Sysdig described JADEPUFFER as the first documented case of agentic ransomware — "a complete extortion operation driven end-to-end by a large language model" — and said its capabilities came from an AI agent rather than a human-run toolkit. In that intrusion, the actor exploited CVE-2025-3248 in an internet-facing Langflow instance, encrypted 1,342 Nacos configuration items using MySQL's built-in AES_ENCRYPT() function, dropped the original tables, and left a README_RANSOM table with a Bitcoin address and a Proton Mail contact. Sysdig reported more than 600 distinct payloads, self-narrating code, and a corrective multi-step payload that followed a failed Nacos login within 31 seconds. Sysdig also said it lacked visibility into the system prompt or the agent's configuration.

The Azure campaign is a distinct operation by the same actor, not a re-run of the July intrusion: it was about deletion and key collection, not encryption, and Microsoft found no ransom note. The link between the two rests partly on infrastructure. The Cloud Security Alliance noted in a 28 September research note that two of the IP addresses Microsoft lists, 45.131.66[.]106 and 34.153.223[.]102, had appeared in Sysdig's July reporting. The same note cautioned that IP reuse alone cannot rule out shared third-party hosting.

Established, assessed, and still open

The mechanics of the Azure intrusion are well documented. The autonomy is not documented to the same standard, and the difference is the most important qualification on this record.

Established by Microsoft's telemetry: two compromised service principals in one tenant; more than 300 successful read operations over about 15 and a half hours; more than 100 storage-account deletion attempts, most of which succeeded; the deletion of a Key Vault, a Function App and an App Service plan; SQL database deletions that all failed because of an unsupported API version; storage accounts saved by resource locks and deletion protection; more than 30 successful ListKeys requests after the destruction; plaintext service-principal credentials in a public GitHub issue and its edit history; no ransom note observed; and no confirmed exfiltration.

Assessed by Microsoft: that the activity belongs to Storm-3168; that the combination of deletion, recovery interference and key collection is consistent with ransomware and extortion; that the execution was likely automated or scripted; and that the collected keys could support future exfiltration. Microsoft's public report does not describe an autonomous agent reasoning through the Azure-specific steps.

Open: how the service principals were first compromised; the identity of the victim and the number of organisations affected; whether any data left the tenant; and whether an AI agent, rather than a script, directed the Azure operations themselves.

The Cloud Security Alliance put the evidential gap precisely in its 28 September note: the "agentic" characterisation, it wrote, currently rests "on the precision, tempo, and division of labor across identities," rather than on captured agent reasoning traces. The evidence Sysdig used in July — self-narrating payloads and a rapid diagnose-and-correct cycle — is absent from the public record of the Azure campaign. Nick Tausek of the security firm Swimlane told CSO Online that the Azure evidence shows "coordinated automation rather than proving AI directed each step."

Coverage of the disclosure used the stronger framing. BleepingComputer's headline described "agentic AI attacks" against Azure, and Dark Reading's described an "AI actor" compromising an Azure tenant; Microsoft's own report says the timing and the division of labour "strongly indicates automated or scripted execution" and does not attribute the individual Azure steps to an agent.

The archive grades this record confidence A and does not flag it as disputed. The record's "confirmed" AI-involvement label turns on the attribution to JADEPUFFER, the actor Sysdig documented as LLM-driven; it is not a claim that Microsoft captured an agent's reasoning during the Azure deletions. The harm is established, the automation is established, and the autonomy is inferred.

What Microsoft says should change

Microsoft's recommendations are operational, and they follow directly from how this intrusion worked. It asks defenders to enable the relevant Microsoft Defender for Cloud plans for Resource Manager, Storage, Key Vault, App Service and Databases; to keep service-principal credentials, storage keys, connection strings and other secrets out of source code, configuration, repositories and issues; to use Microsoft Entra Workload ID instead of long-lived secrets; to apply least privilege and review Azure RBAC assignments for workload identities; and to restrict and monitor backup and recovery resources, including attempts to alter their protection controls.

Microsoft's public report does not say whether the tenant restored its data, whether the victim was notified, or whether any of the collected keys were used afterwards. Those outcomes are not in the record. What the record does carry is a measurable contrast: the resource locks and deletion protection blocked some deletions even against broadly privileged identities, while the SQL databases were saved by an API-version mistake rather than by a defender's decision. Microsoft's account does not say what the tenant did next. It does say the actor spent more than 15 hours reading before it spent seven minutes deleting.