Microsoft says Storm-2949 turned Self-Service Password Reset into an account-takeover path, then used the stolen identities to reach Microsoft 365 and Azure data. The attack did not begin with traditional malware. It began with a trusted identity workflow that users are trained to follow.
Microsoft assesses that the actor initiated a password reset, posed as internal IT support, and convinced targeted users to approve MFA prompts that appeared routine. After approval, the attacker reset the password, removed existing authentication methods, and registered a new MFA method under attacker control [1].
Why the SSPR path works
SSPR abuse is dangerous because it wraps account takeover inside a familiar support process. A user may believe they are helping IT verify an account, while the attacker is completing the reset flow. Once the attacker controls the password and MFA method, normal identity protections can begin working for the wrong person.
The weak point is not just user awareness. It is the combination of SSPR eligibility, MFA enrollment rules, helpdesk trust, and privileged cloud roles. If a targeted identity has access to Microsoft 365 files, Azure resources, Key Vault, App Services, or SQL data, one successful social-engineering flow can become a cloud-wide breach.
What Microsoft observed after takeover
After the identity compromise, Microsoft says Storm-2949 used Microsoft Graph API discovery to enumerate users and applications. The actor accessed Microsoft 365 data, searched OneDrive and SharePoint for operational files, and moved into Azure resources where privileged roles opened access to production assets.
Microsoft’s report also describes Azure activity involving App Services, Key Vault access, Storage accounts, SQL resources, and attempts to use legitimate management-plane operations. That makes the incident hard to detect if teams only look for malware. The activity can resemble administration until the sequence is correlated.
What defenders should check
- Password reset events followed by MFA method changes.
- New authenticator enrollment immediately after SSPR activity.
- Graph API enumeration from unusual locations or scripts.
- Large OneDrive or SharePoint downloads after identity changes.
- Azure RBAC activity against Key Vault, App Services, Storage, SQL, and VM resources.
- ScreenConnect or other remote-access tooling introduced after cloud compromise.
For admins, the response should start with SSPR scope and privileged roles. Limit password reset eligibility for sensitive accounts, require phishing-resistant MFA for privileged users, and audit Azure RBAC permissions that can expose Key Vault, Storage, App Services, or SQL data. Gridinsoft’s earlier coverage of device-code phishing shows the same pattern from another angle: attackers prefer abusing trusted login steps when those steps give them durable access.
References
- Microsoft Security, “How Storm-2949 turned a compromised identity into a cloud-wide breach,” May 18, 2026. Report
