Storm-2949 Azure Attack 2026: How a Fake IT Support Reset Turned One Entra ID Account into a Cloud-Wide Data Theft

On 18 May 2026, Microsoft Threat Intelligence published an account of Storm-2949, a threat actor that turned a handful of compromised Microsoft Entra ID accounts into a breach spanning Microsoft 365 and Azure at one unnamed organisation. Microsoft assessed with high confidence that the entry point was abuse of Self-Service Password Reset (SSPR): the actor starts a reset for a targeted user and, typically posing as IT support, persuades them to approve the multi-factor authentication prompts. The attacker then registered its own Authenticator and used privileged Azure roles held by the compromised accounts to reach Key Vault secrets, App Service publishing credentials, SQL, storage account keys and virtual machines. The entry point was a human identity, but the damage came from the secrets and keys those accounts could reach.

At a glance

What happened

Microsoft says Storm-2949 had "a singular focus: to exfiltrate as much sensitive data from a target organization's high-value assets as possible." It "didn't rely on traditional malware", using legitimate cloud and Azure management features instead.

The first step was the password reset. Microsoft says it assessed "with high confidence" that Storm-2949 used a social engineering technique "consistent with known abuses" of SSPR. In that pattern, the actor starts the reset process for a target and then, as Microsoft puts it, "might impersonate an internal information technology (IT) support representative and contact the user claiming that their account requires urgent verification," telling them to approve the MFA prompts. Microsoft does not say which channel was used to contact the victims. After approval, the attacker reset the password, removed the user's existing phone, email and Authenticator methods and enrolled Authenticator on its own device, locking the real user out. Targets included IT personnel and senior leadership.

With a foothold, the attacker ran a custom Python script against Microsoft Graph to enumerate users and applications. It tried to add credentials to a compromised service principal for persistence, but Microsoft says that "failed due to insufficient permissions." Using the same SSPR technique, it then compromised three additional cloud user accounts.

In Microsoft 365, the attacker went after OneDrive and SharePoint, focusing on IT documents about VPN configuration and remote access. Microsoft says Storm-2949 "used the OneDrive web interface to download thousands of files in a single action to their own infrastructure."

The move into Azure came through role assignments. Microsoft says the compromised identities held privileged custom Azure role-based access control (RBAC) roles. The attacker first targeted a production Azure App Service web application. Blocked there, it called microsoft.Web/sites/publishxml/action on auxiliary web apps to retrieve their publishing profiles, which often contain basic authentication credentials for FTP, Web Deploy and Kudu. It compromised several auxiliary apps but not the primary one.

So it turned to Key Vault. One compromised user held the Owner role over a Key Vault that appeared to hold credentials for the production application. Microsoft says: "Over the span of four minutes, the threat actor successfully manipulated Key Vault access configurations and accessed dozens of secrets." Those secrets included "database connection strings, identity credentials, and more". Using them, the attacker authenticated to the production web app, changed its password to keep control and began taking data from it.

The attacker also used its RBAC permissions to write SQL server firewall rules so it could connect with the stolen credentials, changed storage account network access settings and called listkeys to obtain storage account keys and Shared Access Signature (SAS) tokens. A custom Python script built on the Azure Storage SDK then downloaded large volumes of data. Microsoft says this storage exfiltration "continued over multiple days since the initial access".

On virtual machines, the attacker used the VMAccess extension to create a new local administrator account, and used Run Command to run a script that requested a token for the VM's managed identity from the Instance Metadata Service and tried to read the production Key Vault with it. Microsoft says the attacker "wasn't able to retrieve the secrets because the managed identity lacked the required permissions." A PowerShell script then tried to disable Defender Antivirus protections, installed ScreenConnect from attacker infrastructure disguised as trusted software updates, and cleared event logs and command history. Through ScreenConnect the attacker ran discovery on multiple devices, including searches for .pfx certificate files.

Timeline

How it happened: the identity attack path

1. A reset the victim did not start. The attacker triggered SSPR for a chosen user, then posed as IT support so that the MFA prompts looked routine.
2. Replacing the victim's factors. The attacker removed the user's phone, email and Authenticator methods and enrolled its own Authenticator. Access no longer depended on the victim, and the victim could no longer sign in.
3. Mapping the directory from the inside. A Graph script listed users and applications and looked for privileged roles and led to three more accounts.
4. From user roles to deployment credentials. Privileged custom RBAC roles let the attacker read App Service publishing profiles.
5. Owner of the vault, so owner of the secrets. Holding the Owner role over a Key Vault, the attacker changed its access configuration and read dozens of secrets in four minutes.
6. Keys that bypass identity entirely. Listing storage account keys and SAS tokens gave credentials that work without Entra ID sign-in, which the attacker used to pull data for days.
7. Workload identities as the next target. On a VM, the attacker requested a managed identity token from IMDS to read Key Vault. It failed only because the identity lacked access.

Impact

