On May 18, 2026, Microsoft Threat Intelligence disclosed an active campaign by an actor they track as Storm-2949. The attack drops no malware. It does not chain a CVE. It does not need any access to your endpoint fleet. It compromises a privileged Microsoft 365 identity using nothing more than features that ship turned on by default.
If you run an M365 tenant, this one is worth your time.
The 60-Second Version
Storm-2949 picks a target inside your organization (IT staff or senior leadership), starts a Self-Service Password Reset (SSPR) request as if they were that person, then calls the real user pretending to be internal IT. They walk the user through "verifying" their MFA. Once the MFA prompts get approved, the attacker resets the password, deletes the user's authentication methods (phone, Authenticator, email), enrolls their own device, and locks the legitimate user out.
From that moment, Storm-2949 has full M365 and Azure access as a real, audit-clean user account. No EDR alert. No firewall log. No ransomware note. Just legitimate administrative actions on legitimate sessions.
The attack uses native, supported Microsoft features end-to-end. There is no malicious code for your AV or EDR to catch. Detection has to happen at the identity layer, before the password reset completes.
What Makes Storm-2949 Different
Most ransomware playbooks still start with a malicious attachment, a phish link, or an exposed service. Storm-2949 inverts that. The actor never touches the endpoint. They never write a file. They use SSPR, which exists for the legitimate purpose of letting employees recover their own accounts.
That means most of the security investment in your environment, the EDR, the email gateway, the firewall rules, the SIEM correlation rules, has nothing to act on. The activity looks like a normal employee resetting their password.
Microsoft was direct about the shift: "Threat actors are increasingly targeting identity and control plane access rather than individual devices. When cloud identities are compromised, legitimate administrative features can be used to achieve outcomes similar to traditional lateral movement, often with fewer indicators of compromise."
The Playbook, Step by Step
Here is exactly how Storm-2949 runs:
- Reconnaissance. The attacker identifies a privileged target. IT staff and senior leaders are first picks, because their accounts unlock the most lateral movement.
- SSPR initiation. The attacker visits the public Microsoft password-reset page and starts a reset for the target's account. Microsoft begins sending MFA prompts to the legitimate user.
- The vishing call. While the prompts are arriving, the attacker phones the user, claiming to be internal IT support. They tell the user there is a routine account verification underway and ask them to approve the prompts.
- The user approves. Most people approve MFA prompts when someone they believe is IT asks them to. The reset completes.
- Method takeover. The attacker resets the password, then removes the user's existing MFA methods (phone number, recovery email, Microsoft Authenticator).
- Persistence. The attacker enrolls their own Authenticator device on the account. The legitimate user is locked out. The attacker has clean, audit-friendly access.
- Cloud-wide movement. From the compromised identity, the attacker pivots into Microsoft 365 and Azure resources the account has rights to. Email, SharePoint, OneDrive, Teams, admin centers, Azure subscriptions, all on the table.
Why Detection Tools Will Not Catch It
This is the part that should make every CISO uncomfortable. The technologies most organizations spent the last decade buying are not the right defenses for this attack:
- EDR sees endpoint behavior. There is no endpoint behavior here.
- Email gateway sees inbound mail. The first contact is a phone call.
- Firewall and IDS see network traffic. The traffic is legitimate Microsoft authentication.
- SIEM correlation usually fires on anomalous logins from impossible locations. Storm-2949 logs in from a normal-looking residential or VPS IP after the password reset, with valid credentials and a valid MFA token.
- Identity providers log the password reset as a normal user action. The audit trail says the user did this to themselves.
The only place to stop this is the identity layer, before the reset completes. And the controls live inside Entra ID, not in a separate product you bolt on.
Who Is at Risk
Any organization that meets all three conditions:
- You run Microsoft 365 or Entra ID (formerly Azure AD).
- SSPR is enabled. This is the default for most tenants because it reduces help-desk load.
- SSPR does not require multiple independent factors to reset, or your Conditional Access policies do not restrict the reset flow to managed devices.
If your tenant looks like that, your privileged users are exposed today. The attacker does not need any prior access to your environment. They need a phone number for one IT-adjacent employee.
What to Fix Now
Microsoft published direct guidance. The highest-leverage controls in priority order:
- Require number-matching MFA tenant-wide. This makes "tap to approve" prompts unusable for a social-engineer who is not also reading the user's screen.
- Require multiple authentication methods to reset a password via SSPR. The default is one. Force two.
- Block SSPR for highly privileged roles. Global Admins, Privileged Role Admins, Exchange Admins, and similar roles should be reset by a help-desk human after identity verification, not via self-service.
- Conditional Access on the reset endpoint. Require a compliant or hybrid-joined device for any password reset attempt.
- Authentication-method registration policy. Restrict who can add or remove their own auth methods, and require a strong primary auth before changes.
- Privileged Identity Management. Stop standing admin rights. Use just-in-time elevation with approval. Even if a user account is taken over, the attacker inherits a non-privileged user.
- Alert on authentication-method changes. Anyone removing all their MFA methods then adding a new one is either a Storm-2949 victim or about to be one. Send that to your SOC in real time.
- Train your IT staff and leadership on the specific scam. Generic phishing training does not cover "internal IT calls to walk you through MFA prompts." Name the threat, show the call script, run a drill.
SSPR is not the enemy. It exists for good reasons. The enemy is SSPR configured with a single method, no Conditional Access, no method-change alerts, and no carve-out for privileged roles. The fix is configuration, not removal.
What Cyvatar Sees From the Outside
Our free external scan (Am I Exposed?) cannot read your tenant's SSPR configuration. Nobody outside your tenant can. What it can confirm:
- Whether your domain is an M365 tenant (the precondition for the attack).
- Whether your tenant shows external MFA enforcement signals or looks like MFA is optional.
- Whether Microsoft Teams external federation is discoverable, which is the most common vishing entry point (and the same TTP family Storm-1811 used before this).
- Whether your email security posture is the default EOP configuration, which is what an attacker would test against before placing the call.
If your external scan shows all three signals, you are running with the exact surface area Storm-2949 looks for. The actual SSPR-config check needs authenticated read access to your tenant, which is what a Cyvatar engagement provides.
The Bigger Pattern
Storm-2949 is the second high-profile Microsoft-disclosed attack in two years that bypasses traditional defenses by abusing identity features directly. The first was Storm-1811 (our writeup), which used Teams external chat and Quick Assist to drop Black Basta ransomware. Different payload, same shape: legitimate Microsoft features, social engineering, no malware on the wire.
The lesson is not that Microsoft features are dangerous. It is that the attacker class has moved upstream of the endpoint. If your security program is still organized around "stop the malware at the endpoint or stop the phish in the inbox," you are defending the wrong layer for the threats that are landing in 2026.
What works is treating identity as the new perimeter. Tenant-wide MFA. Conditional Access on every privileged action. PIM for admin rights. Method-change alerts. And a human IT process for password resets on privileged accounts.
Find Out If You Have the Storm-2949 Surface Area
Cyvatar's free Am I Exposed? scan checks the external signals an attacker would use to decide whether to try this on your organization. Takes about 30 seconds.
Run a Free Scan → Talk to Agentic vCISOSources
- How Storm-2949 turned a compromised identity into a cloud-wide breach (Microsoft Security Blog, May 18, 2026)
- Inside Storm-2949's Cloud Takeover Campaign (Hive Pro)
- The Reset Gap: How Storm-2949 Weaponized Native Entra ID Features (Specops)
- Storm-2949 actor targets Microsoft 365 and Azure environments (SC Media)