Microsoft has uncovered a destructive Azure campaign linked to Storm-3168, also known as JADEPUFFER, in which attackers abused compromised service principals to map cloud environments, delete critical resources, target recovery safeguards, and obtain storage-account credentials.
The activity shows how a single exposed workload identity can give attackers the automation and permissions needed to cause rapid cloud-wide disruption.
Microsoft said Storm-3168 used two compromised service principals from the same Azure tenant. The first identity conducted extensive reconnaissance for approximately 15 hours and 30 minutes, completing more than 300 successful read operations.
Storm-3168 Hackers Abuse Compromised Service Principals
It enumerated virtual machines, subscriptions, resource groups, and other Azure assets, providing the attacker with an inventory of the victim’s cloud estate before destructive operations began.
A second service principal performed a much faster survey across two Azure subscriptions, identifying virtual machines and resource groups within five seconds.
About 16 hours later, it inspected Azure App Service configuration stores, possibly to find exposed application secrets. Both compromised identities communicated through infrastructure associated with Storm-3168 and used the python-requests/2.34.2 user agent.
The campaign then shifted almost instantly from reconnaissance to resource destruction. Less than one second after a failed ListKey request against a non-existent storage account, the second service principal began a destructive sequence that lasted around seven minutes.
During a 35-minute window, the identity attempted more than 150 destructive or credential-collection actions, including over 100 attempts to delete Azure Storage accounts. Microsoft reported that most targeted storage accounts were successfully deleted.
The attackers also deleted an Azure Key Vault, Function App, and App Service plan associated with the same resource group. They launched parallel deletion attempts against Azure SQL databases, but those actions failed because the actor used an unsupported API version for the Azure SQL resource type.
The identity also attempted to remove Azure Site Recovery locks and Azure Backup protection locks, indicating an apparent effort to weaken the victim’s ability to restore data and services.
Some deletion attempts failed because Azure resource locks and storage-account-level deletion protection remained effective, even though the compromised identity had broad permissions.
The incident highlights the value of independent recovery controls that a compromised service principal cannot easily remove.
Around 30 minutes after the final destructive action, Storm-3168 began storage-account inventory activity and successfully issued more than 30 ListKeys requests.
These requests retrieved storage-account access keys, including keys connected to Azure Site Recovery resources. Such keys could provide access to sensitive cloud data and support potential follow-on collection or exfiltration.
Microsoft did not observe a ransom note or confirm data theft, but said the combination of destruction, recovery impairment, and credential collection aligns with ransomware or extortion operations.
Microsoft assessed that the operation was automated or agentic due to its timing, division of tasks, and overlapping token use. Two deletion-capable tokens operated simultaneously for 70 seconds, allowing the attackers to target Storage and SQL resources concurrently.
The initial compromise method remains unconfirmed, although Microsoft found the tenant ID, client ID, and client secret had previously been published in plaintext in a public GitHub issue.
Even after the issue was edited, the secret remained available in the public edit history. Organizations should immediately revoke and rotate exposed credentials, enforce least-privilege Azure RBAC permissions, harden backup resources with independent protections, and monitor for anomalous Azure Resource Manager operations and bulk ListKeys requests.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
