Storm-3168 Deletes Azure Resources in 7-Minute Destructive Cloud Attack
Microsoft says Storm-3168 used stolen Azure identities to delete cloud resources within about seven minutes.
Microsoft says Storm-3168 used two compromised service principals in one Azure tenant for reconnaissance and rapid destruction. In early June 2026 one identity completed more than 300 successful reads over about 15 hours 30 minutes; a second identity then spent roughly seven minutes making more than 100 storage-account deletion attempts, most successful, and deleted a Key Vault, Function App, and App Service plan. Azure SQL deletions failed on an unsupported API version, while locks and deletion protection blocked some attempts; about 30 minutes later the actor made more than 30 successful ListKeys calls, including Site Recovery accounts. Researchers link the case to earlier JADEPUFFER agentic ransomware activity but did not confirm a ransom note, successful theft, or direct AI control.
- Two stolen service principals mapped one Azure tenant, then destroyed resources.
- More than 100 storage-account deletions in about seven minutes mostly succeeded.
- A Key Vault, Function App, and App Service plan in the same group were removed.
- SQL deletions failed; locks and deletion protection blocked some attempts.
- The actor later made 30-plus successful storage ListKeys calls.
Full article782 words · extracted from cybersecuritynews.com · click to collapse
Storm-3168 used compromised cloud identities to carry out a destructive attack against an Azure environment in minutes. The operation shows how a stolen application credential can give an intruder broad control over hosted data, services, and recovery protections.
It also highlights the growing threat from automated cloud attacks. The activity is linked to JADEPUFFER agentic ransomware operations, documented earlier in a different intrusion.
Researchers found two compromised service principals inside one tenant, with one mapping the environment and the other destroying resources and collecting storage keys.
Microsoft tracks the actor as Storm-3168. Researchers did not establish that AI directly controlled these Azure operations. Microsoft analysts identified the Azure activity.
Microsoft said in a report shared with Cyber Security News (CSN) that the campaign targeted Azure Storage accounts, SQL databases, Key Vaults, Function Apps, App Services, and recovery controls.
The investigation did not confirm a ransom note or successful data theft, but the combination points to a likely extortion-focused objective.
The case underlines a cloud security problem that begins long before a deletion command is issued. The client ID, secret, and tenant ID for one service principal had appeared in plaintext in a public GitHub issue, although researchers could not verify that this secret was used. Removing a secret from a post does not revoke it or erase its history.
Storm-3168 Deletes Azure Resources
In early June 2026, the first compromised identity spent about 15 hours and 30 minutes performing more than 300 successful read operations.
It listed virtual machines, subscriptions, resource groups, and other resources. About 90 minutes later, the second identity checked virtual machines and groups across two subscriptions in only five seconds.
That second service principal later examined App Service configuration stores, possibly searching for exposed credentials, and unsuccessfully queried Azure OpenSearch resources.
Seventy seconds after its last inventory action, it attempted to retrieve a key from a storage account that did not exist. Less than a second later, the destructive sequence began.
Over roughly seven minutes, Storm-3168 made more than 100 attempts to delete storage accounts, with most targeted accounts successfully removed.
.webp)
It also deleted a Key Vault, Function App, and App Service plan tied to the same resource group. Resource locks and account-level deletion protection stopped several attempts, showing that independent safeguards can limit damage.
The intruder also tried to delete several Azure SQL databases in parallel, but every attempt failed because it used an unsupported API version.
It separately targeted Site Recovery and Azure Backup protection locks. Earlier reporting on Azure API role flaws shows why narrowly named cloud roles still require careful permission reviews.
Stolen Identities Raise Recovery Risks
Around 30 minutes after the final destructive actions, the same identity sent more than 30 successful ListKeys requests for Azure Storage accounts, including accounts related to Site Recovery.
Access keys can expose sensitive data and create a path for later collection. The sequence also targeted storage accounts with terraform and backup-themed names, increasing the risk of impaired recovery.
The timing and use of multiple identities suggest coordinated automation. Microsoft observed five distinct tokens for the service principal used in deletion and key collection; four supported deletion, while one handled storage inventory and key retrieval.
Two deletion tokens were active during the same 70-second window, distributing operations between storage and SQL targets.
Organizations should promptly revoke and rotate every publicly exposed credential, then investigate its previous use. They should keep secrets out of source code, tickets, repositories, and configuration files, while applying least privilege to workload identities.
A separate report on Azure Arc credential exposure demonstrates how accessible deployment secrets can become powerful entry points.
Administrators should restrict access to backups and recovery controls, monitor attempts to change or remove protections, and review identity permissions regularly.
Security teams should also hunt for unexpected resource discovery, high-volume key retrieval, and unusual deletion activity. Related reporting on Key Vault access risks illustrates the importance of tracking risky credential use across the tenant.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| IPv4 | 45.131.66[.]106 | App Service probing and malicious Azure Resource Manager requests |
| IPv4 | 34.153.223[.]102 | App Service probing |
| IPv4 | 64.20.53[.]230 | App Service probing |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
Tushar is a senior cybersecurity and breach reporter. He specializes in covering cybersecurity news, trends, and emerging threats, data breaches, and malware attacks. With years of experience, he brings clarity and depth to complex security topics.