Storm-2949 exposes the real identity governance gap in Azure

At a glance

What this is: Storm-2949 is a cloud identity abuse campaign that moved from password reset abuse into Microsoft 365, Azure Key Vault, SQL, and VM compromise without malware.

Why it matters: It matters because IAM, NHI, and privileged access teams must govern what identities can do after authentication, not just whether the login succeeded.

👉 Read Avatier's analysis of Storm-2949 and cloud identity governance failures

Context

Storm-2949 shows what breaks when identity governance assumes that a successful reset means the access path is safe. The campaign did not rely on malware; it relied on legitimate identity controls being left unreviewed after a compromised account was re-bound to an attacker-owned authenticator. For IAM and NHI teams, that makes the failure mode a governance gap, not an authentication gap.

The article also shows why standing privilege, unmanaged service principals, and unmonitored authentication-method changes belong in the same control conversation. Once an attacker can inherit privileged Azure RBAC and move laterally through Microsoft 365 and control-plane services, the problem is not just entry. It is whether lifecycle attestation, JIT elevation, and identity-event correlation are actually working.

Key questions

Q: What breaks when a privileged account is re-bound after a reset but never recertified?

A: The account becomes trusted again on paper even though the identity state has materially changed. That lets an attacker keep using the account through valid controls while the organisation assumes the reset solved the problem. The fix is not just stronger authentication. It is post-reset review of methods, role assignments, and recent activity before the identity is considered safe.

Q: Why do service principals become high-risk in cloud breaches?

A: Service principals often outlive the teams and workflows that created them, so ownership, rotation, and entitlement review drift over time. Once an attacker enumerates them, forgotten credentials and stale permissions can become durable access paths into control-plane services. Treat them as governed identities with a lifecycle, not as static configuration objects.

Q: How do organisations know whether standing privilege is still a live risk?

A: If high-risk roles such as Azure Owner, Contributor, or User Access Administrator are assigned permanently, standing privilege is still a live risk. Evidence of risk includes old role grants, no recent recertification, and no approval trace for current access. JIT elevation is only effective when those permanent assignments are actually removed.

Q: Who is accountable when a cloud identity breach spreads across multiple services?

A: Accountability sits with the teams that own identity lifecycle, privileged access, and cloud control-plane governance, not only with the sign-in system. When a single compromised identity can reach Key Vault, SQL, storage, and VMs, the failure is cross-domain. Boards and security leaders should require a named owner for each identity type and each elevated role.

Technical breakdown

How authenticator-method drift became the first durable foothold

The campaign began with a legitimate Self-Service Password Reset flow that was socially engineered into approving an attacker-triggered MFA prompt. After that approval, the actor removed the existing phone, email, and authenticator methods and re-registered Microsoft Authenticator on a device they controlled. That sequence matters because the account was not simply guessed or phished once; it was re-bound to a new trust device inside a valid identity workflow. The technical failure is that the identity audit trail showed a high-risk reconfiguration, but no governance process treated it as a containment event.

Practical implication: alert on privileged authenticator-method changes and tie them to lifecycle workflow validation, not just sign-in success.

Why service-principal hygiene is part of breach prevention

Service principals are non-human identities that often outlive the teams that created them. In the Storm-2949 chain, the actor enumerated service principals and attempted credential injection, which shows how quickly forgotten application identities become attack surface once a directory is compromised. The core issue is ownership drift: the identity still exists, the permissions still exist, but accountability no longer does. Without scheduled credential rotation, attestation, and decommissioning, service principals become durable footholds for control-plane abuse.

Practical implication: inventory every privileged service principal, assign a named owner, and recertify credentials on a fixed lifecycle schedule.

Why standing Azure Owner roles turned a breach into a sweep

The four-minute Key Vault sweep depended on standing Azure Owner access that had never been forced through a time-limited approval path. JIT RBAC, or Privileged Identity Management in Microsoft terminology, removes the assumption that historic privilege assignments remain valid forever. Once the actor had a compliant session, the permanent Owner role let them move directly from identity compromise to secret harvesting and control-plane changes. That is a classic privileged access governance failure: access was legitimate at some point, but it was never made temporary, reviewable, or task-scoped.

Practical implication: convert permanent Azure Owner and similar high-risk roles into time-bound elevation with approval and post-task expiry.

Threat narrative

Attacker objective: The objective was to turn one compromised identity into broad cloud control-plane access that could be used to steal secrets, exfiltrate data, and manipulate workloads.

1. Entry began with a socially engineered Self-Service Password Reset and fraudulent MFA approval that let the attacker re-bind a privileged account to an attacker-owned authenticator.
2. Escalation followed through directory enumeration, service-principal probing, and inherited Azure RBAC that exposed Key Vault, SQL, and storage control surfaces.
3. Impact came from legitimate management-plane actions that enabled secrets theft, SQL firewall changes, VM compromise, and Microsoft 365 data exfiltration without malware.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Storm-2949 is an identity governance failure disguised as a password-reset incident. The account was legitimately re-bound, the attack then moved through privilege and lifecycle gaps that were already present. That means the decisive control question is not whether MFA was present, but whether post-reset governance noticed the identity had changed state. Practitioners should treat reset completion as a monitoring trigger, not a closure event.

