Threats and Vulnerabilities
Storm-2949 Cloud Attack Path: From Social Engineering to Microsoft 365 and Azure Control-Plane Abuse
Microsoft reported a multi stage campaign in which a compromised cloud identity became a path into Microsoft 365 data and multiple Azure resources. The key lesson is not that a single security product failed.
Microsoft reported a multi-stage campaign in which a compromised cloud identity became a path into Microsoft 365 data and multiple Azure resources. The key lesson is not that a single security product failed. It is that identity recovery, directory permissions, data access, Azure role assignments, application deployment features, secrets, network controls, and virtual-machine administration formed one connected attack surface.
This analysis reconstructs the path at a defensive level from Microsoft’s May 2026 report, preserves the company’s confidence language, and translates the observed operations into concrete review and detection priorities. It does not identify the unnamed affected organization, reproduce indicators, or provide exploit instructions.
Executive summary
The Microsoft Defender Security Research Team report attributes the activity to a tracked actor it calls Storm-2949. Microsoft said the campaign began with targeted social engineering consistent with abuse of Microsoft Entra self-service password reset and expanded through:
- takeover of multiple cloud user identities;
- changes to authentication methods;
- Microsoft Entra directory discovery;
- attempts to add credentials to service principals;
- data discovery and large downloads from Microsoft 365 applications;
- use of privileged Azure role assignments;
- retrieval of Azure App Service publishing profiles;
- access to secrets in Azure Key Vault;
- changes to Azure SQL and Storage network settings;
- retrieval of storage keys or tokens;
- use of Azure virtual-machine management features; and
- installation or use of remote-access software on virtual machines.
Microsoft’s report describes a specific observed campaign. It does not establish that the same sequence is occurring in another tenant. Organizations should use it as a test of their own identity, cloud-control-plane, data, logging, and response assumptions.
The attack path Microsoft described
Stage 1: social engineering reached identity recovery
Microsoft assessed with high confidence that the actor used a technique consistent with known abuse of self-service password reset. In the described scenario, targeted users were persuaded to complete legitimate-looking authentication prompts during a fraudulent support interaction.
Microsoft reported that after reset access was obtained, the actor changed existing authentication methods and registered an attacker-controlled method. The activity was repeated against multiple users, including IT personnel and senior leadership.
Defensive meaning: phishing-resistant authentication is important, but identity recovery and authentication-method registration can become bypass routes if they rely on weaker proof. Review the complete lifecycle: initial registration, reset, method replacement, help-desk recovery, device registration, privileged recovery, and emergency access.
Stage 2: directory discovery mapped higher-value paths
Microsoft observed Microsoft Graph API queries used to enumerate users and applications. The actor searched names and role attributes and attempted to add credentials to a compromised service principal. Microsoft said that attempt failed because the identity lacked sufficient permission, but the enumeration continued.
Defensive meaning: a blocked persistence attempt is not the end of an incident. Repeated directory and service-principal discovery can show that an identity compromise is moving from user data toward durable application access.
Stage 3: Microsoft 365 data supported both theft and expansion
Microsoft reported discovery and exfiltration from Microsoft 365 applications, including OneDrive and SharePoint. It said IT documentation related to VPN and remote-access procedures was among the information sought and described one instance involving thousands of files downloaded through the OneDrive web interface.
Defensive meaning: collaboration repositories can contain both sensitive business data and instructions that make other systems easier to reach. Access governance should treat network diagrams, recovery procedures, privileged runbooks, vendor instructions, and secret-bearing documents as high-impact content.
Stage 4: Azure privilege connected identity to the management plane
Microsoft reported that compromised users held privileged custom Azure role-based access control roles on multiple subscriptions. The actor used legitimate Azure management operations rather than relying only on malware.
The distinction between management plane and data plane is important:
- the management plane changes or administers resources, permissions, networking, and configuration; and
- the data plane accesses the information or service inside a resource.
A role that appears operationally convenient may expose management actions that create new data-plane access.
Stage 5: App Service publishing profiles exposed deployment credentials
Microsoft observed use of the Microsoft.Web/sites/publishxml/action management operation to retrieve publishing profiles for Azure App Service instances. Microsoft explained that publishing profiles can contain credentials for deployment endpoints.
The actor did not immediately reach the primary application it wanted. Microsoft said it compromised secondary applications in the same ecosystem and continued looking for paths to higher-value resources.
Defensive meaning: secondary applications are not automatically low risk. An authentication service, internal API, staging component, integration service, or deployment endpoint may contain configuration and identity relationships that lead toward production.
Stage 6: Key Vault access expanded the blast radius
Microsoft reported that a compromised user had a privileged Owner role over a Key Vault. It observed changes to access configuration and access to dozens of secrets over a short period. According to Microsoft, those secrets included connection strings and identity credentials that enabled further access.
Defensive meaning: Key Vault protects stored secrets, but broad control-plane privilege can undermine the boundary. Vault ownership, role assignment, network access, secret-use design, logging, and alerts must be reviewed together.
Stage 7: SQL and Storage controls were changed for access
Microsoft reported manipulation of Azure SQL firewall rules and Storage network access settings. It also observed use of a Storage management operation to retrieve account keys and large data downloads using a script.
Microsoft said modified SQL firewall rules were later deleted, behavior it considered consistent with defense evasion.
Defensive meaning: cloud network-policy changes, key retrieval, and mass data access should be correlated. Individually, each operation may be legitimate administration. Together, especially from a newly compromised identity or unusual source, they may describe an incident.
Stage 8: virtual-machine management features became execution paths
Microsoft described use of Azure VM extensions, including Run Command and VMAccess. It reported use of VMAccess to create a local administrator and described subsequent endpoint activity, including remote-access software.
Defensive meaning: Azure administration can change a VM even when conventional network access is restricted. Security monitoring must include Resource Manager and Activity Log operations, extension deployment, run-command use, identity, and endpoint telemetry.
What is confirmed, assessed, and still unknown
| Information type | Careful interpretation |
|---|---|
| Observed operations | Microsoft reported the listed identity, Microsoft 365, Azure management, data, and endpoint activity |
| Threat-actor label | Storm-2949 is Microsoft’s tracking name |
| Initial method | Microsoft assessed with high confidence that activity was consistent with SSPR social-engineering abuse |
| Affected organization | Not publicly identified in the report |
| Complete incident scope | Not established outside Microsoft’s reported observations |
| Universal applicability | Not established; product configuration, permissions, licenses, and monitoring vary |
| Control effectiveness elsewhere | Must be tested in each organization |
This language avoids turning one vendor’s investigation into a generalized claim about all Microsoft 365 or Azure tenants.
Ten control questions to answer
1. Can a strong sign-in method be replaced through weak recovery?
Review who can reset credentials, delete authentication methods, register new methods, satisfy help-desk proofing, and recover privileged accounts. Alert on a reset followed by method registration, new device use, or privileged activity.
The Microsoft Entra passkey deployment plan should be implemented with equivalent care around account recovery.
2. Are privileged cloud accounts also normal collaboration users?
Separate day-to-day productivity from privileged administration where practical. A user who reads email and browses the web should not silently carry broad subscription, vault, or application-management rights.
Use time-limited activation, approval, justification, and review for high-impact roles. Emergency-access accounts require separate controls and monitoring.
3. Which custom roles include dangerous management actions?
Inventory custom Azure roles and identify permissions that can:
- assign roles;
- retrieve publishing profiles;
- list storage keys;
- change database or storage network access;
- alter Key Vault permissions;
- run commands or deploy VM extensions;
- change application settings; or
- manage identities and credentials.
Review the effective scope. A narrow-looking custom role assigned at a broad management-group or subscription level can create extensive access.
4. Can application deployment move away from reusable credentials?
Where supported, prefer managed identities, workload identity federation, and scoped deployment authorization over stored publishing credentials or long-lived secrets. Disable unnecessary basic-authentication deployment methods and rotate existing credentials as part of a controlled migration.
The separate guide to credential-free Azure workload identities should be used for architecture and audit planning, not as a promise that authorization risk disappears.
5. Who can change Key Vault access?
Distinguish the ability to administer the vault from the ability to use secrets. Review:
- Owner and User Access Administrator assignments;
- data-plane roles;
- legacy access policies;
- network access;
- private endpoints;
- diagnostic settings;
- secret-read volume;
- access-policy changes; and
- break-glass procedures.
Alert on high-impact access changes followed by unusual secret reads.
6. Are cloud network changes treated as security events?
Monitor changes to SQL firewalls, Storage public-network access, private endpoints, network rules, service endpoints, and application gateways. A successful connection after a newly authorized IP range should be investigated with the change record and identity context.
7. Are account keys and static credentials still necessary?
Account keys can provide broad access and are difficult to constrain compared with scoped identity authorization. Inventory which applications use keys or shared access mechanisms, why they remain, how they are protected, and whether their retrieval is monitored.
8. Can mass download be distinguished from normal work?
Set baselines for high-volume file, mailbox, SharePoint, OneDrive, Storage, SQL, and application access. Detection should consider identity risk, device, source network, time, data sensitivity, and prior control-plane operations—not volume alone.
9. Are Azure management operations visible to responders?
Confirm retention and routing for:
- Entra sign-in and audit logs;
- service-principal sign-ins;
- Azure Activity Logs;
- resource diagnostic logs;
- Key Vault audit data;
- Storage and database logs;
- Microsoft 365 audit data;
- endpoint detections; and
- secure-access, proxy, and network telemetry.
Test whether the incident team can correlate one identity across these sources.
10. Can containment disable the path without destroying evidence?
Prepare actions for:
- revoking sessions;
- disabling identities;
- removing malicious authentication methods;
- suspending privileged roles;
- blocking risky sources;
- containing applications or subscriptions;
- protecting logs;
- rotating affected secrets and keys;
- isolating virtual machines; and
- preserving a record of control-plane changes.
Containment should be coordinated with business owners so responders understand the operational consequence of disabling a production identity or resource.
A practical detection chain
High-value detections become more useful when correlated:
- password recovery or authentication-method change;
- sign-in from an unusual device, client, or source;
- Graph enumeration of users, roles, applications, or service principals;
- large Microsoft 365 searches or downloads;
- privileged Azure Resource Manager operations;
- publishing-profile retrieval or credential change;
- Key Vault access change and unusual secret reads;
- SQL or Storage network-policy change;
- storage-key retrieval or high-volume data access; and
- VM extension, Run Command, local administrator, or remote-access activity.
Not every item is malicious. The value comes from sequence, identity, scope, business context, and absence of an approved change.
What leaders should prioritize
First 30 days
- Review identity recovery and authentication-method registration.
- Separate or reduce standing privilege for high-risk users.
- Inventory custom roles and the dangerous actions they include.
- Confirm Microsoft 365, Entra, Azure Activity, Key Vault, Storage, SQL, and endpoint logging.
- Alert on high-impact access and network changes.
Next 60 days
- Migrate suitable applications away from reusable secrets and publishing credentials.
- Review Key Vault administration and data access separately.
- Establish mass-download and control-plane correlation.
- Exercise identity-to-cloud containment.
- Validate log retention with a real cross-source investigation.
Ongoing
- Re-certify privileged users, service principals, applications, managed identities, and custom roles.
- Remove unused applications and credentials.
- Re-test recovery and help-desk workflows.
- Track exceptions with owners and expiration dates.
- Update detections as Microsoft and other authoritative sources publish new observations.
Review the connected cloud control plane
OC Security Audit can independently assess Microsoft 365 and Azure identity, privilege, application credentials, Key Vault access, cloud logging, and incident readiness. Contact OC Security Audit for a focused cloud-security review.
Analysis prepared and reviewed by Ali Hassani, CISO.
Sources
- Microsoft Defender Security Research Team — Storm-2949 cloud attack
- Microsoft Entra self-service password reset documentation
- Microsoft Entra privileged identity management documentation
- Azure role-based access control documentation
- Azure Activity Log overview
- Azure Key Vault security overview
- Azure Storage security recommendations
- CISA cloud security technical reference architecture
OC Security Audit’s editorial standards describe how vendor-reported campaigns are attributed, rechecked, and corrected.
Last fact-checked July 2026. Campaign facts are attributed to Microsoft’s published observations and assessments; product capabilities and licensing should be rechecked before implementation.