JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources

Microsoft Links Storm-3168 to JADEPUFFER After Azure Storage-Wipe Attack

Microsoft Security Research has attributed a destructive early-June 2026 Azure incident to Storm-3168 — its tracking name for JADEPUFFER, the threat actor Sysdig first documented in July as the operator of the first fully LLM-driven ransomware attack. Researchers Yossi Weizman and Tushar Mudi describe the new activity, reported by The Hacker News on September 28, as "an evolution of the threat actor's tradecraft": rather than exploiting a vulnerable self-hosted application like Langflow, the attackers hijacked two Azure service principals and used their standing permissions to methodically map, then destroy, a victim's cloud estate — deleting more than 100 storage accounts in roughly seven minutes.

No ransom note was recovered and Microsoft could not confirm data was exfiltrated, but the combination of resource destruction, interference with backup and recovery controls, and bulk harvesting of storage access keys matches the pattern the company associates with ransomware and extortion operations.

Incident Details

Why Service Principals Are a High-Value Target

A service principal is the identity Azure assigns to an application, script, or automated workload so it can authenticate and act without a human signing in interactively — the cloud equivalent of a service account. They routinely carry broad, standing Azure RBAC permissions (Contributor, Storage Account Contributor, SQL DB Contributor) so that CI/CD pipelines, infrastructure-as-code tooling, and backend services can create, modify, and delete resources unattended. That combination — non-interactive, frequently over-provisioned, and rarely monitored with the same scrutiny as a human admin account — makes a compromised service principal one of the most efficient footholds an attacker can obtain in a cloud tenant: no phishing of a live user is required, multi-factor prompts never fire, and the credentials (a client ID, client secret or certificate, and tenant ID) are small enough to paste into a script, a CI config, or — as in this case — a GitHub issue.

Attack Mechanics: From Leaked Secret to Mass Deletion

Initial Access: A Secret That Wouldn't Stay Deleted

Microsoft could not conclusively confirm the entry vector used in this specific intrusion, but it flagged a striking finding during its investigation: the affected organization's service principal client ID, client secret, and tenant ID had previously been posted in plaintext in a public GitHub issue by an employee. The issue was later edited to remove the secret — but GitHub's public edit history preserved the original text, meaning the credential remained retrievable long after anyone assumed it had been scrubbed. Microsoft's core guidance from this finding: treat any publicly exposed credential as compromised permanently, regardless of whether the exposing post was edited or deleted, and rotate it immediately rather than assuming removal equals remediation.

Phase One: 15+ Hours of Quiet Reconnaissance

The first compromised service principal spent roughly 15.5 hours systematically enumerating the tenant — more than 300 successful read operations covering virtual machines, subscriptions, and resource groups, building a full inventory of the victim's cloud footprint before anything was touched. Around 90 minutes after that identity began, a second compromised service principal from the same tenant started its own discovery pass across two subscriptions, and roughly 16 hours in, probed Azure App Service configuration stores — a location commonly used to store connection strings and application secrets — and unsuccessfully searched for Azure OpenSearch resources.

Phase Two: A Seven-Minute Destructive Burst

The pivot from reconnaissance to destruction was almost instantaneous: about 70 seconds after a failed ListKey request against a storage account that didn't exist, the second service principal launched a destructive sequence that ran for approximately seven minutes as part of a broader 35-minute window containing 150+ destructive or credential-collection operations. More than 100 delete attempts were made against Azure Storage Accounts, and the large majority succeeded. The same operator also deleted an Azure Key Vault, a Function App, and an App Service plan in the same environment. Attempts against Azure SQL databases failed — Microsoft noted the attacker used an unsupported API version — and attempts to strip protection from Azure Site Recovery and Azure Backup locks were blocked outright, with those safeguards holding even though the compromised identity otherwise had broad Contributor-level access.

Microsoft traced the destructive identity's activity to five unique OAuth tokens — four used for deletion operations and one dedicated to storage-account inventory and key retrieval — with two deletion tokens active concurrently for about 70 seconds, one driving storage deletions and the other mixing storage and SQL targets. Both compromised service principals shared infrastructure and network fingerprints linked to Storm-3168, and all requests carried the identical python-requests/2.34.2 user agent — a detail Microsoft says, combined with the tight timing and division of labor across identities and overlapping token streams, "strongly indicates automated or scripted execution" rather than manual, hands-on-keyboard operation.

