Microsoft Storm-3168 Azure Attack: How Compromised Service Principals Deleted Cloud Resources — and How to Defend
Cybersecurity & Privacy · Threat analysis
Microsoft says Storm-3168 used compromised Azure service principals to discover cloud resources, delete infrastructure at machine speed, and collect storage account keys. The incident is a reminder that a non-human identity with a leaked secret and broad RBAC permissions can become as dangerous as a compromised administrator.
Featured image credit: CSIRO / Wikimedia Commons, CC BY 3.0. Contextual data-center imagery; this is not the affected Azure environment.
This is not a consumer Microsoft-account warning. The highest-risk audience is organizations running Azure workloads with service principals, long-lived client secrets, broad Contributor-style permissions, or recovery controls that can be changed by the same identity plane as production resources.
What Microsoft says happened in the Storm-3168 Azure attack
Microsoft Security Research says two compromised service principals from the same tenant were involved. One spent roughly 15 hours and 30 minutes enumerating Azure virtual machines, subscriptions, resource groups and other resources, producing more than 300 successful read operations. A second service principal then enumerated virtual machines and resource groups across two subscriptions in about five seconds.
After further discovery, the destructive phase accelerated sharply. Microsoft says the second service principal attempted 150+ destructive or credential-collection operations in 35 minutes. The core destructive sequence lasted about seven minutes and included more than 100 Azure Storage account deletion attempts.
Most of the targeted storage accounts were successfully deleted, according to Microsoft. An Azure Key Vault, Function App and App Service plan were also deleted. Attempts to delete multiple Azure SQL databases failed because the actor used an unsupported API version for that resource type. Some storage deletions were blocked by resource locks or deletion protection, which is exactly why independent recovery controls matter.
Storm-3168 attack timeline: discovery, destruction and key collection
| Stage | What Microsoft observed | Why it matters |
|---|---|---|
| Reconnaissance | 300+ successful read operations over about 15h 30m from one compromised service principal | Broad discovery can map subscriptions, VMs and resource groups before destructive actions begin |
| Rapid discovery | A second service principal enumerated VMs and resource groups across two subscriptions in about five seconds | Valid non-human credentials can automate cloud discovery quickly |
| Destruction | 150+ destructive or credential-related operations in 35 minutes; core deletion sequence about seven minutes | Manual response windows can be very short once destructive automation starts |
| Storage deletion | 100+ deletion attempts; most targeted storage accounts were deleted | Broad Storage Account Contributor-style rights can translate into major data availability risk |
| Credential collection | 30+ successful ListKeys requests after the destructive phase | Storage keys can expand access to data even after resource damage |
What is an Azure service principal?
A service principal is a Microsoft Entra workload identity used by an application, script, automation job or service to authenticate and access resources. Microsoft describes workload identities as applications, service principals and managed identities. Unlike a human user, a service principal does not normally sign in with a password plus MFA; it authenticates with mechanisms such as client secrets, certificates, managed identities or federated credentials.
That makes lifecycle and credential hygiene especially important. Microsoft notes that workload identities often cannot perform MFA, may lack a formal lifecycle process, and may need credentials stored somewhere. If a long-lived secret is exposed and the service principal already holds broad Azure RBAC permissions, the attacker can inherit those permissions.
In the Storm-3168 incident, Microsoft says the destructive operations followed the identity’s existing role assignments. A group-granted Storage Account Contributor role authorized storage operations, while direct Contributor access enabled deletion of application resources and a key retrieval. This is a practical demonstration of the least-privilege principle behind Zero Trust: the blast radius of a stolen identity is heavily influenced by what that identity was already allowed to do.
The exposed-secret clue — and what Microsoft could not confirm
Microsoft says the client ID, client secret and tenant ID for one service principal had previously appeared in plaintext in a public GitHub issue posted by an employee of the affected organization. The issue was later edited, but the secret remained visible through public edit history.
The defensive lesson is still clear: deleting a secret from a repository, issue or page does not revoke it. Copies can remain in commit history, caches, logs, mirrors or screenshots. Microsoft explicitly recommends treating publicly exposed credentials as compromised and rotating or revoking them immediately.
Where supported, Microsoft recommends moving away from long-lived client secrets toward managed identities, certificates or workload identity federation. Managed identities are especially useful for Azure-hosted workloads because Azure manages the underlying credentials, reducing the need to store reusable secrets in code or configuration.
Was Storm-3168 ransomware? The public evidence is narrower
Microsoft describes the activity as consistent with tactics that can support ransomware and extortion. The actor targeted production resources, attempted to interfere with recovery-related protections, and collected storage account keys that could provide access to data. However, Microsoft says it did not observe a ransom note in this Azure activity and did not confirm successful exfiltration.
That distinction is useful because “ransomware” is often used too broadly. The incident clearly involved destructive behavior and ransomware-aligned objectives, but the public Microsoft report stops short of saying that this particular Azure tenant received a ransom demand.
The broader JADEPUFFER context comes from Sysdig Threat Research, which documented an earlier campaign it assessed as the first end-to-end agentic ransomware operation. Microsoft says the Azure activity expands the public picture of that same actor.
What “agentic-driven” means in this incident
“Agentic” should not be read as “an AI independently decided to attack Azure.” Microsoft says the timing, division of work across multiple service principals and overlapping token streams strongly indicate automated or scripted execution. It also places the incident in a broader shift toward AI-orchestrated attacks.
The practical security issue is speed and coordination. Once valid credentials and permissions exist, automation can perform reconnaissance, destructive actions and key retrieval faster than a human analyst may be able to manually follow each event. That is why detection and prevention controls have to work before or during execution, not only after an incident is obvious.
For readers following the AI-agent side of this trend, DPB’s NVIDIA OpenShell and Sentry explainer covers a different part of the problem: constraining and monitoring agents before they act outside approved boundaries.
Who should review their Azure environment now
Organizations should prioritize review if any of the following apply:
- Service principals use client secrets stored in repositories, CI/CD variables, tickets or configuration files.
- Workload identities hold broad Contributor, Storage Account Contributor, SQL DB Contributor or similarly powerful roles at subscription or resource-group scope.
- Service principals have not been inventoried, reviewed or tied to a current owner and lifecycle process.
- Production and backup controls share the same administrative trust boundary, allowing one compromised identity to damage both live resources and recovery paths.
- Azure activity logs and Microsoft Defender alerts are not actively monitored for unusual Resource Manager, Key Vault, Storage or App Service behavior.
Consumers using Microsoft 365, Windows or a personal Microsoft account are not the primary population described in Microsoft’s Storm-3168 report. The incident concerns Azure workload identities and cloud-resource permissions.
Seven defensive actions Microsoft’s findings make urgent
- Find exposed credentials. Search public and private repositories, issue trackers, build logs and configuration stores for app IDs, tenant IDs, client secrets, storage keys and connection strings.
- Rotate or revoke immediately. Do not assume deleting the original disclosure fixes the problem. Investigate historical sign-ins and token use after rotation.
- Reduce RBAC scope. Review service principals holding Contributor-style roles and replace broad assignments with the smallest role and scope the workload actually needs.
- Prefer secretless authentication. Use managed identities for Azure resources or workload identity federation where supported; use certificates rather than client secrets when secretless options are not practical.
- Protect recovery controls separately. Enable Azure Backup protections appropriate to the environment, including immutability, soft delete and multiuser authorization where supported.
- Turn on relevant Defender coverage. Microsoft recommends workload protections for Resource Manager, Storage, Key Vault, App Service and databases where applicable.
- Hunt for unusual management-plane activity. Review sudden enumeration, mass deletion attempts, ListKeys activity, suspicious proxy IPs and unusual application access to Key Vault or Storage.
Why backup and recovery controls need a separate trust boundary
The Storm-3168 report is a useful example of why backup security cannot be treated as an afterthought. Microsoft observed attempts against Azure Site Recovery locks and Azure Backup protection locks, while some storage deletions were blocked by protection mechanisms.
Microsoft’s current Azure Backup guidance recommends controls such as multiuser authorization (MUA), immutable vaults and soft delete. MUA can require approval from a separate security administrator for destructive or high-impact backup operations. Locked immutability prevents backup data from being modified or deleted before its retention period expires.
The architectural point is more important than any single product feature: recovery must survive compromise of the production administration plane. If the same identity can delete production data and remove the backups that would restore it, the backup exists but the recovery design is weak.
Detection clues and indicators defenders can use
| Signal | Why to investigate |
|---|---|
| Large bursts of Azure Resource Manager reads | Can indicate automated discovery of subscriptions, VMs, resource groups and workloads |
| Mass storage-account deletion attempts | Matches destructive behavior Microsoft observed in this incident |
High-volume or unusual ListKeys operations | Can expose storage account keys and enable broader data access |
| Unexpected service principal accessing Key Vault | Credential access and secret retrieval are high-value attacker objectives |
| Attempts to alter backup or recovery protections | Can indicate preparation to make recovery harder after destructive actions |
| Resource Manager operations from suspicious proxy infrastructure | Microsoft Defender for Resource Manager includes detections for suspicious proxy-based ARM activity |
Microsoft published three defanged IP indicators for the observed activity: 45.131.66[.]106, 34.153.223[.]102 and 64.20.53[.]230. Indicators age quickly, so they should support—not replace—behavioral detections and identity review.
Bottom line
Storm-3168 is less a story about a magical new attack technique than about a familiar security failure operating at machine speed: a powerful identity was compromised, the identity already had broad permissions, and automation converted those permissions into rapid destructive action.
The durable defense is therefore not a single indicator or alert. It is a combination of secretless workload identity where possible, aggressive credential rotation when exposure occurs, least-privilege RBAC, independent recovery protections and monitoring that treats service principals as first-class security identities.
Primary sources: Microsoft Security Research on Storm-3168; Microsoft Entra workload identities; Azure RBAC best practices; Azure Backup security best practices.