Standing privilege was the control assumption Storm-2949 exploited. Historic Azure Owner assignments were treated as if they remained valid indefinitely, even though the operational need had changed. That assumption fails when the attacker can inherit the role through a compromised session and immediately convert it into secret access. The implication is that privilege recertification must be continuous for high-risk cloud roles, not annual and retrospective.

Service-principal hygiene is now a core breach-prevention discipline, not an inventory exercise. The campaign showed how easily non-human identities become forgotten attack infrastructure once ownership and rotation lapse. OWASP-NHI and NIST CSF both point to the same gap: a credential is only as governable as the lifecycle process behind it. Practitioners should stop treating service principals as static configuration and start treating them as governed identities.

Identity blast radius is the right concept for this campaign. One compromised account expanded across Microsoft 365, Azure RBAC, Key Vault, SQL, storage, and VMs because each surface trusted the same identity path. The attack reveals that controls separated by product boundary are too narrow for cloud governance. Security teams should evaluate identity risk by the number of control planes a single identity can reach before review, not by login volume alone.

Phishing-resistant authentication is necessary here, but it is not the whole lesson. The breach chain shows that the initial prompt was only one doorway; the real damage came from what happened after identity assurance was restored on paper. That is why NHI governance, privileged access review, and cross-surface logging must be treated as one control stack. Practitioners should map this campaign to OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to 2024 ESG Report: Managing Non-Human Identities.
• For lifecycle controls and ownership discipline, see NHI Lifecycle Management Guide, which maps provisioning, rotation, and offboarding to governed identity states.

What this signals

Identity blast radius: Storm-2949 is a reminder that the real unit of risk is not the login, but the number of cloud control planes an identity can touch before review. For practitioners, that means measuring identity reach across Entra, Azure RBAC, Key Vault, SQL, and workload telemetry as one governance problem, not five separate logs.

With 72% of organisations already reporting or suspecting an NHI breach in the 2024 ESG Report: Managing Non-Human Identities, lifecycle discipline is no longer optional background work. Teams should expect more attacks that start with one identity and expand through stale permissions, especially where ownership is unclear.

The practical signal to watch is whether your privileged roles, service principals, and post-reset authenticator changes are being recertified against the same lifecycle system. If they are not, the programme is still relying on trust at the point of authentication rather than control after authentication.

For practitioners

• Monitor post-reset authenticator changes Alert on privileged account changes that remove existing phone or email methods and register a new authenticator outside an approved service-desk or lifecycle workflow. Correlate the audit event with the ticketing system before allowing the account to remain active.
• Recertify service principals on a fixed cadence Assign a named human owner to every privileged service principal, rotate credentials on a schedule, and revoke identities that no longer map to an active application. Use ownership attestation to catch forgotten non-human identities before they become attack infrastructure.
• Replace standing Azure Owner with JIT elevation Move critical Azure roles into time-bound approval flows with post-task expiry, and require anomaly checks on recently authenticated sessions before elevation is granted. Permanent Owner assignments should be treated as exceptions that need explicit business justification.
• Unify identity telemetry across control planes Feed Entra audit logs, Azure activity logs, Key Vault events, SQL firewall changes, and workload audit streams into a single identity graph. Alert when one identity touches multiple control surfaces in a short window that does not match its normal behaviour.

Key takeaways

• Storm-2949 succeeded because identity governance was missing after the reset, not because authentication failed outright.
• The breach demonstrates how standing privilege, forgotten service principals, and unreviewed authenticator changes can turn one account compromise into multi-service cloud access.
• JIT elevation, lifecycle attestation, and unified identity telemetry are the controls most likely to prevent the same pattern from recurring.

Key terms

• Standing Privilege: Standing privilege is persistent elevated access that remains assigned after the original task or project has ended. In cloud identity governance, it creates a durable attack path because an account can still reach sensitive control planes long after the business need changed.
• 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.
• Identity Blast Radius: Identity blast radius is the amount of damage one compromised identity can do across systems, data, and control planes. In practice, it is shaped by role scope, token lifetime, service ownership, and whether governance detects lateral movement before the attacker reaches sensitive assets.
• Authenticator Drift: Authenticator drift is the uncontrolled change of a user’s or administrator’s trust methods after initial enrollment or reset. It becomes a governance problem when the new method is not tied to an approved workflow, because the identity still looks valid even though the assurance state has changed.

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.

This post draws on content published by Avatier covering Storm-2949: identity governance failures after a privileged password reset. Read the original.