NEWS

JadePuffer AI Actor Compromises Azure Tenant in Destructive Cloud Attack

JadePuffer (Storm-3168), an agentic AI actor, used exposed credentials to wipe 100+ Azure storage accounts and other resources in minutes.

Dylan H.

News Desk

October 4, 2026
8 min read
JadePuffer AI Actor Compromises Azure Tenant in Destructive Cloud Attack

JadePuffer Agentic AI Actor Wipes Azure Resources in Seven-Minute Destructive Campaign

Microsoft Security Research disclosed on September 25, 2026 that an agentic AI threat actor it tracks as Storm-3168 — publicly reported as JadePuffer — compromised two legitimate Azure service principals belonging to the same tenant and used them to map the victim's cloud environment before launching a highly automated destruction campaign. The attacker attempted to wipe Azure Storage accounts, Key Vaults, Function Apps, Virtual Machines, and App Services, while separately working to disable backup and recovery controls to hinder restoration. Microsoft observed two such attacks in June 2026; the destructive phase in the primary incident lasted roughly seven minutes and targeted more than 100 storage accounts. Although most targeted storage accounts were deleted, some survived because of Azure resource locks and storage-account-level deletion protections. No ransom note was recovered and Microsoft said it did not confirm successful data exfiltration, but the activity pattern is consistent with tactics that support ransomware and extortion operations.


Details

AttributeValue
Threat actorJadePuffer, tracked by Microsoft as Storm-3168
First documentedJuly 2026, by cloud security firm Sysdig, as the first known LLM-driven ransomware operation
Disclosure of this incidentMicrosoft Security Blog, September 25, 2026
Attack window observedTwo incidents in June 2026
Initial accessTwo compromised Azure service principals (client ID, secret, tenant ID) from the same tenant
Suspected exposure sourceCredentials for one service principal appeared in plaintext in a public GitHub issue before the attacks
Destructive phase durationApproximately 7 minutes
Primary targets100+ Azure Storage accounts, plus Key Vaults, Function Apps, Virtual Machines, and App Services
Confirmed deletionsMost targeted storage accounts, one Key Vault, one Function App, one App Service plan
Failed deletionsAzure SQL databases (blocked by an unsupported API version for that resource type)
Data exfiltration / ransom noteNot confirmed / not observed

How the Service Principals Were Compromised

Microsoft traced the likely initial access to a publicly exposed secret: an employee had posted the service principal's client ID, secret, and tenant ID in plaintext inside a public GitHub issue. Although the secret was later edited out, it remained retrievable through the issue's public edit history — a reminder that editing a GitHub comment does not scrub prior revisions from view. Microsoft was not able to confirm with certainty that this specific exposure was the vector used in the June attacks, but the timing and the nature of the leak made it the leading suspect.

Service principals are non-human identities that let applications and automated tooling authenticate to Azure and act on assigned resources without interactive sign-in. Because they often carry broad permissions and are easy to overlook in credential-hygiene reviews, they have become an attractive target for both human-operated and AI-driven intrusions.

The Attack Chain: Reconnaissance to Destruction

The operation unfolded as a tightly sequenced, largely autonomous chain. The first compromised service principal spent approximately 15.5 hours enumerating the tenant's resources, issuing more than 300 read operations across subscriptions, resource groups, storage accounts, virtual machines, web apps, and recovery-services configurations. About 90 minutes after that initial reconnaissance, a second compromised service principal began its own enumeration pass across two subscriptions, completing it in roughly five seconds — a pace well beyond typical human operator behavior.

Roughly 16 hours after the first activity, the second principal enumerated App Service configurations, then attempted a ListKey call against a storage account that did not exist. Less than a second later, the destructive phase began: within the seven-minute window, the actor issued more than 100 storage-account deletion attempts alongside deletions targeting Key Vaults, Function Apps, and App Service plans. About 30 minutes after the destructive burst, the same identity shifted to credential collection, successfully executing more than 30 ListKeys requests, including against storage tied to Azure Site Recovery — consistent with an effort to both harvest further credentials and strip away recovery options.

JadePuffer's Broader Pattern: From LLM-Driven Ransomware to AI Asset Targeting

