Seven Minutes to Destroy an Azure Tenant: Inside the Storm-3168 Agentic Ransomware Incident

A Seven-Minute Cloud Catastrophe

The Storm-3168 incident disclosed by Microsoft reveals a disturbing new trend in cloud security: using just two compromised Azure service principals, attackers needed roughly seven minutes to map an entire tenant's resources and delete storage accounts, Key Vaults, and multiple application assets.

According to Microsoft, the actor behind this incident is JADEPUFFER — the first documented "agentic" ransomware operation on record. "Agentic" means the attack chain incorporates automated components capable of autonomous decision-making, rather than relying entirely on manual, step-by-step human operation. This approach pushes attack speed and destructive efficiency to an entirely new level.

The seven-minute figure is alarming precisely because it falls far short of most organizations' security response windows. By the time an alert fires and the security team intervenes, critical resources have already been wiped. This fundamentally reshapes the time dynamics between defenders and attackers.

Why Service Principals Became the Entry Point

Service principals are the "workload identities" in Azure — they represent applications, services, or automation scripts for authentication purposes. Unlike human user accounts, they typically lack multi-factor authentication protection. Their credentials exist as keys or certificates, and they are frequently granted overly broad permissions as a matter of convenience.

This is the crux of the problem. Once a service principal's credentials are compromised, an attacker can call Azure management APIs directly using a legitimate identity, and the system has difficulty distinguishing this from normal automated behavior. In the Storm-3168 incident, the attackers held two compromised service principals, first conducting tenant mapping (enumerating resources, permissions, and asset relationships), then carrying out targeted deletion operations.

Enumeration Before Destruction

The "mapping" phase of the attack flow deserves special attention. Rather than acting blindly, the attackers first determined which high-value resources existed in the tenant and which service principals held delete permissions. This reconnaissance activity often looks indistinguishable from routine inventory queries at the API call level — easy to overlook. By the time the destructive actions began, the attackers had already precisely identified their targets.

Service principals play the role of "machine accounts" in Azure's identity architecture. They are security objects generated after an application registration in Azure Active Directory (Entra ID). Each service principal corresponds to an App Registration and authenticates via a Client Secret or certificate, exchanging credentials for an OAuth 2.0 access token to call various Azure APIs. Compared to human accounts, service principal credentials are frequently hardcoded into CI/CD pipelines, configuration files, or environment variables — giving them a much larger exposure surface than MFA-protected user accounts. To avoid frequent permission requests, many organizations habitually grant service principals the Contributor or even Owner role. This over-permissioning translates directly into lateral movement and destructive capability for attackers when credentials are leaked. Azure's permission model is based on RBAC (Role-Based Access Control), with fine-grained permissions available down to the individual resource level — but this granularity is rarely fully utilized in practice.

Why a Deleted Secret Still Works

Microsoft specifically highlighted a counterintuitive technical detail in this incident: a "deleted" secret can still work.

This stems from the lifecycle mechanics of OAuth tokens. When a service principal uses a key to obtain an access token, that token remains valid for its entire lifetime — typically tens of minutes to an hour — even if the original key is subsequently rotated or deleted. The token itself is stateless; Azure does not perform a real-time check to verify whether the original key still exists during validation.

This means simply "deleting the compromised key" is not enough to immediately cut off an attacker's access. Until the token expires, the attacker's access credential remains valid — and the seven-minute attack window falls entirely within a single token's lifetime. This explains why rapid credential rotation may not stop an attack already in progress.

The root of this mechanism lies in the design philosophy of OAuth 2.0 — access tokens are self-contained signed credentials. The service side only needs to verify the token signature and expiration time during validation, with no need to query the Authorization Server in real time. The JWT (JSON Web Token) format tokens used by Azure embed permission claims, and once issued, exist independently of the original credentials. The only way to truly invalidate a token is through Token Revocation, but Azure AD's revocation mechanism has propagation delays, and not all resource providers check revocation lists in real time. To immediately cut off an attacker's access, the correct approach is to revoke or disable the service principal itself (not just delete the key), trigger a "Revoke all session tokens" operation in Entra ID, and combine this with Conditional Access policies to block requests from anomalous sources.

Governance Lessons for Workload Identities

This incident points directly to concrete areas for improvement in how workload identities are managed.

The principle of least privilege cannot remain just a slogan. Service principals should only be granted the permissions necessary to complete their tasks. Delete operations and other high-risk management actions in particular must be tightly restricted. If read-only access suffices, don't grant read-write. If resource-level scope suffices, don't grant subscription-level.

Shorten token lifetimes and introduce Conditional Access. For sensitive workload identities, consider shorter token lifespans combined with Conditional Access policies (such as restricting source IPs or requiring device compliance) to reduce the exploitable window if a token is stolen.

Establish behavioral baselines and real-time alerting for management plane operations. Large-scale resource deletion, Key Vault purging, and similar operations should trigger immediate alerts or even automated blocking — not after-the-fact audits. Against a seven-minute attack, passive log review is nearly meaningless.

Enable resource deletion protection and soft delete. Azure provides resource locks, soft delete, and Key Vault purge protection. Enabling these features creates a recovery window for deleted resources, transforming "irreversible destruction" into a "recoverable incident."

Rethinking Defense for the Age of Agentic Attacks

Storm-3168 matters not just as an individual incident, but as a signal of a new phase in attack automation. When attackers leverage autonomous components to compress the time between reconnaissance and execution, traditional response workflows that depend on human analysis will become increasingly inadequate.

Defenders need to raise their own automation level in parallel: from identity governance and permission reduction, to machine-speed detection of anomalous behavior and automated response — building a protection system capable of reacting in minutes or even seconds. In cloud environments, identity has become the true perimeter, and workload identities are the most overlooked and most dangerous weak point along that perimeter.

The "Agentic" attack pattern represented by JADEPUFFER refers to an attack toolchain that incorporates AI or automated agent components with environmental awareness and decision-making capability. Unlike traditional scripted attacks, agentic attacks can dynamically adjust their next steps based on reconnaissance results — for example, automatically prioritizing high-value targets after enumeration, or automatically attempting alternative paths after encountering a permission denial. This adaptability significantly undermines signature-based defenses (such as rule-based SIEM alerts). Security researchers are concerned that as large language models integrate more deeply with penetration testing frameworks, the barrier to agentic attacks will continue to fall while their execution speed and decision quality continue to rise — ultimately creating a severe asymmetry of "AI attacks vs. human defense." This is the deeper reason JADEPUFFER is regarded as a landmark incident.