• Data: thousands of OneDrive files downloaded in one action, with a focus on VPN and remote access documents; sensitive data taken from the production web app; large volumes downloaded from several storage accounts over multiple days (Microsoft). Microsoft gave no volumes or record counts.
• Secrets: dozens of Key Vault secrets exposed, including database connection strings and identity credentials, plus storage account keys, SAS tokens and web app publishing credentials.
• Endpoints: ScreenConnect installed on multiple devices, with Defender targeted and logs cleared.
• Motive: BleepingComputer reported that Microsoft did not observe extortion activity. The victim's identity and any disclosure by it are not public.

What this means for identity security

Storm-2949 is a human identity breach at the front door. There was no exploit: the attacker used a legitimate recovery feature and a convincing story. When a password reset accepts a single push approval as proof of identity, the person approving it becomes the control, and the attacker only has to persuade them. Specops Software put it plainly: "SSPR in Entra ID treats a completed MFA prompt as proof of identity." Enrolling a new Authenticator straight after the reset then turned a one-off approval into durable access, much as help desk social engineering did in the MGM Resorts breach.

What made one reset into a cloud-wide breach was what the reset accounts could reach. Microsoft's account reads like a list of non-human credentials: deployment credentials in publishing profiles, connection strings and identity credentials in Key Vault, storage account keys and SAS tokens, a service principal and a VM managed identity. Storage keys in particular authenticate outside Entra ID, so resetting the stolen user passwords does nothing to revoke them. A human user holding the Owner role on a production Key Vault is a standing path from a phone conversation to every secret in that vault.

The two blocked steps are worth noting. The service principal credential addition and the managed identity read both failed for lack of permissions. Least privilege worked on the non-human side but was missing on the human side, where custom roles gave people broad control over vaults, storage and SQL network settings. Our Cloud PAM and CIEM Guide covers finding and cutting that kind of standing cloud privilege.

Recommendations

• Harden self-service password reset. Do not let a reset complete on a single push approval, especially for administrators and executives. Microsoft recommends phishing-resistant MFA strength for administrators and making sure privileged users already have a registered MFA method, which stops attackers registering the first one. The Active Directory and Entra ID Hardening Guide covers these settings.
• Alert on method changes after a reset. Removal of existing authentication methods followed by a new Authenticator registration on the same account is a strong signal, worth an immediate review.
• Take standing Owner rights off Key Vaults and storage. Audit Azure RBAC assignments regularly, use time-bound elevation for access changes to vaults, and monitor the activity log for publishxml, listkeys and firewall rule writes, as Microsoft advises.
• Remove shared keys and basic auth where possible. Microsoft recommends disabling legacy authentication on App Services and using managed identities, enforcing Entra ID authentication for SQL and using private endpoints for storage and Key Vault. Our Secrets Management Guide explains how to shorten and remove long-lived secrets.
• Scope workload identities tightly. Give managed identities and service principals only the access they need, and restrict who can use Run Command and VMAccess.
• Rotate every machine credential after a user compromise. If a compromised account could read a vault or list keys, treat all those secrets, keys and SAS tokens as exposed.
• Enable Key Vault logging and purge protection, and keep logs for up to a year.

Frequently asked questions

What is Storm-2949?

Storm-2949 is the name Microsoft Threat Intelligence gives to a threat actor it disclosed on 18 May 2026. Microsoft says it compromised Entra ID accounts through SSPR abuse, then used legitimate Microsoft 365 and Azure features to steal data from one organisation.

How did Storm-2949 get into Azure?

The attacker started password resets for targeted users and, posing as IT support, persuaded them to approve the MFA prompts. It then enrolled its own Authenticator. The accounts' privileged Azure roles then opened Key Vault, storage, SQL and VMs.

Were Azure Key Vault secrets stolen in the Storm-2949 attack?

Yes. Microsoft says one compromised user held the Owner role over a Key Vault, and the attacker changed its access configuration and read dozens of secrets within four minutes, including database connection strings and identity credentials. A separate attempt to read Key Vault through a VM's managed identity failed.

Related NHI Mgmt Group resources

Secrets Exposure Via Azure Key Vault Role · MGM Resorts breach 2023 · Microsoft Midnight Blizzard breach · Stryker Microsoft Intune wiper attack · Cloud Workload Identity Guide

How NHI Mgmt Group can help

Storm-2949 started with a person, but it was the Key Vault secrets, storage keys and deployment credentials behind that person's roles that turned one reset into a cloud-wide data theft. Our NHI Foundation Level Training Course shows teams how to inventory, scope and rotate these non-human identities so a single compromised account cannot reach them all.

References

• Microsoft Threat Intelligence: How Storm-2949 turned a compromised identity into a cloud-wide breach (18 May 2026)
• BleepingComputer: Microsoft Self-Service Password Reset abused in Azure data theft attacks (19 May 2026)
• The Cyber Express: Microsoft Exposes Storm-2949 Azure And M365 Breach (19 May 2026)
• Cyber Security News: Hackers Abuse Microsoft Entra ID Accounts to Exfiltrate Microsoft 365 and Azure Data (19 May 2026)
• SC Media: Storm-2949 actor targets Microsoft 365 and Azure environments (20 May 2026)
• Specops Software: The Reset Gap: How Storm-2949 Weaponized Native Entra ID Features (22 May 2026, updated 22 September 2026)