Sysdig researchers first identified JadePuffer in July 2026, describing it as the first documented large language model-driven ransomware operation — one that uses AI agents to automate reconnaissance, credential theft, lateral movement, persistence, and encryption with minimal human direction. Sysdig subsequently reported that JadePuffer expanded its targeting to AI assets, training datasets, and vector databases, deploying a tool it called EncForge for that purpose. The Azure campaign Microsoft documented fits this evolving pattern: an actor capable of compressing what would normally be days of manual attacker tradecraft into hours, with a destructive payload that executes in minutes once access and context are established.

Impact Assessment

Impact AreaDescription
Data availabilitySuccessful deletion of the majority of targeted storage accounts, plus a Key Vault, Function App, and App Service plan, causing direct data and service loss
Recovery resilienceAttacker specifically targeted and removed Azure Site Recovery locks, indicating deliberate intent to defeat backup-based restoration
Partial containmentAzure resource locks and storage-account-level deletion protection blocked some deletion attempts, demonstrating the value of independent, defense-in-depth safeguards even after admin-level credential compromise
Database layerAzure SQL database deletions failed due to an unsupported API version — an unintentional technical gap rather than a security control, so it should not be relied upon
Extortion signalNo ransom note or confirmed data theft, but the tactics, scope, and speed are consistent with ransomware/extortion tradecraft rather than pure sabotage
Industry significanceOne of the most detailed public cases of a largely autonomous, agentic-AI-driven attack chain operating against major cloud infrastructure at production scale

Recommendations

For Azure Administrators

  • Treat any credential that has ever appeared in a public repository, issue, commit, or edit history as permanently compromised; editing or deleting the post does not invalidate the secret — rotate it immediately.
  • Apply Azure resource locks (CanNotDelete / ReadOnly) and storage-account-level deletion protection broadly, since these controls demonstrably blocked some destruction attempts even after the attacker held valid credentials.
  • Restrict and closely monitor permissions on Azure Site Recovery, Key Vaults, and other backup/recovery infrastructure — these are now explicit targets for disabling restoration, not just operational plumbing.

For Cloud Security Teams

  • Enforce least-privilege Azure RBAC on all service principals; audit for over-permissioned non-human identities, which are harder to monitor than interactive user accounts and were the sole entry point in this campaign.
  • Enable Microsoft Defender for Cloud across Resource Manager, Storage, Key Vault, App Service, and Database plans to surface anomalous enumeration and deletion activity before a destructive burst completes.
  • Run routine secret-scanning sweeps against public and internal repositories, including issue trackers and pull request history, not just source code — this incident's suspected entry point was a GitHub issue comment, not a committed file.

For SOC and Incident Response Teams

  • Build detections for rapid, sequential resource-enumeration-to-deletion patterns from service principal identities; the compressed timeline in this case (enumeration to destruction in roughly 16 hours, destruction itself in 7 minutes) is a hallmark of agentic, AI-paced attack tooling rather than manual operation.
  • Treat unusual ListKeys activity against storage accounts — especially in bulk or against Site Recovery-linked storage — as a high-priority indicator of credential-harvesting or anti-recovery staging.
  • Evaluate AI-aware investigation tooling, such as Microsoft's Project Perception, and AI asset-discovery tools like Microsoft Defender for AI Security (MDASH), given JadePuffer's documented expansion into targeting AI assets and vector databases.

Key Takeaways

  1. JadePuffer, tracked by Microsoft as Storm-3168, used two compromised Azure service principals from the same tenant to conduct reconnaissance and then a seven-minute destructive campaign against 100+ storage accounts and other resources.
  2. The suspected initial access vector was a service principal's client ID, secret, and tenant ID exposed in plaintext in a public GitHub issue — editing the comment later did not remove the secret from the issue's edit history.
  3. The attack chain moved from roughly 15.5 hours of reconnaissance to full destruction in under 16 hours total, with the actual deletion burst completing in minutes — a pace Microsoft and other researchers attribute to AI-agent automation rather than manual operation.
  4. Azure resource locks and storage-account-level deletion protection meaningfully blocked some destructive actions, while a lucky technical gap (an unsupported API version) incidentally saved Azure SQL databases from deletion.
  5. No ransom note or confirmed data exfiltration was observed, but the tactics align with ransomware/extortion tradecraft, and JadePuffer was first identified by Sysdig in July 2026 as an LLM-driven ransomware operation that has since expanded to targeting AI assets and vector databases via a tool called EncForge.
  6. The case is one of the most detailed public examples to date of a largely autonomous, agentic-AI-driven attack chain executing against production cloud infrastructure, underscoring the need for credential hygiene, least-privilege service principals, and layered deletion protections.

Sources