Phase Three: Harvesting Keys on the Way Out

About 30 minutes after the last destructive action, the attacker pivoted to credential collection, issuing more than 30 successful ListKeys requests and retrieving Azure Storage account access keys — including keys tied to accounts associated with Azure Site Recovery. Microsoft flagged this as consistent with either covering tracks, enabling a later return, or setting up a follow-on data-theft stage, even though no exfiltration was confirmed in this incident.

How This Connects to Earlier JADEPUFFER Activity

CosmicBytez Labs has covered JADEPUFFER twice before: its July 2026 debut as the first fully LLM-driven ransomware attack, which exploited Langflow's CVE-2025-3248 to gain code execution and then used an autonomous AI agent to encrypt databases with MySQL's built-in encryption functions, and its follow-up campaign deploying custom ENCFORGE ransomware purpose-built to target AI model data and training pipelines. This Azure incident is a distinct campaign against a different target — there is no Langflow, no self-hosted application exploit, and no AI-asset targeting here. What connects it to the earlier activity, per Microsoft, is the underlying operating pattern: tight automation, minimal human latency between stages, and a willingness to act destructively at scale once access is obtained. Microsoft's blog explicitly frames this as the first detailed public look at JADEPUFFER/Storm-3168's cloud-native tradecraft, expanding the group's known playbook beyond the Langflow-based intrusions into direct abuse of legitimate cloud identity primitives.

Impact Assessment

Recommendations for Azure and Cloud Security Teams

1. Never store service principal credentials in source code, config files, CI/CD pipelines, or issue trackers — including "temporary" pastes in GitHub issues, PR descriptions, or commit messages. Once exposed publicly, a secret should be considered permanently burned.
2. Treat edited or deleted public posts containing secrets as still-exposed. GitHub (and most platforms) preserve edit history; rotate the credential immediately rather than relying on the post being taken down.
3. Apply least-privilege RBAC to every service principal. Broad, standing Contributor or Storage Account Contributor grants — especially inherited via group membership — turn a single leaked secret into tenant-wide blast radius.
4. Enable and enforce resource locks and deletion protection on storage accounts, Key Vaults, and backup/recovery infrastructure. This incident's own evidence shows locks are the one control that held when identity-based permissions did not.
5. Restrict and closely monitor access to backup and recovery resources specifically — attackers increasingly target these first, or in parallel with primary data, to remove the fallback option before demanding payment.
6. Turn on Microsoft Defender for Resource Manager, Storage, Key Vault, App Service, and Databases to catch anomalous deletion bursts and unusual ListKeys volume in near-real time.
7. Alert on automation fingerprints, not just failed logins: unusual user agents (e.g., raw python-requests), high-velocity API call sequences, and multiple concurrent tokens from a single service principal are strong signals of scripted, non-human activity.
8. Rotate all credentials — client secrets, storage keys, and connection strings — for any service principal or resource touched by a suspected compromise, since key harvesting late in this attack shows operators plan for persistence beyond the initial destructive event.

Key Takeaways

1. Microsoft has formally linked Storm-3168 to JADEPUFFER, the actor behind the first documented LLM-driven ransomware attack — but this is a new, distinct cloud-identity campaign, not a repeat of the earlier Langflow exploitation.
2. A leaked GitHub secret may have enabled the breach. The victim's service principal client ID, secret, and tenant ID were posted in plaintext in a public GitHub issue; edit history kept the secret retrievable after the post was "cleaned up."
3. Two compromised service principals split the work — one spent 15+ hours on silent reconnaissance, the other executed the destructive and credential-harvesting phases.
4. Destruction was fast and automated: 100+ storage accounts deleted in roughly seven minutes, with timing, overlapping tokens, and a consistent python-requests user agent pointing to scripted execution.
5. Resource locks and backup protection were the controls that actually held — even with broad Contributor-level access, the attacker could not override pre-configured deletion protection on Site Recovery and Backup resources.
6. No ransom note or confirmed exfiltration — but the pattern matches extortion tradecraft. Deleting backups while harvesting storage keys keeps both leverage options open for the attacker.

Sources

• The Hacker News — JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources
• Microsoft Security Blog — Storm-3168: Agentic-driven cloud attacks using compromised service principals