Critical Microsoft Vulnerability Exposes User Data and MFA Status

Key Takeaways

• A critical vulnerability in Microsoft’s Entra ID Self-Service Password Reset (SSPR) portal allows unauthenticated users to enumerate valid accounts and determine their MFA status.
• Attackers can leverage variations in server responses to identify existing accounts, determine SSPR eligibility, and discover registered password reset methods (e.g., SMS, authenticator app).
• This exposure significantly aids in refining sophisticated phishing, password-spraying, and social engineering attacks, especially against privileged accounts.
• While Microsoft has implemented some protective measures like throttling, organizations are advised to review SSPR settings, enforce strong authentication, and monitor for suspicious activity.

Microsoft SSPR Portal Vulnerability Exposes Sensitive User Data

A significant security flaw within Microsoft’s Entra ID Self-Service Password Reset (SSPR) portal could be exposing sensitive account information to unauthorized individuals. This vulnerability allows attackers to ascertain the existence of Entra ID accounts and identify their configured password-reset methods, even without authentication.

Such information provides a critical advantage to malicious actors, enabling them to tailor highly effective phishing, password-spraying, and social engineering campaigns against corporate networks and their users.

How the Vulnerability Works

The Microsoft Entra ID SSPR feature is designed to allow users to regain access to forgotten passwords through a public web portal. Users typically enter their email address and then select a registered verification method to reset their credentials.

However, research conducted by Matthew Coady revealed a problematic aspect of the portal’s design. The server’s responses vary distinctly based on the account details provided. This variability can be exploited to confirm whether an account exists, if it’s eligible for SSPR, and which specific verification options are available for accounts that are eligible.

The portal’s underlying ASP.NET form workflow provides the key to this reconnaissance. Upon submission of a username, the server’s reply includes a field named “CurrentViewName.” For accounts that do not exist, the portal remains on the initial identifier screen. In contrast, valid accounts will either progress to a password-reset method selection or trigger a policy-related error message.

Crucially, even policy-related error messages can signal that an account has been recognized by the system before any restrictive policies take effect. For instance, if a user is part of a group not enabled for SSPR, the system’s response will differ from that for a completely nonexistent user, thereby confirming the account’s validity.

Enabling User Enumeration and Targeted Attacks

This differential behavior creates a significant user-enumeration issue. Attackers, often equipped with lists of email addresses obtained from public sources, prior data breaches, or previous phishing operations, can leverage this flaw to identify valid corporate accounts before launching more direct credential attacks.

For accounts that are eligible for SSPR, the portal can also reveal the specific verification methods registered, such as Microsoft Authenticator codes, SMS, voice calls, or security questions. The type of verification method directly impacts an account’s resistance to attack.

Accounts protected by a strong authenticator app or other robust sign-in methods are inherently more difficult to compromise than those relying on less secure options like email OTP or SMS. This granular information allows attackers to customize their fraud attempts. For example, identifying a target who relies on SMS for verification could facilitate SIM-swapping or real-time phishing attacks.

LevelBlue researcher Matthew Coady also found that detecting privileged accounts might be simpler, depending on how tenant configurations are set up. Administrator roles often have distinct password-reset requirements, while regular users might be excluded from an organization’s SSPR scope. If SSPR is restricted for standard users, any account that successfully advances to the method selection stage could potentially indicate a privileged account, making it a prime target for attackers. While not every account progressing through the portal is necessarily an administrator, these response patterns offer valuable reconnaissance opportunities.

Mitigating the Risk

Organizations must treat SSPR activities as a critical component of their identity security posture, particularly when observing a high volume of failed password-reset attempts across multiple usernames.

Despite Microsoft’s implementation of protective measures, such as throttling during the password reset process, organizations should not rely solely on these controls. Public identity workflows, when exhibiting observable differences in account responses, can still be exploited for reconnaissance.

The publicly available ResetSpy proof-of-concept tool further demonstrates how these response discrepancies can be automated to facilitate user enumeration and assess SSPR vulnerabilities.

What You Should Do

• Review SSPR Settings: Periodically audit and refine your SSPR settings to ensure that only appropriate users are included in the scope.
• Prioritize Strong Authentication: Favor the use of strong authentication methods, such as hardware security keys or authenticator apps, and minimize reliance on less secure options like security questions or alternate email addresses. Implement phishing-resistant MFA for all accounts, especially privileged ones.
• Monitor Audit Logs: Actively monitor Entra audit and sign-in records for unusual patterns of repeated password reset activities, suspicious requests targeting executive accounts, and frequent account-validation failures.
• Educate Users: Train users on identifying and reporting phishing attempts, particularly those related to password resets.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.