Storm-2949 exposed the reset gap in Azure identity governance

At a glance

What this is: Storm-2949 is a post-reset identity abuse campaign that turned one compromised user into broad cloud compromise across Microsoft 365 and Azure.

Why it matters: It matters because IAM, IGA, and PAM programmes must detect what an identity does after authentication, not just whether the login succeeded.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Avatier's analysis of Storm-2949 and the Azure reset gap

Context

Storm-2949 shows what happens when identity governance stops at authentication. The campaign began with a legitimate password reset and MFA approval, then moved into authenticator re-registration, service-principal probing, and standing Azure Owner abuse. The primary keyword here is Storm-2949, but the deeper issue is the reset gap between a successful login and what the identity is allowed to do next.

In practical terms, this is an IGA and PAM failure as much as an access-control failure. Existing IAM models can confirm who authenticated, yet still miss whether a privileged account changed methods, whether a service principal was about to be abused, or whether a standing role should have expired long ago.

The article argues that the attacker did not need malware because the control plane itself was the path. That is typical of modern cloud identity abuse: once governance does not watch post-authentication change, the breach can move from human deception to cross-service impact in minutes.

Key questions

Q: What failure mode does Storm-2949 show in identity governance?

A: It shows that authentication can succeed while governance fails immediately afterward. The breach moved from a legitimate reset into authenticator replacement, service-principal probing, and standing privilege abuse. That means teams cannot rely on sign-in controls alone. They need alerting on post-authentication identity change, especially for privileged users and non-human identities.

Q: Why do standing privileged roles increase cloud breach impact?

A: Standing roles keep elevated access available long after the original business need has passed. In Storm-2949, a permanent Azure Owner assignment allowed a rapid Key Vault sweep once the attacker had access. Time-bound elevation changes the problem from durable exposure to narrow, reviewable access. That is why JIT and recertification matter together.

Q: How do service principals complicate cloud identity governance?

A: Service principals often lack clear ownership, are not reviewed as often as human accounts, and can retain permissions after the application or team changes. Storm-2949 shows why that matters: the attacker could enumerate and probe them as part of the wider cloud compromise. Governance needs ownership, rotation, and retirement discipline.

Q: Who is accountable when a reset-based takeover leads to cloud exfiltration?

A: Accountability spans the help desk, IAM, IGA, and cloud platform owners. The reset may be the trigger, but the breach becomes material when privileged methods, roles, and non-human identities remain unchecked. Frameworks such as OWASP NHI and NIST CSF both support this view. Teams need a shared control owner for post-reset review.

Technical breakdown

How Storm-2949 used legitimate authentication to open the first door

The initial access pattern was social engineering layered over Self-Service Password Reset. The user approved an MFA prompt, the password reset completed, and the attacker immediately replaced the existing authentication methods with a new Microsoft Authenticator on a device they controlled. That matters because the security event was not a failed login attempt but a valid identity transition. In identity terms, the account remained compliant from the platform’s point of view even as its trust ownership changed. The gap is that authentication success does not tell you whether the account still belongs to the right person.

Practical implication: monitor authenticator-method changes as a governance event, not just successful sign-ins.

Why service-principal hygiene became the second attack surface

Service principals are non-human identities that often outlive the teams that created them. In this campaign, the actor enumerated service principals and attempted credential injection because the environment had no strong continuous ownership or attestation signal on those identities. NHI governance failures here are usually about drift, not disclosure alone: credentials remain valid, permissions stay broad, and nobody is accountable for retirement. The result is an identity that keeps working after the business reason for its existence has disappeared.

Practical implication: bind every service principal to an owner, review its permissions on a schedule, and decommission it when the application retires.

Standing Azure Owner roles turned a breach into a four-minute secrets sweep

Standing privilege means elevated access persists by default until someone manually removes it. Storm-2949 exploited a permanently assigned Owner role on a critical Key Vault, which allowed the attacker to harvest secrets quickly once inside Azure. This is where PAM and JIT controls matter: if the role had been time-bound, the attacker would have needed to trigger elevation from an unusual session, creating both friction and a detection point. The key technical lesson is that broad cloud roles become breach accelerators when they never expire.

Practical implication: move high-risk Azure roles to just-in-time elevation and recertify them against task need, not historical assignment.

Threat narrative

Attacker objective: The attacker’s objective was to convert one trusted identity into broad cloud control and extract secrets, data, and administrative reach across Microsoft 365 and Azure.

1. Entry occurred through a socially engineered Self-Service Password Reset flow where the attacker induced an MFA approval and then re-registered authenticator methods on the target account.
2. Escalation followed when the compromised identity enumerated Graph data, service principals, Azure RBAC, Key Vault, SQL, Storage, and VM management-plane permissions using legitimate administrative primitives.
3. Impact came from rapid secret harvesting, database exposure, firewall rewrites, and VM compromise, all without malware and all executed through authenticated cloud control-plane actions.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Microsoft Azure OpenAI service breach — stolen Azure API keys used to bypass AI safety controls at scale.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The reset gap is not the real control failure because governance failed after authentication succeeded. The breach was not only about a password reset or a fraudulent MFA approval. It worked because no control attested the authenticator changes, the service-principal probe, or the standing Azure Owner role after the initial reset. The practitioner implication is that identity governance must treat post-authentication change as the real boundary.

