How the Storm‑2949 Attack Turned a Password Reset Into a Microsoft 365 and Azure Breach

How the Storm‑2949 attack started

Microsoft Threat Intelligence describes Storm‑2949 as a “methodical, sophisticated, and multi‑layered” campaign focused on stealing sensitive data from high‑value cloud assets.

Instead of deploying malware, the attackers primarily compromised identities and abused legitimate cloud features. Once they gained access to a user account—often a privileged one—they leveraged normal administrative workflows inside Microsoft 365 and Azure to expand their reach across the victim organization’s cloud environment.

This strategy allowed the attackers to blend in with legitimate activity and avoid traditional security controls designed to detect malicious software.

The role of Self‑Service Password Reset (SSPR)

A key step in the attack chain involved abusing Microsoft Entra’s Self‑Service Password Reset (SSPR) system, which normally allows users to reset their own passwords without contacting IT support.

Storm‑2949 exploited this workflow through social engineering:

• Attackers impersonated internal IT support or security personnel and contacted targeted employees.
• Victims were instructed to approve what appeared to be routine verification prompts.
• These prompts were actually MFA approvals triggered during a password‑reset attempt.

Once the victim approved the prompt, the attacker could proceed with the password reset process.

After gaining control of the account, the attacker could:

• Reset the user’s password.
• Remove existing authentication methods tied to the legitimate user.
• Register their own authentication device (such as a Microsoft Authenticator instance).

This step effectively locked the real user out while giving the attacker persistent MFA‑backed access.

How attackers expanded into a cloud‑wide breach

After controlling the identity, Storm‑2949 moved laterally across the organization’s cloud resources.

Because the compromised accounts often belonged to high‑privilege users such as IT staff or senior leadership, attackers could access a wide range of Microsoft services.

Targets included:

• Microsoft 365 data such as SharePoint and OneDrive files
• Azure‑hosted production environments
• Cloud storage accounts and databases
• Sensitive secrets stored in services like Azure Key Vault

The campaign demonstrates a key security reality in cloud environments: identity is the control plane. When a privileged identity is compromised, attackers can potentially access many interconnected services without needing to exploit software vulnerabilities.

Why Microsoft is phasing out SMS authentication

At the same time that incidents like Storm‑2949 highlight identity risks, Microsoft has announced that it will phase out SMS codes for authentication and account recovery on personal Microsoft accounts.

The company argues that SMS‑based authentication has become a major source of fraud and is vulnerable to multiple attack techniques.

Common weaknesses include:

• SIM‑swap attacks that transfer a victim’s phone number to a malicious SIM card
• Interception of text messages across telecom infrastructure
• Social engineering that tricks users into revealing verification codes

Because SMS codes are phishable and transferable, attackers can capture them remotely. Microsoft therefore considers them weaker than modern passwordless authentication systems.

Instead, Microsoft is pushing users toward passkeys, authenticator apps, and verified secondary email, which rely on device‑bound cryptographic credentials or secure authentication workflows.

Security measures Microsoft recommends for organizations

The Storm‑2949 campaign highlights how identity attacks can bypass traditional defenses. Microsoft recommends several key security controls to reduce this risk.

1. Use phishing‑resistant MFA

Organizations should prioritize authentication methods that cannot be easily phished or approved through social engineering. These include passkeys or hardware‑based authentication aligned with phishing‑resistant standards.

2. Enforce least‑privilege access

Role‑based access control (RBAC) should ensure that users only have the permissions necessary for their job. This limits the damage if a single account is compromised.

3. Treat password‑reset workflows as high‑risk

Recovery mechanisms such as SSPR can become attack paths if abused. Organizations should monitor and secure these processes carefully, especially for privileged users.

4. Monitor identity and cloud control‑plane activity

Logging and monitoring should cover:

• Identity and authentication events
• Password‑reset activity
• Microsoft 365 data access
• Azure management operations

This visibility helps security teams detect suspicious administrative behavior early in an attack.

The broader lesson: identity is the new attack surface

Storm‑2949 illustrates a major shift in modern cyberattacks. Rather than exploiting software vulnerabilities or deploying malware, attackers increasingly target identity systems and recovery workflows.

A single compromised identity—especially one with elevated privileges—can become the entry point to an organization’s entire cloud ecosystem. Strengthening authentication, reducing privilege levels, and monitoring identity activity are therefore critical defenses for cloud‑first environments.