Storm-2949 exposed the reset gap in Azure identity governance

At a glance

What this is: This analysis shows how Storm-2949 used a legitimate reset flow and approved MFA prompt to move from initial compromise into Azure control-plane abuse, proving that authentication success alone did not contain the incident.

Why it matters: It matters because IAM teams that stop at reset controls miss the governance layer that should detect post-reset authenticator drift, standing privilege, and NHI credential abuse across cloud workloads.

By the numbers:

• The campaign progressed through Microsoft 365 data theft, Azure Key Vault access, SQL exfiltration, and VM compromise without using malware.

Context

Storm-2949 is a cloud identity compromise in which an attacker used a successful reset and MFA approval to keep moving through Microsoft 365 and Azure. In IAM terms, the problem is not only whether the user was authenticated, but whether privileged changes after authentication were governed and monitored.

The article’s central claim is that reset workflows can complete legitimately while the identity estate drifts into unsafe state. That makes this an identity governance problem as much as an authentication problem, especially where privileged users, service principals, and cloud control-plane access share the same tenant.

Avatier’s framing is useful because it separates the door from the room behind it: a reset may open access, but governance determines whether the attacker can stay, escalate, and harvest secrets. That distinction is typical of mature cloud identity failures, not an edge case.

Key questions

Q: What fails when a privileged account is reset but its access is not re-governed?

A: The account can remain operationally dangerous even after the password changes, because the attacker may still control authenticator methods, session context, or elevated roles. In Storm-2949, the reset did not remove the attacker’s ability to move into Key Vault and other Azure surfaces. The failure is post-reset governance, not password change alone.

Q: Why do standing Azure roles make cloud identity compromises worse?

A: Standing roles turn a compromise into immediate control because the attacker does not need to request elevation or wait for approval. A permanently assigned Owner role lets a stolen identity read secrets, alter policies, and expand access quickly. That is why time-bound privilege is a governance requirement, not a convenience.

Q: How do teams tell whether authenticator changes are being governed properly?

A: They should be able to correlate every privileged authenticator change with an approved workflow, an ownership record, and a legitimate business reason. If method replacement, device enrollment, or recovery-factor changes appear without that trail, governance is missing the exact moment when compromise often becomes persistent access.

Q: What should IAM teams do when service principals are part of the same attack surface as users?

A: They should govern service principals as first-class identities with ownership, expiry, recertification, and credential rotation. When these non-human identities drift unmanaged, a human compromise can pivot into application-level access that bypasses normal workforce controls and survives well beyond the initial incident.

Technical breakdown

Why a successful reset did not stop the breach

Self-Service Password Reset only answers one question: did the user complete the prescribed proofing path. It does not, by itself, prove that the account should retain the same privileges, the same recovery methods, or the same session trust after the reset. In Storm-2949, the attacker used the reset flow plus a fraudulent MFA approval to obtain a legitimate-looking authentication state, then changed the account’s authentication methods. The technical issue is state transition without governance enforcement. Authentication succeeded, but the account moved into a new, attacker-controlled binding between user, device, and credential. The control failure was the absence of a post-reset governance check on the changed identity state.

Practical implication: treat reset completion as a trigger for governance review, not as a closed security event.

How standing Azure Owner privilege enabled the Key Vault sweep

Azure Owner is a control-plane role with broad authority over resources and access policy changes. When that role remains permanently assigned, an attacker who inherits the identity also inherits the ability to read and reshape the environment without needing a second approval path. Storm-2949 used that standing privilege to reach Key Vault and harvest secrets in minutes. This is not a malware problem and not a token-expiry problem. It is a privilege permanence problem. Once the role is standing, the compromise path shortens dramatically because the attacker does not need to escalate inside the cloud platform. The governance gap is the assumption that yesterday’s elevated role is still justified today.

Practical implication: convert persistent Owner assignments into time-bound elevation with explicit recertification.

Why service principals widen the post-reset attack surface

Service principals are non-human identities that often outlive the teams and applications that created them. They are easy to forget, hard to attest, and dangerous when their credentials or permissions drift. In the Storm-2949 chain, the attacker probed a service principal for credential injection, which shows that the campaign was not limited to the human user’s account. The deeper lesson is that a privileged human reset can be only the first foothold in a broader identity graph that includes service principals, managed identities, and delegated permissions. If those identities are unmanaged, the attacker can pivot from a human compromise into machine-access paths that operate outside normal user lifecycle controls.

Practical implication: inventory and attest non-human identities alongside human admin accounts, especially where privilege and rotation are unclear.

