JadePuffer attackers deleted over 100 Azure storage accounts in 7 minutes

Microsoft said JadePuffer attackers, whom it tracks as Storm-3168, compromised two Azure service principals in early June and used them to destroy cloud resources and collect credentials. Over an 18-hour period, the attackers carried out what Microsoft called extensive Azure-focused resource destruction. The activity is linked to JadePuffer, the first documented agentic ransomware infection in which a large language model drove the entire extortion operation.thehackernews.com+1

JadePuffer first emerged in July, when researchers at cloud security company Sysdig documented an infection in which an AI model drove the whole extortion chain, from gaining initial access to compromising a production database server and destroying data. Microsoft's disclosure matters because it shows the same attacker moving beyond that initial campaign into destructive attacks on live Azure tenants, targeting storage, backups, and credentials rather than only encrypting data on compromised servers.theregister.com

What Microsoft observed in June

Microsoft researchers Yossi Weizman and Tushar Mudi wrote that Storm-3168 compromised two service principals belonging to the same cloud tenant. One machine identity handled reconnaissance and resource discovery; the other carried out destructive operations and credential collection. The attackers used the same network fingerprint and the user agent python-requests/2.34.2 across both identities. Microsoft could not determine how the service principals were initially hijacked.

The attack ran about 18 hours in total, with the discovery phase lasting about 15 hours and 30 minutes. During that window, the compromised service principal completed more than 300 successful read operations against Azure Virtual Machines, subscriptions, resource groups, and resources. Microsoft said this breadth of activity gave the threat actor visibility across the organisation's Azure environment. About 90 minutes after the first identity began collecting Azure information, the second service principal started reading Azure virtual machines and resource groups across two subscriptions in five seconds.

About 16 hours after the initial target reads, the second service principal discovered Azure App Service configuration stores and unsuccessfully attempted to find Azure OpenSearch resources. Seventy seconds later, it attempted a ListKey operation against a non-existent storage account. The destructive phase then began: over 35 minutes, the service principal made more than 150 destructive or credential-stealing attempts. The actual deletion activity lasted about seven minutes.

How the 18-hour attack unfolded

During those seven minutes, the attacker attempted to delete more than 100 Azure Storage accounts, and most deletions succeeded. Azure resource locks and storage-account-level deletion protections blocked a few. The attacker also deleted an Azure Key Vault, a Function App, and an App service plan, all belonging to the same resource group. Attempts to delete Azure SQL databases in parallel failed because the attacker used an unsupported API version for that resource type.

About 28 minutes after the destruction ended, the same service principal made an inventory request for Azure Storage Accounts and sent more than 30 successful ListKeys requests, asking the Azure Resource Manager to return each storage account's access keys. Those storage accounts included Azure Site Recovery-related accounts. The attacker also made multiple unsuccessful deletion attempts against Azure Site Recovery locks and Azure Backup protection locks that protected storage accounts.

Microsoft said the destructive activity, combined with attempts to interfere with recovery mechanisms and collect credentials, is consistent with tactics that support ransomware and extortion operations. However, Microsoft did not observe a ransom note and did not confirm successful data exfiltration in the described activity. The attacker's removal of backup and recovery protections suggests an effort to make restoration more difficult, according to Microsoft's researchers.

What failed and what succeeded

Microsoft noted that an employee of the same organisation had previously exposed client IDs, client secrets, and tenant IDs in plaintext in a public GitHub issue, though the researchers do not know whether that exposure led to the initial compromise. Since the beginning of 2026, Microsoft also observed repeated probing from Storm-3168-linked infrastructure against multiple Azure App services for different customers.

Microsoft recommended several mitigation steps for system administrators, including activating cloud workload protections, checking for secrets in public repositories, and evaluating Azure role-based access control permissions against least-privilege principles. The recommendations follow Microsoft's finding that the attackers moved from reconnaissance to destruction in a single 18-hour window, using legitimate machine identities to reach resources across two subscriptions in the same tenant.