Standing privilege is the specific failure mode Storm-2949 exposed. A permanently assigned Azure Owner role was designed for a world where elevated access remains visible long enough to be reviewed. That assumption fails when attackers can move from reset to secret sweep in minutes, because the role survives past the moment it should have been retired or time-boxed. The implication is that historic role assignment is not evidence of current need.

Service-principal hygiene is a governance discipline, not a housekeeping task. Storm-2949 showed that a forgotten non-human identity can sit inside the tenant with enough reach to support credential injection attempts and lateral cloud discovery. This is a classic OWASP-NHI and NIST CSF governance problem, not just a cloud configuration issue. The practitioner implication is that every service principal needs ownership, recertification, and retirement logic.

Authenticator-registration drift is the named concept this breach makes visible. The user’s trusted methods were removed and replaced after the reset, which means the identity changed shape while still appearing legitimate to the platform. That drift is dangerous because it looks like account maintenance, yet it can be the first durable sign of account takeover. The practitioner implication is that method changes must be governed as lifecycle events, not only as login events.

This incident validates the case for identity-graph governance across human, NHI, and control-plane activity. The attacker touched Entra ID, Graph, Key Vault, SQL, Storage, and VMs in one chain, so isolated log review at each surface missed the pattern. Cross-surface correlation is where the breach becomes visible, which is why access review, PAM, and NHI governance must share a single operational view. The practitioner implication is that identity telemetry has to be stitched into one graph.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• See also: 52 NHI Breaches Analysis for breach patterns that turn credential exposure into operational compromise.

What this signals

Identity programmes need a post-authentication control layer, not just stronger login gates. Storm-2949 makes clear that the breach boundary now sits after the reset, where method changes, role persistence, and service-principal drift can be exploited without malware. Teams that only harden sign-in will still miss the operational moment when identity changes shape. The useful metric is whether your telemetry can tell a legitimate reset from a takeover in near real time.

Standing privilege is becoming the easiest way for attackers to turn one identity event into a cloud-wide incident. The programme implication is straightforward: directory roles, Key Vault access, and application credentials cannot be managed as static entitlements. If your recertification cycle is slower than attacker movement, your governance is already behind. Move toward JIT elevation, ownership attestation, and cross-surface identity correlation.

Service-principal sprawl and method drift are now the same governance problem. One is the machine identity side, the other is the human identity side, but Storm-2949 ties them together in a single attack path. That is why the most useful concept here is identity graph visibility: a view that connects account changes, NHI inventory, and control-plane activity across the Ultimate Guide to NHIs and the broader identity stack.

For practitioners

• Treat authenticator changes as high-risk lifecycle events Alert on phone, email, and authenticator method removal or replacement for privileged users, and require workflow correlation before the change is accepted as legitimate.
• Move Azure Owner and similar roles to JIT elevation Remove standing assignment from Key Vault, subscription, and directory admin roles, then recertify each role against a current task requirement rather than historic need.
• Assign ownership to every service principal Require a named human owner, scheduled permission recertification, and retirement checks for every service principal so forgotten identities do not become dormant attack paths.
• Correlate identity events across the full cloud control plane Join Entra audit logs, Azure activity logs, Key Vault events, and SQL administrative actions so a single identity moving across surfaces becomes one reviewable narrative.
• Use out-of-band verification for reset requests Verify service-desk requests through a separate channel before approving password resets, authenticator re-registration, or recovery method changes on privileged accounts.

Key takeaways

• Storm-2949 shows that the real failure was not the reset itself but the absence of governance after the account changed hands.
• The breach’s scale mattered because one compromised identity reached Microsoft 365, Key Vault, SQL, and VM management without malware.
• Time-bound privilege, post-reset alerting, and service-principal ownership are the controls that would have reduced the blast radius.

Key terms

• Authenticator-registration drift: A change in authentication methods that occurs after a legitimate sign-in but before the account is reviewed. In practice, it means the identity still looks valid while its trust anchor has quietly changed, which is especially dangerous for privileged users and cloud administrators.
• Standing privilege: Persistent elevated access that remains assigned until someone removes it. In cloud and identity governance programmes, standing privilege is a breach multiplier because it lets attackers use legitimate roles long after the original business need has expired.
• Service principal: A non-human identity used by applications, automation, or cloud services to authenticate and receive permissions. Service principals need the same governance discipline as human accounts because stale ownership, broad roles, and unrotated credentials can create durable attack paths.
• Identity graph visibility: A unified view that connects identity events across human accounts, non-human identities, and cloud control-plane actions. It allows teams to see patterns such as reset, method change, role use, and secret access as one sequence rather than separate log entries.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Avatier covering Storm-2949: Microsoft identity compromise and Azure control-plane abuse. Read the original.