Storm-2949 Turns Password Reset Into Cloud Breach

Microsoft published a May 18, 2026 report describing how Storm-2949 used self-service password reset abuse as the opening move in a larger cloud intrusion. The report is useful because it does not stop at the compromised user. It follows the chain into MFA registration, Azure resources, Key Vault secrets, a production web app, SQL, storage accounts, virtual machines, and data exfiltration.

The practical lesson is that password reset is not a convenience feature sitting outside the threat model. In cloud identity, reset can be a privileged path into the same control plane that governs applications, secrets, storage, and sessions. Security teams should review SSPR policy as carefully as they review login policy.

Many identity incidents are described as credential theft and then handled as a password problem. Microsoft's Storm-2949 report is more useful because it traces what happened after identity access was obtained. The actor used reset and authentication-method abuse to gain a foothold, then expanded into cloud infrastructure where application secrets and resource permissions created the larger breach.

That shape matters for Protocol Report readers because collaboration systems, developer platforms, chat communities, crypto teams, and SaaS-heavy organizations often centralize trust in one identity provider. If reset policy lets an attacker become a legitimate user, every downstream system that trusts that identity provider has to be reviewed.

Microsoft's SSPR documentation frames self-service password reset as a way for users to regain access without administrator or help-desk involvement. That is valuable. It reduces lockouts and support pressure. It also means the reset path makes decisions that used to belong to a human operator: whether an account holder has proven enough control to change a credential.

The documented Microsoft Entra flow checks whether SSPR is enabled, whether the user has the required authentication methods, whether one or two methods are required, and whether administrator reset policy differences apply. Those settings should be treated as production security policy, not onboarding plumbing. A reset event can become the moment an attacker gets a fresh password, registers a device, changes MFA defaults, and starts collecting tokens.

The Storm-2949 report describes expansion across Azure resources after the identity compromise. Microsoft says the actor accessed a main production web app, changed its password to retain control, and exfiltrated sensitive data. The same chain reached Azure Storage accounts and an Azure SQL server. The actor manipulated SQL firewall rules and storage network access configurations to enable access and then removed some changes afterward, which Microsoft characterizes as defense evasion.

That is the central cloud lesson: after reset abuse, the important question is not only whether the user's mailbox was opened. It is whether that identity had access to resource groups, service principals, Key Vault secrets, storage keys, publish profiles, SQL firewall changes, VM commands, backup data, SaaS apps, or partner tenants. The blast radius follows permissions.

Microsoft's detection list includes attacker device registration as an MFA method, suspicious addition of a default third-party MFA method, suspicious Entra device join or registration, and malicious device registration with strong MFA. Those events are not normal account hygiene. They are equivalent to adding a new lock that the attacker controls.

Security teams should alert on MFA method creation, method deletion, default method change, phone-number changes, device registration, Temporary Access Pass issuance, and resets for privileged or high-impact users. The same review should include support and admin actions. If a help-desk process can add or replace a recovery method without enough verification, the organization has built a manual version of the same attack path.

The Microsoft report says the actor found credentials that enabled access to the targeted production web app, and it discusses suspicious Key Vault policy changes and secret queries among the detections. Key Vault is supposed to centralize sensitive material so applications do not scatter secrets through code and configuration. That is a strong pattern, but it concentrates evidence and privilege when an attacker reaches it.

Key Vault, storage accounts, SQL, and VMs need independent containment controls. Private endpoints, least-privilege RBAC, separate vaults by environment and application, restricted storage network rules, logging, and alerts for unusual secret queries are not optional extras. They are the controls that limit damage when identity fails.

A normal reset response can be too small. If Storm-2949-style activity is suspected, responders need a timeline that starts before the reset and continues through method registration, sign-ins, resource-manager operations, Key Vault access, storage reads, SQL firewall changes, VM command execution, and mass downloads. The password is only one artifact.

The first containment move is to revoke sessions, remove unfamiliar authentication methods and devices, reset credentials from a trusted admin path, and disable or quarantine suspicious accounts. The next move is cloud scoping: check resource changes, secret reads, storage access, SQL access, app credential changes, service-principal activity, and data movement. Only after that should the team close the incident as account recovery abuse.

Disabling self-service recovery for everyone is rarely practical. People lose devices, forget passwords, change phones, and need support. The better answer is tiering. Ordinary users may use a well-monitored SSPR flow with two methods and risk-based checks. Administrators, finance approvers, production engineers, community owners, and identity operators need stronger reset paths, stronger authentication strengths, shorter sessions, and immediate notification to security staff.

Microsoft's risk-based policy guidance is useful here because it treats user and sign-in risk as conditions that can trigger MFA, password change, risk remediation, session revocation, or block decisions. Recovery should be adaptive too. A reset from a new geography, a new device registration followed by storage reads, or a privileged user's method change should create friction and investigation, not a quiet successful login.