Cybersecurity

Microsoft Reveals Storm-3168 Attacks on Azure Using Compromised Service Identities

Microsoft observed activity linked to Storm-3168 that carried out extensive reconnaissance and deletion of Azure resources, along with the collection of storage access keys, using compromised service identities. The company believes the pattern is consistent with potential ransomware objectives, although no ransom note was observed and data exfiltration was not confirmed in this incident.

2026-09-25
4 min read
25 views
certi.news Editorial Team
Microsoft Reveals Storm-3168 Attacks on Azure Using Compromised Service Identities

Microsoft disclosed extensive destructive activity within an Azure environment that it linked to the Storm-3168 group, also known for its association with JADEPUFFER. The attack relied on two compromised service principals to conduct resource reconnaissance, delete cloud services, and attempt to collect credentials that could be used to access data or facilitate its subsequent exfiltration.

Microsoft says the investigation provides the first detailed description of Storm-3168 activity within Azure and expands what is known about JADEPUFFER, which Sysdig reported in July 2026 as the first documented ransomware operation to rely on agents. Microsoft did not confirm that the incident involved successful data exfiltration, nor did it observe a ransom note.

Reconnaissance Before Destruction

In early June 2026, one of the service identities spent approximately 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups, and resources, with more than 300 successful read operations. About 90 minutes later, the second identity enumerated virtual machines and resource groups across two subscriptions in just five seconds.

The two identities used infrastructure linked to Storm-3168, a single network fingerprint, and the user agent python-requests/2.34.2. After 16 hours, the second identity inspected App Service configuration stores, likely searching for exposed credentials, then attempted to access Azure OpenSearch resources without success before making a ListKey attempt against a nonexistent storage account.

Deleting Resources and Collecting Keys

Less than one second after the failed ListKey attempt, the destructive sequence began. The second identity carried out more than 150 operations related to deletion or credential collection over 35 minutes, while the main destructive phase lasted approximately seven minutes.

The activity included more than 100 attempts to delete Azure Storage accounts, most of which succeeded, in addition to deleting Azure Key Vault, a Function App, and an App Service plan. Parallel attempts were also made to delete Azure SQL databases, but they failed because an unsupported version of the application programming interface was used. The attackers also attempted to delete locks associated with Azure Site Recovery and Azure Backup, resources intended to protect recovery.

About 30 minutes after the last destructive operation, the identity made more than 30 successful ListKeys requests, returning access keys for storage accounts, including accounts associated with Azure Site Recovery.

What Does This Mean for Defenders?

Microsoft believes that the combination of resource deletion, targeting backup and recovery controls, and attempts to obtain storage keys is consistent with tactics that could support ransomware and extortion. However, the source alone does not prove that the ultimate objective was to extort the victim or that data was actually exfiltrated.

The investigation also highlights the importance of independent safeguards: resource locks and deletion protection at some storage-account levels prevented additional deletion operations, even though the compromised identity had broad administrative privileges. Conversely, the Azure RBAC roles granted to the group or directly to the service identity allowed it to carry out the destructive operations within the scope of its permissions.

Recommended Protection Measures

  • Rotate or revoke any exposed credentials immediately; deleting a secret from a public post does not make it invalid, and it may remain in the change history, cache, or archives.
  • Apply the principle of least privilege to service identities and review Azure RBAC roles and the resources each identity can access.
  • Protect backup and recovery resources and monitor attempts to modify or delete their locks.
  • Enable the appropriate Microsoft Defender for Cloud plans, including protection for Resource Manager, Storage, Key Vault, App Service, and databases.
  • Use AI-supported investigation and response capabilities, such as Project Perception, while securing AI applications and agentic systems.
News source
Microsoft Security Blog
Open original source ↗
c
Author

certi.news Editorial Team

In the same category

You may also like

View all news