TL;DR: Storm-2949 used Entra ID SSPR and social engineering to take over privileged Microsoft accounts without malware or a zero-day, and MFA did not stop the reset flow, according to Bravura Security. The breach shows that user-held credential reset authority is itself the attack surface, because approval confirms interaction, not understanding.
At a glance
What this is: This is an analysis of how Storm-2949 abused Entra ID SSPR and social engineering to convert credential reset governance into account takeover.
Why it matters: It matters because IAM teams need to see credential reset as a governance path, not just a recovery feature, especially for privileged and high-blast-radius accounts.
Context
Credential reset governance is the decision model that determines who can trigger recovery, who approves it, and whether that path can be socially engineered. In Entra ID SSPR environments, the user often sits in that decision seat, which means the reset flow itself becomes part of the attack surface for privileged identity estates.
Storm-2949 showed that MFA can be present throughout a reset attack and still fail to stop compromise, because approval only proves that a prompt was accepted, not that the person understood the request. For identity programmes, that distinction matters across human accounts, help desk processes, and any lifecycle workflow that still depends on user action to restore access.
Key questions
Q: What breaks when credential reset authority sits with the user?
A: The reset path becomes reachable through social engineering, because the attacker only needs to influence one human decision at the right moment. Once that happens, the recovery mechanism and the compromise mechanism are effectively the same workflow. For privileged accounts, that means account recovery can turn into tenant-level exposure before defenders can coordinate a response.
Q: Why do MFA controls not stop socially engineered password resets?
A: MFA validates that a registered factor approved a prompt, but it does not validate caller legitimacy or the user’s understanding of the request. If the attacker can time the interaction to the reset flow, the prompt itself becomes the trap. Phishing-resistant MFA helps, but it does not remove the underlying recovery governance flaw.
Q: How should teams handle privileged account recovery after a reset attack?
A: They should treat privileged recovery as a separate governance path from normal self-service. The process should support coordinated containment, not individual user-by-user remediation, because attackers exploit the delay between compromise and recovery. The goal is to shorten the attacker’s window without depending on the same user action that was already abused.
Q: What is the difference between self-service password reset and enterprise-managed recovery?
A: Self-service password reset places the user in the recovery loop, which makes the path socially engineerable. Enterprise-managed recovery keeps issuance and restoration under policy control, so the organisation can reset and reissue credentials without relying on a compromised person to act. The difference is who controls the last security decision.
Technical breakdown
How a privileged reset flow expands blast radius
When IT staff or executives can be reset through a user-managed process, the attacker is not just gaining one mailbox or workstation account. They are entering a privilege tier that often reaches Azure roles, admin tooling, data stores, and downstream SaaS controls. Once the reset succeeds, the attacker can strip other authentication methods, enroll a new device, and move laterally through cloud management interfaces and shared documentation. The architecture turns one successful social engineering interaction into enterprise-wide exposure. Practical implication: any reset path that reaches privileged identities needs separate governance from ordinary user recovery.
Practical implication: segment privileged credential recovery from standard user self-service so that one social engineering event cannot escalate to tenant-wide access.
Threat narrative
Attacker objective: The attacker aimed to convert reset authority into privileged Microsoft account takeover and then expand that foothold into broader cloud access and data exposure.
- Entry occurred through social engineering of the target during the SSPR process, with the attacker posing as internal support while the reset workflow was active.
- Credential access followed when the victim approved the reset and the attacker took over the password reset flow, then stripped existing authentication methods and enrolled a new device.
- Escalation continued as the attacker used the newly reset privileged account to enumerate roles, applications, users, and service principals through Microsoft Graph API.
- Impact included OneDrive and SharePoint access, exfiltration of operational documentation, and lateral movement across the tenant while recovery was still manual.
Breaches seen in the wild
- Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential reset authority is the real attack surface: When an organisation places password recovery in the user’s hands, it creates a path that social engineering can reach even when authentication is otherwise strong. The problem is not whether SSPR works as designed. The problem is that the design makes user approval the decisive security event. Practitioner implication: identity teams need to evaluate reset authority as a control plane, not a convenience feature.
Approval is not understanding: MFA can confirm that a prompt was accepted, but it cannot prove the person understood who initiated the request or why. That is why attacks like Storm-2949 remain viable even in MFA-enabled environments. The reset flow still trusts a human judgement moment that adversaries can manufacture. Practitioner implication: controls that only prove interaction leave the governance gap untouched.
User-held recovery breaks privilege containment: A reset process that reaches IT staff or executives does not stay at the account boundary. It expands into cloud roles, admin tooling, and adjacent systems that were never meant to depend on a socially engineered approval. That is a blast-radius problem, not an authentication problem. Practitioner implication: separate privileged identity recovery from ordinary user recovery and treat them as different governance domains.
Enterprise-owned credential lifecycle beats user-owned recovery: The durable fix is not a safer version of the same recovery model. It is a model where the enterprise owns credential issuance, rotation, and recovery so that the user is not the final gate on access restoration. This is where the governance assumption collapses: credential reset authority was designed for user-paced recovery, and that assumption fails when the reset path itself is reachable by an attacker. Practitioner implication: redesign lifecycle ownership before tuning the recovery flow.
From our research library:
- Password-related issues can represent 10–50% of service desk calls, many of which are avoidable.
What this signals
Reset governance needs to be treated like privilege governance: Identity teams should stop treating recovery as a back-office support function and start evaluating it as an access control decision. Where users can approve their own restoration path, the organisation has already accepted a social engineering exposure window.
Privileged accounts need a different recovery model: The same reset design that is tolerable for low-risk users becomes materially more dangerous when the account can reach admin roles, cloud control planes, or sensitive collaboration data. Recovery for those identities should be governed as a blast-radius reduction problem, not a convenience problem.
For practitioners
- Separate privileged recovery from standard SSPR Create a distinct recovery process for admins, executives, and support staff that does not rely on the same user-driven approval path used for ordinary accounts.
- Require phishing-resistant MFA for high-risk identities Use FIDO2 security keys or passkeys for privileged accounts so a phone-based social engineering call cannot approve the reset prompt in the moment.
- Establish coordinated mass reset capability Make sure incident responders can scope and execute a tenant-wide or population-wide password reset without waiting for each user to re-enter the recovery flow.
- Remove the user from the reset decision seat Shift credential ownership to enterprise policy for the identities that matter most, so recovery is governed by lifecycle control rather than individual judgment.
Key takeaways
- Storm-2949 shows that the main weakness was not a broken product control but a recovery model that let social engineering reach credential reset authority.
- The attack succeeded against MFA-enabled accounts and then expanded into Microsoft Graph, OneDrive, and SharePoint access, showing how a reset can become a broad compromise.
- The practical response is to remove ordinary users from privileged reset decisions and move recovery toward enterprise-controlled credential lifecycle governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The attack exploited a reset flow that trusted user approval as authentication evidence. |
| NHI-10 — Human Use of NHI | User-held recovery authority let a human interaction become the compromise vector for non-human credential control. | |
| Recommendation — Review reset flows under NHI-04 and remove any step that can be socially engineered into account takeover. Apply NHI-10 to move credential recovery decisions away from user-mediated approval paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential reset, replacement, and lifecycle control map directly to authenticator management. |
| Recommendation — Use IA-5 to govern reset, replacement, and revocation of privileged authenticators under policy control. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about who can authorise restoration of access and how that authority is controlled. |
| Recommendation — Apply PR.AA-05 to limit who can authorise privileged account recovery and credential reissue. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The chain progressed from credential capture through movement across cloud resources and roles. |
| Recommendation — Map the reset-abuse path to TA0006 and TA0008 to prioritise detection and containment around recovery abuse. | ||
Key terms
- Credential Reset Authority: Credential reset authority is the power to approve or trigger a new authentication path for an account. In governance terms, it is a privileged decision point because whoever controls the reset flow can often control account recovery, especially when the user is asked to validate their own restoration.
- Self-service password reset: A recovery workflow that lets users regain access without relying on a help desk agent to perform the reset. In identity governance terms, it replaces discretionary manual verification with a standardized, auditable process that can be tuned to the risk of the account or application being recovered.
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
- Enterprise-Managed Credentials: Enterprise-managed credentials are passwords or secrets that are generated, rotated, and delivered under central organisational control. The user may retrieve them for access, but does not decide when they change or how they are maintained. This model reduces reliance on memorisation, manual reset steps, and inconsistent recovery workflows.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 20, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org