Threat narrative

Attacker objective: The objective was to turn one compromised identity into durable cloud control, secret access, and broad data theft across Microsoft and Azure services.

1. Entry occurred through social engineering during a Self-Service Password Reset flow, where the attacker induced the target to approve a fraudulent MFA prompt.
2. Credential access followed when the attacker reset the password and re-registered authentication methods on the compromised account, preserving legitimate-looking access.
3. Escalation and impact followed through standing Azure Owner privilege, which allowed the attacker to sweep Key Vault, exfiltrate SQL data, and compromise VMs without malware.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

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

Reset success is not a security finish line: Storm-2949 shows that authentication can complete correctly while the identity estate becomes less trustworthy after the fact. The governance failure is not the reset itself but the absence of controls that re-evaluate privilege, authenticator state, and ownership immediately after the reset event. Practitioners should treat post-reset state change as the real control boundary.

Standing privilege created the breach’s usable window: The campaign worked because a privileged Azure Owner assignment remained valid long after the business need that created it. That assumption was designed for stable administrative roles, not for identities that can be repurposed in minutes after compromise. The implication is that cloud privilege governance must be time-bounded, continuously attested, and separated from successful authentication.

Post-reset identity drift: The most important failure mode here is not credential theft alone but the unmanaged drift that follows a legitimate-looking reset. Authenticator re-registration, service-principal probing, and persistent RBAC together show that the attacker did not need malware to create operational damage. The implication is that governance must follow state change, not just access grant.

Credential governance now spans humans and NHIs: This campaign crossed from a compromised human identity into service principals and cloud control-plane permissions. That is the clearest sign that identity governance can no longer stop at workforce accounts. Practitioners need one operating model for privilege review, offboarding, and attestation across users, service accounts, and cloud roles.

Microsoft’s own control-plane warning is the right signal to watch: The company’s observation that attackers increasingly target identity and control-plane access is more than incident commentary. It confirms that the attack surface is now the management layer itself. Security programmes should prioritise detection of abnormal control-plane transitions, not just endpoint compromise.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Post-reset identity drift: Storm-2949 shows why the security boundary has moved from successful authentication to the state changes that follow it. When authenticator methods, role assignments, and service-principal permissions can change without lifecycle scrutiny, the attacker does not need malware to create durable access.

Governance must watch the control plane, not just the login event: The practical signal for practitioners is not whether the user got in once, but whether that identity starts touching surfaces it never normally uses. A short burst of Graph enumeration, Key Vault reads, and SQL policy changes from one account is a stronger warning than any isolated login alert.

For practitioners

• Harden post-reset review workflows Trigger a governance review whenever a privileged user completes SSPR, especially if authenticator methods, recovery factors, or enrolled devices change in the same session.
• Eliminate standing Azure Owner assignments Move critical Azure Owner access into JIT elevation with recertification, because a permanently assigned role gives an attacker immediate control if the account is taken over.
• Attest service principals as governed identities Require named ownership, scheduled credential rotation, and permission recertification for service principals and managed identities before they become forgotten pivot points.
• Correlate identity state changes with workflow tickets Alert when authenticator registration, password reset, and privileged role activity occur without a matching service-desk or lifecycle record.
• Monitor cloud control-plane sequence anomalies Look for a single identity moving from Entra sign-in to Graph enumeration, Key Vault reads, SQL firewall edits, and VM changes in one short window.

Key takeaways

• Storm-2949 shows that a legitimate reset can still become a full cloud compromise when privileged identity changes are not re-governed.
• The campaign moved from a single account into Microsoft 365, Key Vault, SQL, and VMs, which is the scale that makes governance failure visible.
• Time-bound privilege, authenticator-change review, and non-human identity attestation are the controls most directly aligned to the failure mode.

Key terms

• Post-reset identity drift: The change in account state that happens after a password reset or recovery event when authenticators, devices, and privileges are not revalidated. In privileged environments, this drift can matter more than the reset itself because attackers use the new state to keep access looking legitimate.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Service Principal Hygiene: Service principal hygiene is the lifecycle discipline for non-human application identities, including ownership, credential rotation, entitlement review, and retirement. It matters because forgotten service principals often retain permissions long after the team that created them has disappeared.
• Control-Plane Access: Control-plane access is the ability to change cloud infrastructure, configuration, or policy through management APIs. It is more sensitive than ordinary data access because it can create, alter, or delete the environment itself. In NHI incidents, control-plane access is often the point where valid credentials become material impact.

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.