In May 2026, Microsoft Threat Intelligence published a detailed account of a sophisticated cloud intrusion conducted by a threat actor tracked as Storm-2949. The campaign began with a phone call. An attacker impersonating IT support convinced employees to approve MFA prompts during a fake account verification process. That single social engineering success gave Storm-2949 access to Microsoft Entra ID, then Microsoft 365, then Azure Key Vault, App Services, Storage accounts, SQL databases, and production virtual machines. No malware. No CVE. No zero-day. Just a compromised identity and legitimate cloud management tools used by the wrong person.
What Happened
Storm-2949 is a threat actor focused on a single objective: exfiltrating as much sensitive data as possible from target organisations’ high-value cloud assets. The campaign Microsoft documented moved methodically from identity compromise through cloud infrastructure, touching every layer of a Microsoft cloud environment – SaaS, PaaS, and IaaS, while blending into expected administrative behaviour.
The campaign followed a clear attack chain:
- Phase 1 — SSPR abuse and social engineering: Storm-2949 initiated Microsoft Entra ID Self-Service Password Reset (SSPR) flows on behalf of targeted employees. Posing as internal IT support, attackers contacted employees by phone and convinced them to approve MFA prompts during a fake routine account verification. Once the user approved the prompt, the attacker reset the password, removed all existing authentication methods — phone numbers, email addresses, Microsoft Authenticator registrations — and enrolled their own device as a trusted MFA authenticator. The legitimate user was locked out; the attacker had persistent, MFA-protected access.
- Phase 2 — Tenant enumeration via Microsoft Graph API: Using a custom Python script, Storm-2949 issued automated Microsoft Graph API requests to enumerate all users, groups, applications, and service principals in the compromised tenant. The script searched for accounts by name patterns and role attributes to identify privileged identities and high-value targets.
- Phase 3 — Lateral identity expansion: Using the same SSPR social engineering technique, Storm-2949 compromised three additional cloud user accounts within the same organisation, expanding their foothold across multiple privileged identities.
- Phase 4 — Cloud data exfiltration: With privileged Entra ID access established, Storm-2949 moved to Microsoft 365 applications. They accessed OneDrive and SharePoint, downloaded thousands of files in single bulk operations, and focused specifically on IT documentation covering VPN configurations and remote access procedures — intelligence for follow-on lateral movement or future attacks.
- Phase 5 — Azure infrastructure pivot: From the compromised cloud identities, Storm-2949 pivoted into the organisation’s Azure-hosted production environment, accessing Key Vault, App Services, storage accounts, SQL databases, and virtual machines.
Microsoft disclosed the campaign on 18 May 2026. Indicators of compromise include three IPv4 addresses: 176.123.4.44, 91.208.197.87, and 185.241.208.243.
How It Happened
The Storm-2949 campaign succeeded because of three compounding failures that are endemic to cloud identity programmes:
SSPR as an unauthenticated identity reset surface. Microsoft’s Self-Service Password Reset is designed to reduce IT overhead by allowing users to reset their own passwords. The process requires the user to complete MFA verification. But SSPR verification methods — push notifications, SMS passcodes, email links — verify that someone has access to something. They do not verify who that person actually is. Storm-2949 did not need to steal any device or SIM. They just needed a phone call convincing enough to make the user approve the prompt. Once that approval came through, the password reset was legitimate from the platform’s perspective.
MFA as a false security ceiling for privileged accounts. Standard MFA — SMS codes, authenticator app OTPs, push notifications, does not protect against social engineering of the MFA response itself. Storm-2949 specifically targeted IT personnel and senior leadership: the accounts most likely to have broad Azure RBAC assignments. These accounts had MFA enabled. The MFA was defeated by a convincing phone call.
Legitimate cloud tools as attack infrastructure. Every action Storm-2949 took after initial access used legitimate Microsoft platform capabilities. Microsoft Graph API enumeration. OneDrive file downloads. Azure Key Vault access. SQL database queries. From the platform’s perspective, every action was authorised and expected. Endpoint detection found nothing to flag. The attacker blended into normal administrative behaviour because they were using normal administrative tools.
What This Means for NHI Governance
Storm-2949 is a cloud identity attack. Its lessons are direct and immediate for any organisation running Microsoft 365 and Azure.
From an NHI perspective, the campaign has a specific relevance that extends beyond the SSPR weakness: once Storm-2949 had compromised a privileged cloud identity, they used Microsoft Graph API to enumerate service principals and attempted to add credentials to a service principal directly. That attempt failed due to insufficient permissions. But the intent is clear: the attacker was looking for non-human identities, service principals, managed identities, application registrations, as lateral movement paths to additional access.
Service principals with Key Vault access, storage account keys, SQL connection strings, and App Service deployment credentials are exactly the class of non-human identities that represent high-value pivot points in a cloud breach. Storm-2949 knew to look for them. Most organisations do not govern them with the scrutiny they deserve.
The campaign also illustrates the help desk social engineering pattern that has now produced a series of major breaches: Scattered Spider at MGM and Caesars (2023), the Handala group at Stryker (2026), and now Storm-2949. The common thread is an over-permissive recovery flow that treats a completed MFA prompt as proof of identity rather than as proof of device access.
Recommendations
- Enforce phishing-resistant MFA for all privileged accounts. FIDO2 hardware security keys and certificate-based authentication are cryptographically bound to the specific domain and cannot be phished or socially engineered. Standard push notifications and SMS codes are insufficient for accounts with Azure RBAC assignments.
- Restrict SSPR access for high-privilege accounts. Consider disabling SSPR for IT administrators, Azure owners, and senior leadership. Those accounts should have identity verification routes that cannot be triggered by a phone call.
- Require Multi-Admin Approval for destructive Entra ID actions. Authentication method removal and device registration are high-impact identity events. They should require approval from a second administrator, not be performable by a single authenticated session.
- Monitor and alert on SSPR events for privileged accounts. Any SSPR completion, authentication method removal, or new device registration on a privileged account should generate an immediate security alert.
- Audit service principal credential assignments. Storm-2949 specifically targeted service principals as lateral movement vectors. Every service principal in your Azure tenant should have a documented owner, a defined scope, and a rotation schedule. Unknown or ungoverned service principals with Key Vault or storage access are high-risk.
- Restrict OneDrive and SharePoint bulk download from unmanaged devices. Thousands of files downloaded in a single session from a non-compliant device should trigger an automatic session block, not just an alert.
How NHI Mgmt Group Can Help
Securing Non-Human Identities (NHIs) including AI Agents, is becoming increasingly crucial as attackers discover and target service accounts, API keys, tokens, secrets, and OAuth credentials during breaches. These NHIs often hold extensive permissions that can be exploited, making their security a priority for any organisation focused on protecting their digital assets.
Take our NHI Foundation Level Training Course, the most comprehensive in the industry, that will empower you and your organisation with the knowledge needed to manage and secure these non-human identities effectively.
Final Thoughts
Storm-2949 is the textbook demonstration of why the security community has been saying for years that identity is the new perimeter. The attack did not breach a firewall. It did not exploit a vulnerability. It convinced a human to approve a prompt. From that single social engineering success, a methodical attacker moved from one reset identity to four compromised accounts, from SSPR to Graph API enumeration, from OneDrive bulk download to Azure infrastructure access, all using legitimate platform capabilities, all blending into expected administrative behaviour.
The lesson is not that MFA is useless. The lesson is that MFA must be paired with phishing-resistant authentication for privileged accounts, with monitoring for anomalous identity events, and with governance over the non-human identities that sit downstream of every compromised cloud account.
