Microsoft's Defender Security Research Team recently published a detailed incident report on Storm-2949, a threat group that exfiltrated data across Microsoft 365, Azure Key Vault, App Services, storage accounts, SQL databases, and virtual machines. It's a thorough account of how far an attacker can move once they're inside. But the more important detail is how they got in: Self-Service Password Reset (SSPR).
Storm-2949 initiated the SSPR flow on behalf of a target, then called them on the phone, impersonated IT support, and convinced them to approve the MFA prompt. Once they had that approval, they reset the password, stripped out every existing authentication method, and enrolled their own device.
"We assess with high confidence that Storm-2949 leveraged a social engineering technique consistent with known abuses of Microsoft's Self-Service Password Reset (SSPR) process." — Microsoft Defender Security Research Team
What the report documents isn't a misconfiguration or an unpatched vulnerability. The SSPR flow worked exactly as designed: the reset request was real, the MFA prompt was real, and it was genuinely approved. The attacker’s insight was the same we’ve been highlighting for a long time: MFA verifies access, not people. That’s the gap which attackers continue to exploit.
Why Account Recovery Is Structurally Exposed
Account recovery has a property that authentication doesn't: it's specifically invoked when a user has lost their normal means of proving who they are. That's the moment an attacker targets, because it's the moment the organization's controls are most likely to downgrade security levels.
Standard SSPR validation methods — push notifications, SMS passcodes, and email links — all verify that someone has access to something: a registered device, a phone number, or an inbox. Storm-2949 didn't need to compromise any of those things. They simply needed to convince a person to interact with a legitimate prompt, using social engineering.
This is a downgrade attack in action. And the identity gap exposed here isn't specific to any one authentication method. It's present anywhere that account recovery flows depend on a user responding to a prompt rather than on confirming who they actually are.
What Closes This Gap
The only account recovery approach that isn't vulnerable to this attack class is one that verifies the person behind the request through means that can't be replicated over a phone call.
Nametag's self-service account recovery module requires the user to verify their identity against a live selfie and their government-issued ID document in a way that can’t be phished, fooled or faked. There's no prompt for a caller to convince someone to approve. The verification either confirms the person or it doesn't, and that decision isn't accessible to social engineering.
Nametag has offered this capability for Microsoft Entra and other directories for more than two years. The Storm-2949 report is a clear account of what the attack looks like in practice, and it's useful exactly because it makes the exposure concrete enough to act on.
If your SSPR flow relies on users responding to prompts, this report describes your exposure. See how Nametag closes this gap with our self-service account recovery module.
