Storm-3168, Linked to JADEPUFFER, Abused Stolen Azure Identities
Storm-3168, Linked to JADEPUFFER, Abused Stolen Azure Identities
September 28, 2026 
Microsoft details Storm-3168, the JADEPUFFER-linked actor that used stolen service principals to delete Azure storage in minutes and harvest keys.
Microsoft just published the first detailed look at what JADEPUFFER does inside Azure. Sysdig first spotted the group’s activity in July 2026 and called it the first documented agentic ransomware operation. Microsoft tracks the same actor as Storm-3168, and its new report shows how fast this crew moves once it holds valid cloud credentials.
The attack involved two compromised service principals from the same tenant. These are non-human identities that applications use to communicate with Azure. One was used for reconnaissance, while the other focused on discovery, destruction and credential theft. It was a clear division of tasks between the two identities.
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. About 90 minutes later, the second identity carried out similar activity across two subscriptions in just five seconds. Both identities used Storm-3168 infrastructure, the same network fingerprint and the same user agent, python-requests/2.34.2.
“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.16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.” reads the report published by Microsoft. “70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.”
Sixteen hours later, the second identity checked App Service configuration stores, possibly hunting for exposed credentials, and tried to find Azure OpenSearch resources without luck. Seventy seconds after that, it asked for the keys of a storage account that doesn’t exist. Less than a second after that failed request, the deletion started.
In 35 minutes the identity attempted more than 150 destructive or credential related operations, and the destructive part itself ran about seven minutes. It 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 that one app.
Not everything was deleted. Azure resource locks and storage account deletion protection prevented the attackers from removing several storage accounts. Microsoft says this shows that independent security controls can still protect resources even when a compromised identity has broad admin privileges.
The attackers also tried to delete several Azure SQL databases at the same time, but all the attempts failed because the script used an unsupported API version for that resource type. In this case, a simple technical error ended up blocking part of the attack.
The attackers also targeted backup and recovery systems. The compromised identity made several unsuccessful attempts to remove Azure Site Recovery locks and Azure Backup protection locks. It also targeted storage accounts with names related to Terraform and backups, suggesting that the attackers were trying to make recovery more difficult.
Half an hour after the last deletion, the same identity came back for keys. It inventoried the storage accounts and sent more than 30 successful ListKeys requests, including for accounts tied to Azure Site Recovery. 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.
Microsoft says it can’t confirm how the identity was first compromised. It did find 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.
“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.” continues the report. “We could not confirm whether this secret was used for the activity described here.”
The report also describes separate probing from Storm-3168 linked infrastructure since the start of the year. The targets were Azure App Services belonging to different customers, and the paths included WordPress administration, PHP-CGI, LangFlow’s code validation endpoint at /api/v1/validate/code, and other web shell style locations. None of those targets overlapped with the affected subscriptions, and Microsoft found no route from an App Service to Azure Resource Manager credentials for this tenant. The three IP addresses tied to the probing and malicious requests are 45.131.66[.]106, 34.153.223[.]102, and 64.20.53[.]230.
Why call it automated? The timing, the split between two identities, and overlapping token streams point to scripted execution.
“The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.” Microsoft states.
The destructive identity used five unique tokens, four for deletion and one for storage inventory and key retrieval, and two of the deletion tokens were active at the same time for 70 seconds. One focused on storage deletion, the other on a mix of storage and SQL.
The permissions match what the identity already had. A group-granted Storage Account Contributor role covered the storage deletions. Direct Contributor access covered the three application resource deletions and one key retrieval, and direct SQL DB Contributor access covered the failed SQL attempts. The attackers didn’t need to escalate anything, because the access was already there.
Microsoft describes the pattern as consistent with ransomware and extortion, but with a caveat. It didn’t see a ransom note or confirm data exfiltration in this case. What it did see is destruction, interference with recovery, and collection of keys that could open the door to data theft later.
The advice starts with the boring part. Treat any credential exposed on the public internet as compromised, revoke or rotate it, and check its history of use. Keep secrets out of code, config files, repositories, and issues, and give service principals only the permissions their apps need.
Turn on the relevant Defender for Cloud plans for Resource Manager, Storage, Key Vault, App Service, and Databases. Restrict access to backup and recovery resources, and watch for attempts to change or remove their protection. Microsoft also points defenders toward Project Perception for AI agents that investigate at machine speed, and MDASH for finding AI assets and their weak spots.
“Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, JADEPUFFER)
About Author
