Hacker in a hoodie using a laptop surrounded by cybersecurity and cloud icons, illustrating a cyberattack scene

How Threat Actors Are Abusing Microsoft Entra ID Self-Service Password Reset (SSPR) to Compromise Cloud Environments

Posted by:

|

On:

|

Threat actors are increasingly leveraging Microsoft Entra ID’s Self-Service Password Reset (SSPR) feature to conduct highly targeted, identity-driven attacks. Advanced threat groups, such as Storm-2949, have demonstrated how legitimate account recovery functionality can be manipulated to gain access to high-value executive and IT accounts. Once access is obtained, attackers move beyond traditional account compromise, targeting Microsoft 365 and Azure environments to conduct large-scale data theft and cloud infrastructure abuse.

Understanding the Threat

Microsoft’s SSPR feature is designed to reduce IT overhead by allowing users to securely recover access to their accounts. While this functionality provides significant operational benefits, security researchers have observed threat actors weaponizing the feature as part of sophisticated intrusion campaigns.

Attackers often begin by conducting reconnaissance against targeted accounts. By initiating SSPR workflows through anonymizing services such as Tor, they can identify which verification methods are configured for a user. This information helps them determine the most effective path to compromise.

Threat actors typically gain control of targeted identities through one of two methods:

  • Performing SIM swap attacks to intercept SMS or voice-based one-time passcodes (OTPs).
  • Conducting social engineering campaigns in which they impersonate IT support personnel and convince users to approve fraudulent multi-factor authentication (MFA) prompts.

Once access is obtained, attackers reset passwords, replace legitimate MFA configurations with devices under their control, and begin conducting extensive directory reconnaissance. In recent campaigns, compromised identities were used not only to steal data from Microsoft 365 services such as OneDrive and SharePoint but also to access Azure production environments. By relying on legitimate administrative functionality rather than malware, attackers are often able to blend their activity with normal administrative operations, making detection significantly more difficult.

Attack Progression

These identity-centric cloud intrusions typically follow a deliberate progression from SaaS access to full cloud infrastructure compromise.

Initial Access and Reconnaissance

Threat actors begin by initiating SSPR workflows to determine which authentication methods are available for a target account. When SMS or voice verification is enabled, attackers may attempt SIM swapping to effectively weaken MFA protections. In campaigns attributed to Storm-2949, attackers combined SSPR activity with highly convincing phishing phone calls, persuading senior leaders and IT personnel to approve MFA requests without suspicion.

Identity Persistence

Immediately after gaining access, attackers establish persistence by removing the victim’s existing MFA devices and enrolling their own authentication methods, often through Microsoft Authenticator. This tactic allows attackers to maintain access even if the organization performs a routine password reset.

Microsoft 365 Data Collection

Following account compromise, threat actors use automated tools, including custom Python scripts that interact with the Microsoft Graph API, to rapidly enumerate users, groups, and applications within the environment.

Attackers frequently target OneDrive and SharePoint repositories to download large volumes of corporate data. Particular interest is often placed on network diagrams, VPN configurations, remote access documentation, and other information that may facilitate additional lateral movement opportunities.

Azure Infrastructure Hijacking

When compromised accounts possess Azure Role-Based Access Control (RBAC) privileges, attackers may pivot from Microsoft 365 services into Azure production environments.

In observed campaigns, threat actors invoked legitimate Azure management actions such as microsoft.Web/sites/publishxml/action to retrieve application publishing profiles. They also modified firewall configurations and network access rules for Azure SQL databases and Storage accounts, enabling direct database extraction and the theft of Shared Access Signature (SAS) tokens.

Because these actions utilize legitimate administrative functionality, they can be difficult to distinguish from normal operational activity.

Indicators of Compromise

Organizations should monitor for the following indicators that may suggest SSPR-related compromise activity.

SSPR and Authentication Red Flags

  • Incomplete or abandoned SSPR requests originating from Tor exit nodes, VPN services, or unusual geographic locations.
  • Successful SSPR activity completed through SMS, voice, or MFA push notifications from rare or unexpected IP addresses.
  • Sudden removal of existing MFA devices followed by the immediate registration of new Microsoft Authenticator profiles.

Post-Compromise Microsoft Graph API and Azure Activity

  • Rapid, automated bursts of Microsoft Graph API enumeration activity targeting users, groups, or enterprise applications.
  • Large-scale downloads from OneDrive or SharePoint repositories, particularly involving IT, network, or credential-related documentation.
  • High-risk Azure management operations, such as retrieving publishing XML profiles, modifying SQL firewall rules, or rotating Azure Storage keys shortly after anomalous authentication events.

Mitigation Recommendations

Harden SSPR Configurations

Organizations should evaluate whether SSPR is required for all users. If operationally feasible, consider disabling SSPR globally or restricting it for highly targeted groups such as executives and administrators.

If SSPR must remain enabled:

  • Require at least two verification methods for password resets.
  • Disable mobile and office phone verification methods where possible to reduce SIM swapping risk.

Monitor Identity Changes

Implement automated alerts for:

  • Successful SSPR events.
  • Authentication method modifications.
  • MFA device removals or additions.
  • Session revocations and re-registration activity.

Enforce Least Privilege

Regularly review Azure RBAC assignments and remove unnecessary permissions. Avoid broad or legacy custom roles that provide excessive management-plane access to production environments.

Secure Critical Cloud Resources

Restrict public access to Azure Key Vaults, Azure SQL databases, and Storage accounts. Implement strict network access controls and retain critical audit logs for up to one year to support threat hunting and incident response activities.

Revoke Active Sessions During Incident Response

When responding to a suspected compromise, organizations should revoke all active sessions across connected cloud services rather than relying solely on password resets. This helps ensure attackers cannot maintain access through previously established authentication tokens.

Final Thoughts

As organizations continue to adopt cloud-first architectures, identity has become one of the most valuable attack surfaces available to threat actors. Campaigns leveraging Microsoft Entra ID SSPR demonstrate how legitimate account recovery mechanisms can be transformed into powerful intrusion vectors when combined with social engineering and identity-focused attack techniques.

Defending against these threats requires a combination of strong identity controls, proactive monitoring, least-privilege access models, and rapid incident response procedures capable of addressing both account compromise and cloud infrastructure abuse.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.