The Storm-3168 Azure attack shows how quickly compromised application identities can lead to widespread cloud destruction. Researchers observed two service principals being used to map an Azure tenant, collect storage keys and delete resources in roughly seven minutes.
How the Storm-3168 Azure attack unfolded
Details published on 29 September 2026 describe a rapid and highly automated intrusion into a Microsoft Azure environment. Rather than relying on an interactive user account, the attackers operated through compromised service principals, which are identities used by applications, services and automation tools to access Azure resources.
Researchers identified two compromised service principals within a single tenant. The identities performed separate roles during the operation, indicating that the attackers had divided reconnaissance, data access and destructive activity across multiple credentials.
One service principal was used to map the tenant. This activity allowed the attackers to understand the cloud environment, identify accessible resources and determine what the compromised identity could reach.
The second service principal was used to collect storage keys and destroy resources. Storage account keys can provide extensive access to data held in Azure Storage, depending on how the account and its permissions are configured. Their collection created an opportunity for the attackers to access or remove hosted information outside the immediate management session.
The destructive phase affected Azure resources and recovery protections. The available report does not provide a complete inventory of the deleted services, the volume of data involved or the operational impact on the affected organisation. However, the seven-minute timeframe demonstrates that meaningful damage can occur before a conventional manual response process begins.
A seven-minute destructive sequence
The Storm-3168 Azure attack was notable for its speed. After gaining the ability to operate as the compromised service principals, the threat actor moved through discovery, key collection and resource deletion in approximately seven minutes.
This compressed timeline suggests the use of scripts or other automated procedures. Automated cloud operations can issue numerous management requests in quick succession, allowing an attacker to enumerate assets and delete resources much faster than a person navigating the Azure portal manually.
Researchers have not established that artificial intelligence directly controlled the Azure activity. That distinction is important because the operation has been associated with JADEPUFFER, which has previously been described in connection with agentic ransomware. The evidence reported for this incident supports automation, but not a conclusion that an AI agent independently directed the attack.
Compromised Azure service principals enabled access
The Storm-3168 Azure attack did not centre on a newly disclosed software vulnerability. No CVE, vulnerable Azure product version or affected operating system version was identified in the report. Instead, the intrusion depended on compromised cloud identities and the permissions already assigned to them.
A service principal represents an application or automated workload within Microsoft Entra ID and Azure. It can authenticate without a human user and receive permissions to subscriptions, resource groups, storage accounts or individual services. If its credential is stolen, an attacker may be able to operate with the same authorised access.
This makes the permissions attached to each identity central to the incident. A narrowly scoped service principal would restrict what an attacker could discover or delete. An identity with broad permissions can expose resources across a tenant and give an intruder the authority needed to dismantle services or interfere with recovery.
The available reporting does not explain how the two service principal credentials were originally compromised. It also does not identify the affected organisation, its sector or the precise Azure services that were removed. Those gaps mean the incident should not be interpreted as evidence of an Azure platform vulnerability.
Separation of attacker tasks
The use of two identities is a significant feature of the Storm-3168 Azure attack. It allowed the threat actor to separate environmental discovery from storage access and destruction, potentially making the activity appear as unrelated operations by different applications.
- The first compromised service principal mapped the Azure tenant and identified accessible resources.
- The second collected storage keys, which could enable access to data stored in Azure accounts.
- The second identity also conducted the destructive actions against cloud resources and recovery protections.
- The overall sequence took roughly seven minutes, leaving a very limited window for intervention.
Organisations monitoring identities individually could therefore miss the combined pattern. Correlating activity across service principals, subscriptions and resource groups is necessary to recognise that discovery by one identity may be connected to destructive activity by another.
Storm-3168 and the JADEPUFFER connection
Microsoft tracks the actor responsible for the reported activity as Storm-3168. Researchers linked the operation to JADEPUFFER ransomware activity documented in a separate intrusion, although the published account does not state that ransomware encryption was deployed inside this Azure tenant.
The connection provides context for the apparent objective. Collecting storage keys before deleting resources may support data theft, extortion or efforts to increase pressure by damaging recovery options. However, the evidence described publicly does not confirm what data was extracted, whether a ransom demand followed or whether the victim recovered the deleted services.
As of the report published on 29 September 2026, the confirmed scope was an observed Azure environment containing two compromised service principals. No total victim count or wider list of affected tenants was provided. The activity is therefore confirmed as an observed attack, but the available information does not establish the scale of any broader campaign.
Why this Azure identity attack matters
The Storm-3168 Azure attack illustrates that non-human identities can provide access as powerful as privileged employee accounts. These identities may also receive less scrutiny because their routine actions are expected to be automated and frequent.
The incident also narrows the practical response window. When discovery and deletion occur within minutes, alerts that are reviewed hours later may document damage rather than prevent it. Controls must be able to identify unusual management activity and restrict destructive permissions before credentials are compromised.
Actions organisations should take now
Azure administrators should first identify service principals with permissions to delete resources, access storage account keys or modify recovery controls. Those permissions should be removed where they are not essential and scoped to the smallest required subscription, resource group or service.
- Rotate credentials for service principals suspected of exposure and disable identities that are no longer required.
- Review Azure activity for rapid enumeration, storage key retrieval and deletion operations across multiple application identities.
- Correlate related actions across the tenant rather than assessing each service principal in isolation.
- Test whether recovery arrangements remain available when a privileged cloud identity is compromised.
These measures directly address the methods reported in the Storm-3168 Azure attack. The priority is to reduce the authority held by application identities and detect automated destructive activity quickly enough to contain it.
Originally reported by cybersecuritynews.com.
