What went wrong in Storm-2949 was not “a magical exploit” nor a classic breach with malware. It was a chain of identity and permission abuse in Azure that ended in data exfiltration from Azure Key Vault and Azure SQL Database, relying on the use (and often abuse) of App Services as an execution plane. The practical result in an enterprise is clear: when identity control degrades, the perimeter disappears and network segmentation does not compensate.
This post focuses on the Storm-2949 case described by Microsoft (May 2026) from an operational postmortem approach: what conditions enable the jump from “identity theft” to “full compromise”, what signals are usually already in the logs, and what containment and prevention measures are realistic in organizations with multiple subscriptions, teams, and pipelines.
What went wrong: identity as a single point of failure
In the Storm-2949 attack, the decisive element was that identity (users, service principals and/or managed identities) became the main vector to operate inside Azure with a legitimate appearance. In a corporate environment, this happens when permissions are oversized, application credentials are managed as “configuration” and not as high-risk assets, and monitoring focuses on network and endpoints, leaving control-plane telemetry in the background.
The real consequence is that the attacker does not need to run binaries or “install anything”: it is enough to invoke APIs (directly or through App Services) to read secrets, enumerate resources, and extract data. In practice, this reduces detection friction because many actions resemble usual administration operations, especially if the organization has aggressive automation and “does everything” with application identities.
A typical pattern that worsens the impact is the use of shared identities for multiple environments (dev/test/prod) or for multiple applications. When that identity has access to Key Vault and at the same time can act on App Services, the chain accelerates: extracting secrets enables access to more services; and having a managed runtime makes it easier to execute calls to internal services without raising suspicion from an unknown host.
How access was chained: from App Services to Key Vault and SQL without malware
The abuse of App Services as an “execution platform” fits especially well in organizations where apps already have connectivity, assigned identities, and access to secrets. Instead of pivoting with post-exploitation techniques on machines, the attacker can use existing components to operate: App Services with managed identities, settings with references to secrets, and pre-existing permissions to read from Key Vault or authenticate to SQL.
In enterprises this dependency is frequently seen: an App Service obtains credentials or tokens (directly or indirectly) to access SQL Database and other backends. If the attacker manages to control the identity or its execution context, or manages to operate with equivalent permissions, the jump from “I can read secrets” to “I can read data” is a matter of minutes. Exfiltration does not need strange tunnels: legitimate queries and exports using channels permitted by the platform itself are enough.
To ground it in real consequences: a single read of secrets in Key Vault can reveal connection strings, certificates, signing keys, or third-party credentials. With that, the attacker not only extracts data from SQL; they can also impersonate integrations, sign tokens in poorly designed systems, or move laterally to other resources that trust those cryptographic materials.
Early signals that are usually in your tenant (and get overlooked)
In incidents like Storm-2949, the signals are rarely “an antivirus fired”. They are usually identity and administration traces: spikes in control-plane operations, Key Vault access outside normal patterns, or App Services activity that does not fit the expected behavior (for example, secret reads not associated with deployments).
A practical problem is that many teams look at logs “after the fact” and in a fragmented way: the platform team looks at App Service, the data team looks at SQL, and the security team looks at AAD. The attacker lives in the gaps. When it finally gets correlated, the damage is already done and secret rotation becomes urgent and disruptive.
- Anomalous Key Vault access: not only authentication failures; also successful reads of secrets/keys/certs from identities that normally do not do so.
In a corporate environment, this translates into reviewing Key Vault audit events to detect mass reads, after-hours access, or access from “infra” identities that should not touch application secrets. If there is no baseline, the first step is to build it per application and per identity, not for the entire subscription.
- “Small” changes in App Services: configuration modifications, assigned identity, Key Vault references, or slot changes that seem routine.
These changes are especially dangerous because they get confused with CI/CD operations. In companies with many daily deployments, an actor with a compromised identity can camouflage among normal activity. That is why it is advisable to separate deployment identities from execution identities, and alert when a pipeline identity touches sensitive settings or identity assignments.
- Unusual data activity in SQL: spikes in queries, exports, or access from applications that “are not for reporting”.
Here the enterprise nuance is that exfiltration can look like a legitimate load. Without identity-based access controls (and not only network-based) and without active auditing, it is discovered late. The useful indicator is not only “more queries”, but “queries from the wrong principal” or from an app that should not access certain schemas.
Containment without shutting down the company: real decisions and trade-offs
When a chain of identity abuse is confirmed, the instinctive response is usually “revoke everything” or “rotate all secrets”. In practice, that can take production down if systems depend on static secrets or if multiple apps share the same Key Vault. In Storm-2949, the risk is that the attacker already has enough material to re-authenticate even if some paths are cut.
Effective enterprise containment prioritizes cutting persistence and reducing blast radius with the least impact: disabling or restricting suspicious identities, blocking access paths to Key Vault from high-risk identities, and forcing selective rotation starting with secrets that open more doors (signing certificates, integration credentials, keys with broad privileges). The trade-off is accepting a window of controlled degradation (for example, temporarily disabling non-critical features) in exchange for not collapsing the service.
- Freeze changes in sensitive App Services: stop deployments and block configuration/identity modifications until triage is completed.
This is uncomfortable for product teams, but it prevents the attacker from continuing to “blend in” with operational noise. If it is not frozen, the investigation becomes unreliable because the state constantly changes and the attacker can take advantage of the normal change flow.
- Prioritized rotation of Key Vault secrets: start with those that allow data access (SQL) and those that enable impersonation (certificates/keys).
Indiscriminate mass rotation often breaks third-party integrations and legacy systems. In contrast, impact-based rotation reduces recovery time. If it is detected that an identity had read permissions, you must assume compromise of those secrets, even if the access does not seem “excessive”.
How to do it in practice: identity hardening and verifiable controls
Realistic prevention against a case like Storm-2949 is not based on “more tools”, but on concrete restrictions on identities, Key Vault, and App Services, plus continuous verification. The goal is that a compromised identity is not enough to read critical secrets and then extract SQL data, or at least that this path is noisy and blockable.
The first thing is to review effective permissions (not intentions) and separate identities by function: deployment, execution, operations. In too many companies a pipeline identity has the ability to change settings, assign identities, and also read Key Vault. That combination turns any credential leak into a systemic compromise.
- Reduce privileges of App Service identities: assign minimum permissions in Key Vault (only necessary secrets, not global “get/list”), and avoid having the same identity hold broad roles in the subscription.
Verifiable action: check in Azure RBAC and/or in Key Vault access policies (depending on the model used) that the execution identity does not have mass enumeration permissions. In mature environments, it is also validated that there are no inherited assignments at the resource group level that “give away” access to multiple vaults.
- Restrict configuration changes in App Services: limit who can modify settings, managed identity, and Key Vault references; audit and alert on changes outside authorized pipelines.
Verifiable action: review Azure Activity Logs for write-type operations on the App Service resource, and set alerts when the actor is not the pipeline identity or when the change affects sensitive configurations. In companies with multiple teams, this requires an “owners” model per app, not a shared global role.
- Limit SQL access by identity: avoid reusable static credentials and ensure that access from applications is segmented by database/schema.
Verifiable action: confirm that the principals used by the app in SQL do not have global read permissions nor unjustified export capabilities. Where possible, require that access paths correspond to specific execution identities, so that an anomalous read is attributable and blockable.
Recommendations for corporate environments
Storm-2949 shows an uncomfortable reality in Azure: when an identity (human or application) has broad permissions and can operate with App Services, the attacker can move and exfiltrate data without deploying malware. In that context, “network-based” security or reliance on endpoint signals is not enough, because the abuse occurs in the control plane and in legitimate access to managed services.
The actionable lessons concentrate on three fronts: reduce effective privileges in Key Vault and in execution identities, control and audit App Services changes as if they were security changes, and treat SQL access as a high-risk flow that must be segmented by identity. If today your organization cannot quickly answer “which identities can read which secrets” and “which applications can query which data”, the path from identity theft to full compromise is already paved.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.