Storm-3168 deletes Azure resources in seven minutes using two compromised service principals

Early June 2026. Inside a compromised Azure tenant, a first service principal spends about 15 hours and 30 minutes mapping the environment — more than 300 read operations. September 2026. Microsoft publishes the full analysis of the intrusion, attributed to the JADEPUFFER actor (tracked internally as Storm-3168), and The Hacker News syndicates it on September 28, 2026. Why it matters: the attack encrypted nothing. It deleted — more than one hundred storage-account deletion attempts in seven minutes — and the only things that held were safeguards independent of the compromised identity.

A known agentic actor, a first documented Azure intrusion

JADEPUFFER was first discovered by Sysdig in July 2026 and reported as the first documented agentic ransomware operation. Microsoft’s analysis extends that record with the first detailed view of its Azure activity, marking an evolution in its tradecraft. The presumed entry point is itself instructive: the client ID, client secret, and tenant ID of a service principal had been exposed in plaintext in a public GitHub issue by an employee of the affected organization. The issue was later edited to remove the secret — but the public edit history preserved the value. Microsoft notes it could not confirm that exact secret was used, while restating the rule: removing a disclosure does not revoke the secret.

Two service principals, two distinct roles

The attack relied on two compromised service principals in the same tenant, splitting the work. The first handled reconnaissance: enumerating virtual machines, subscriptions, and resource groups for nearly 16 hours and more than 300 successful reads. The second handled discovery, destruction, and credential collection, in 35 minutes and more than 150 operations.

The timing is precise. About 90 minutes after the first principal began enumerating, the second enumerated virtual machines and resource groups across two subscriptions in five seconds. Sixteen hours later, it inventoried App Service configurations, likely hunting for exposed credentials, then unsuccessfully looked for OpenSearch resources. 70 seconds after that final inventory, it attempted a ListKey operation against a nonexistent storage account, and less than one second later, the destructive sequence began.

Seven minutes of destruction, bounded by roles

The destructive sequence lasted about seven minutes, with more than 100 storage-account deletion attempts. Most succeeded. In parallel, the same principal tried to delete several Azure SQL databases, but every attempt failed because of an unsupported API version for the resource type. A Key Vault, a Function App, and an App Service plan in the same resource group were, however, deleted.

What bounded the damage is the identity’s role. The operations followed the principal’s existing role assignments: a group-granted Storage Account Contributor role authorized the destructive storage operations, a direct Contributor role the application-resource deletions and one key retrieval, and a direct SQL DB Contributor role the database attempts. In other words, the attacker escalated no privileges — it exploited exactly the permissions the tenant had already granted.

The only deletions that were blocked were stopped by mechanisms independent of the identity: Azure resource locks and account-level deletion protection. Microsoft points to this as proof of the value of these safeguards, which remain effective even when a compromised identity holds broad administrative permissions.

The collection that follows the destruction

About 30 minutes after the destruction ended, the same principal inventoried the storage accounts and issued more than 30 successful ListKeys requests, retrieving the access keys for each account — including those tied to Azure Site Recovery. Microsoft observed five unique tokens issued for this principal: four for deletion and one for inventory and key retrieval, two of them active during the same 70-second window.

The destructive objective is consistent with an actor historically aligned with ransomware — JADEPUFFER was previously linked to an exploitation chain through the CVE-2025-3248 flaw in Langflow. Here, mass resource deletion followed by key collection matches a logic of destroy-then-exfiltrate, orchestrated through automation.

Coordinated execution, the signature of an agentic actor

Microsoft stresses the coordination between operations: the division of labor across two principals, the overlapping token streams, and the near-instant gap between the end of reconnaissance and the start of destruction — less than one second — point to automated or scripted execution. It is precisely this orchestration, faster than a human operator, that compressed most of the destruction into 35 minutes and the destructive phase into seven minutes.

The point deserves naming: JADEPUFFER was described in July 2026 as the first agentic ransomware actor, meaning an attack chain built on AI agents rather than fixed scripts. The Azure intrusion Microsoft documented is its operational confirmation: the speed and parallelism — two principals, five tokens, simultaneous storage and SQL deletions — fit the profile of an agent-orchestrated attack, not an operator issuing commands by hand.

What this changes for cloud defense

The common thread of the intrusion is the workload identity. Service principals — the non-human identities used by automation — became the lever of an attack that needed no malware on any machine. Three lessons follow.

First, secret hygiene: a value exposed in a public history remains usable until it is revoked or rotated. The fix is revocation, not deleting the disclosure. Second, least privilege: the roles defined exactly what the attacker could destroy, which argues for granular roles rather than catch-all Contributor assignments. Third, independent safeguards — resource locks, soft delete, immutable backups — were the only barrier that held against an identity that was nonetheless highly privileged.

How to detect this kind of intrusion

Microsoft’s write-up points to several observable signals that would have surfaced this activity in near-real time. The reconnaissance phase produced a long tail of read operations against virtual machines, subscriptions, and resource groups — a pattern that stands out when a single service principal suddenly enumerates the whole tenant. The destructive phase is louder: mass storage-account deletions and parallel SQL deletion attempts within minutes, followed by a burst of ListKeys requests. Microsoft recommends enabling Microsoft Defender for Cloud protections and monitoring for anomalous deletion operations and unusual key-list requests against storage accounts. The decisive point is that none of this requires novel tooling: the signals are already in the Azure Activity Log, and the value comes from alerting on rate, scope, and role rather than on a single signature. In practice, the cheapest win is a simple alert on any identity that deletes more than a handful of storage accounts in a short window. Because the destructive phase runs so fast, a manual review will almost always arrive too late — the alert has to fire on the first anomalous deletion, not on the hundredth.

Verdict

If you use Azure service principals, start with an inventory of exposed secrets — scanning the public history of your repositories beats an after-the-fact audit — and revoke then rotate any value that has already leaked. If your identities carry broad roles, shrink them to least privilege and prefer granular per-resource roles over a global Contributor. And for your critical resources, enable resource locks, deletion protection, and immutable backup: those are the only mechanisms that actually stopped Storm-3168 during its destruction sequence, and they do not depend on an identity staying healthy.

References

• Microsoft Security Blog — Storm-3168: Agentic-driven cloud attacks using compromised service principals (September 25, 2026)
• The Hacker News — JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources (September 28, 2026)
• Dark Reading — JadePuffer AI Actor Compromises Azure in Destructive Cloud Attack (September 2026)