The Reset Gap: How Storm-2949 Weaponized Native Entra ID Features

On 18 May 2026, Microsoft’s Threat Intelligence team reported the results of an investigation into a threat actor they have labeled Storm-2949. Similar to the recent Handala attack against US healthcare vendor Stryker, this attack did not hinge on some novel zero-day. Instead, it leveraged legitimate Azure tools.

Microsoft reports that initial access was achieved through Entra ID Self-Service Password Reset (SSPR) and social engineering to reset the user’s credentials. These attacks lean on techniques such as MFA fatigue to push credentials sourced from leaks like ALIEN TXTBASE over the line, getting the user to accept an MFA prompt that looks routine. Once MFA is bypassed, the attacker can reset the password, disable the legitimate user’s authentication methods, and register their own device to achieve persistence. From there it is a clean run to lateral movement across cloud-connected services.

How Storm-2949 established a foothold

According to Microsoft Storm-2949 ran the SSPR exploit against high-value accounts, targeting IT personnel and senior leadership that were most likely to hold privileged Azure role-based access control (RBAC) assignments. After gaining initial access, the attacker used the Microsoft Graph API to map the tenant. A custom Python script enumerated users, applications, and service principals, looking for privileged identities and additional footholds. An attempt to add credentials to a service principal failed on insufficient permissions, but the reconnaissance continued and three more cloud accounts were compromised through the same reset technique.

The attacker then pivoted to identifying opportunities for lateral movement from a cloud identity into the endpoint network. Storm-2949 OneDrive and SharePoint searched for IT documentation covering VPN configurations and remote access procedures, with thousands of files pulled in a single action through the OneDrive web interface. The pattern repeated for every compromised identity, likely because different users had access to different folders and shared directories.

From identity to full cloud compromise

With privileged RBAC roles in hand, Storm-2949 turned to Azure itself. After failing to reach a primary production web application directly, the attacker compromised several auxiliary App Service instances by retrieving their publishing profiles, which contained deployment credentials for FTP, Web Deploy, and Kudu.

The real breakthrough came at Azure Key Vault. The compromised user held the Owner role over a vault containing production credentials. In four minutes, the attacker reconfigured access, pulled dozens of secrets including database connection strings and identity credentials, and used them to authenticate to the production web application they had originally been targeting.

Azure Storage and SQL followed, with Storm-2949 rewriting firewall rules to permit access from attacker-controlled IP addresses. The threat actor also enumerated Shared Access Signature tokens and account keys, and ran a custom Python script using the Azure SDK to pull large volumes of data from storage accounts over multiple days. The modified SQL firewall rules were deleted afterwards to slow forensic reconstruction.

In parallel, Storm-2949 abused the VMAccess extension to create local administrator accounts on Azure Virtual Machines, then ran PowerShell through the Run Command feature to install ConnectWise ScreenConnect from infrastructure they controlled. Before installation, the script attempted to disable Microsoft Defender Antivirus real-time protection and behavior monitoring, renamed the ScreenConnect service to resemble a legitimate Windows component, and cleared event logs and command history to complicate any later investigation.

No ransom was issued, no extortion attempt made, and at the time of writing, no known group has claimed the intrusion. The primary goals of many recent campaigns were Data theft, credential harvesting, and resale on criminal markets, all of which make threat actor activity within an organization harder to detect. When there is no encryption event to alert on and no payload signature to flag, malicious actions blend into the noise of routine cloud administration.

Who is behind Storm-2949?

At present, it seems that this threat actor could be a relative newcomer. Microsoft uses the Storm-#### designation for activity clusters or groups that have not yet been definitively linked to a known nation-state, financially motivated outfit, or other tracked actor. Once Microsoft has enough telemetry and corroboration, Storm clusters typically graduate to a permanent name in one of the weather-themed taxonomies, such as Tempest for financially motivated actors or Typhoon for state-aligned ones.

What has been confirmed about Storm-2949 is limited to the behavior observed in this campaign. The threat actor appears to prioritize identities over endpoints and uses social engineering as the primary intrusion vector. The custom Python tooling used for both directory discovery and storage exfiltration suggests a capable operator rather than a script-driven affiliate, and the comfort shown with Microsoft Graph, Azure Resource Manager APIs, and VM extension abuse points to an actor who has spent real time in Entra ID and Azure environments. Microsoft has published indicators of compromise covering three attacker IP addresses, including one hosting the ScreenConnect instance used in the intrusion.

The absence of extortion, the data-only objective, and the focus on production credentials and IT documentation are consistent with several active criminal and access-broker clusters, but Microsoft has not made an attribution call and neither will we.

What defenders can do to strengthen against this attack pattern

The success of this campaign was not due to failures in Microsoft Defender or missing security controls. It succeeded because SSPR in Entra ID treats a completed MFA prompt as proof of identity. Once that proof is harvested through social engineering, every downstream protection inherits a false premise.

As Microsoft states in its report, Storm-2949 was able to “move laterally across cloud and endpoint environments while blending into expected administrative behavior.” That is the part defenders need to internalize, as the activity following the reset was indistinguishable from legitimate administration.

The good news is that the chain has several breakable links well before an attacker reaches Key Vault. The following five controls address the specific weaknesses Storm-2949 exploited.

1. Harden the password reset workflow itself

SSPR is the door this attack walks through, so the verification standard at that door matters more than any control downstream. Move away from a reset process that can be completed with a single push notification approval. Specops uReset supports more than 20 third-party authentication options and MFA-fatigue-resistant factors such as FIDO2 security keys or time-based one-time password codes, so a successful reset depends on more than one piece of evidence an attacker can talk a user into providing.

2. Add phishing-resistant identity verification

The Storm-2949 operators succeeded because the user on the other end of the call could not distinguish them from internal IT. Government-issued ID checks and biometric liveness detection take that ambiguity out of the workflow. Specops Verified ID adds both at the point of reset, validating against the user’s directory record before any password change is permitted and removing the knowledge-based answers attackers can easily guess.

3. Block leaked credentials before they become a foothold

Targeted social engineering becomes far easier when the attacker already has a working password from a public breach corpus. Continuously scanning Active Directory against known-compromised credentials closes that precursor. Specops Password Policy, when the Breached Password Protection feature is enabled, checks against more than six billion compromised passwords in real time, blocking their use at password set or change.

4. Enforce least privilege and Zero Trust at the access point

Storm-2949’s reach into Key Vault, Azure Storage, and SQL was a function of the RBAC roles held by compromised user accounts. As such, even legitimate sign-ins should be evaluated against device posture and access context, not waved through on a valid MFA prompt alone. Specops Device Trust ties identities to specific devices, preventing them from using stolen credentials or session cookies from an unauthorized device.

5. Audit your own exposure

Knowing where weak, reused, or already-breached passwords sit in Active Directory is a useful starting point for any of the above. The free Specops Password Auditor gives a read-only report on compromised and vulnerable accounts in an existing AD environment,delivering a quick way to gauge how exposed an organization is to the exact initial-access pattern Storm-2949 used.

The Storm-2949 campaign is a reminder of where the security perimeter sits in cloud-first environments. Password resets, MFA prompts, and even a voice on the other end of a call are all moments sophisticated attackers can exploit. Strengthening identity verification at those moments is what keeps a single social engineering call from turning into a full cloud compromise.

Interested in seeing how Specops could work in your environment? Contact us today, or book a demo to see our solutions in action.