Storm-3168 mapped an Azure tenant for 17 hours before a seven-minute deletion run
Microsoft says Storm-3168, also tracked as JADEPUFFER, used two stolen Azure service principals to try deleting more than 100 storage accounts. The deletions took about seven minutes, so the 17 hours of API reads before them were when anyone watching those identities had time to act.
The Watch · Security desk
What happened
- Reconnaissance began in early June 2026, when the first service principal spent about 15.5 hours running more than 300 successful reads against VMs, subscriptions and resource groups.
- About 90 minutes in, the second service principal swept two subscriptions in five seconds from the same infrastructure, network fingerprint and python-requests/2.34.2 user agent.
- Over 35 minutes, the second identity attempted more than 150 destructive or credential-related operations inside the tenant.
- Microsoft could not confirm the entry point but found the service principal's client ID, secret and tenant ID posted in plaintext in a public GitHub issue by a victim employee.
Why it matters
- Who's exposed exposure A service principal secret that ever appeared in a public GitHub issue stays usable after redaction, because the edit history keeps it readable until someone rotates it.
- What it limits constraint At a deletion attempt about every four seconds, the destructive phase leaves no time for a human response, so only controls configured beforehand limited the loss.
- What's now possible capability A shared user agent and network fingerprint across two service principals lets defenders tie the slow reconnaissance identity to the destructive one before the second acts.
- Who's exposed exposure The keys pulled after the deletions, including for Site Recovery storage, keep the victim's surviving data reachable until each key is rotated.
Next story · Security · Oct 1
Microsoft's 2026 defense report says cross-system intrusions become clearer when signals are joinedConfirmed6 publishers
The attacker gave each identity one job: one for reconnaissance, the other for discovery, destruction and credential theft [6]. The first worked slowly. Its more than 300 successful reads over about 15 and a half hours [7] average out to roughly one every three minutes or less [20]. The second swept virtual machines and resource groups across two subscriptions in five seconds [8]. Deletion began about 17 and a half hours after the first read [18], and about 71 seconds after the attacker's last inventory call [19].
The last call before the wipe failed. The second identity asked for the keys to a storage account that does not exist [10], and deletion started less than a second later [11]. It tried to remove more than 100 storage accounts and succeeded with most. It also deleted a Key Vault, a Function App and an App Service plan that appeared to support a single app [13]. The destructive phase lasted about seven minutes [12]. Over that window the storage deletions alone come to an attempt roughly every four seconds or faster [21].
Once deletion started, the controls that held were the ones set up in advance. Resource locks and storage account deletion protection kept several storage accounts from being removed [14]. Microsoft says such independent controls can protect resources even when a compromised identity has broad admin privileges [14]. Attempts to strip Azure Site Recovery and Azure Backup protection locks failed, though the identity also went after storage accounts with Terraform and backup names [3]. The SQL databases survived because of the attacker's own mistake. The script called an API version that resource type does not support [15].
Half an hour after the last deletion, the identity came back for keys. It sent more than 30 successful ListKeys requests, including for accounts tied to Azure Site Recovery [4]. One storage account in the same resource group as the deleted Key Vault and Function App had been left alone during the deletions. Later it had its keys pulled [5].
Microsoft could not confirm how the identity was first compromised [16]. Someone later edited the leaked secret out of the GitHub issue, but it stayed readable in the issue's public edit history [17]. "Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated," Microsoft wrote [17].
Sysdig first spotted the group's activity in July 2026 and called it the first documented agentic ransomware operation [2]. The Azure intrusion began in early June [7], about a month before that sighting [22]. The public Azure record covers one tenant and two identities [6]. It shows a Python client identifying itself as python-requests/2.34.2 [8], and a script with at least one plain error in it [15]. The published account does not say whether the victim's monitoring flagged the hours of reads, or whether a ransom demand followed.
What to watch
- Whether Microsoft or Sysdig report further tenants hit by Storm-3168, which would show a sustained campaign beyond this single victim.
- Whether Microsoft confirms the secret posted in the GitHub issue as the initial access vector.
- Whether later Storm-3168 intrusions fix the unsupported SQL API version call that spared the databases in this case.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence72
- Adoption
- Not scored
- Hype gap+25
- Incentives55
- Confidence70
Perspective Coverage
6 publishers- Builder
- Builder 23%
- Operator
- Operator 70%
- Investor
- Investor 7%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Microsoft published the first detailed look at what JADEPUFFER does inside Azure; Microsoft tracks the same actor as Storm-3168.
- [2]
Sysdig first spotted the group's activity in July 2026 and called it the first documented agentic ransomware operation.
- [3]
The compromised identity made several unsuccessful attempts to remove Azure Site Recovery locks and Azure Backup protection locks, and targeted storage accounts with names related to Terraform and backups.
- [4]
Half an hour after the last deletion, the same identity inventoried the storage accounts and sent more than 30 successful ListKeys requests, including for accounts tied to Azure Site Recovery.
- [5]
One storage account in the same resource group as the deleted Key Vault and Function App was spared during the cleanup, then hit with a successful key request later.
- [6]
The attack involved two compromised service principals from the same tenant; one was used for reconnaissance, while the other focused on discovery, destruction and credential theft.
- [7]
The reconnaissance began in early June 2026. The first identity spent about 15 hours and 30 minutes listing virtual machines, subscriptions, resource groups and other resources, completing more than 300 successful read operations.
- [8]
"About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2."
- [9]
16 hours later, the second service principal enumerated Azure App Service configuration stores, possibly looking for exposed credentials, and unsuccessfully attempted to look for Azure OpenSearch resources.
- [10]
70 seconds after this final inventory operation, the same service principal attempted a ListKey operation against a non-existent storage account.
- [11]
Less than a second after that failed request, the deletion started.
- [12]
In 35 minutes the identity attempted more than 150 destructive or credential-related operations, and the destructive part itself ran about seven minutes.
- [13]
The identity tried to delete over 100 storage accounts and succeeded with most of them. It also deleted a Key Vault, a Function App and an App Service plan from the same resource group, all of which appeared to support one app.
- [14]
Azure resource locks and storage account deletion protection prevented the attackers from removing several storage accounts. Microsoft says this shows independent security controls can still protect resources even when a compromised identity has broad admin privileges.
- [15]
The attackers tried to delete several Azure SQL databases, but all attempts failed because the script used an unsupported API version for that resource type.
- [16]
Microsoft says it cannot confirm how the identity was first compromised. It found that the client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the impacted organization.
- [17]
"The issue was later edited to remove the secret, but the secret remained accessible through the issue's public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated."
- [18]
Deletion began roughly 17 and a half hours after the first service principal started enumeration.
- [19]
About 71 seconds separated the final inventory operation from the first deletion.
- [20]
The first identity averaged roughly one successful read every three minutes or less.
- [21]
More than 100 storage account deletion attempts in a destructive phase of about seven minutes is an attempt roughly every four seconds or faster.
- [22]
The Azure intrusion Microsoft describes began about a month before Sysdig first spotted the group's activity.
Sources
6 independent publishers whose own reporting we read for this story.
- bleepingcomputer.comJadePuffer agentic AI attacks target Azure, destroy cloud resources
1 article · September 28, 2026
- csoonline.comAutonomous agents attack Azure using compromised identities, destroying resources | CSO Online
1 article · September 28, 2026
- darkreading.comJadePuffer AI Actor Compromises Azure Tenant in Destructive Cloud Attack
1 article · September 28, 2026
- microsoft.comStorm-3168: Agentic-driven cloud attacks using compromised service principals
2 articles · September 25, 2026
- securityaffairs.comStorm-3168, Linked to JADEPUFFER, Abused Stolen Azure Identities
1 article · September 28, 2026
- thehackernews.comJADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources
2 articles · September 28, 2026
Topics and entities
Topics
- Cloud workload identity security
- Ransomware
- Agentic AI Attacks
- Secrets and Credential Exposure
- Cloud backup and recovery resilience
Entities
- Microsoft
- CVE-2025-3248
- Microsoft Defender for Cloud
- Corsica Technologies
- JADEPUFFER
- Langflow
- Swimlane Inc.
- Sysdig
- GitHub
- Microsoft Azure