Microsoft Password Reset Portal Could Reveal Users and MFA Protection Details
Microsoft Entra ID’s public password-reset portal can reveal valid accounts and registered MFA methods to unauthenticated users.
LevelBlue researcher Matthew Coady found that Microsoft Entra ID’s public Self-Service Password Reset portal returns different responses for valid and invalid usernames. Unauthenticated queries can reveal whether an account exists, whether it is eligible for SSPR, and which verification methods are registered, including Microsoft Authenticator, SMS, voice calls, or security questions. Differing policy errors may also help distinguish privileged accounts when SSPR is limited to selected groups. A public proof-of-concept named ResetSpy automates the enumeration; Microsoft throttles resets, but organizations should still restrict SSPR and monitor repeated attempts.
- Portal responses differ for valid, ineligible, and nonexistent Entra ID accounts.
- Eligible accounts can expose methods such as authenticator, SMS, voice, or security questions.
- Some tenant settings may make privileged accounts easier to identify.
- Public ResetSpy proof-of-concept automates enumeration despite Microsoft throttling.
- Limit SSPR scope, prefer phishing-resistant MFA, and monitor repeated reset attempts.
Full article617 words · extracted from cybersecuritynews.com · click to collapse
Microsoft’s SSPR portal may expose sensitive account details to unauthenticated users, including whether an Entra ID account exists and its registered password-reset methods.
Such exposure might assist attackers in refining their phishing, password-spraying, and social engineering attacks on corporate networks.
Microsoft Entra ID’s Self-Service Password Reset (SSPR) feature lets users reset forgotten passwords through the public portal by entering their email and choosing a registered verification method.
Research by Matthew Coady highlights a problematic aspect of the portal: the server responses vary based on the provided account. This variability can indicate the existence of an account, eligibility for SSPR, and which verification options are available for eligible users.
The portal operates using an ASP.NET form workflow. When a username is submitted, the server’s reply includes a field termed CurrentViewName.
For invalid accounts, the portal stays on the identifier screen, while valid accounts may either advance to the selection of a password-reset method or generate a policy-related error message.
These policy responses are crucial as they can still signify that the account has been recognized before any restrictions kick in. For instance, if a user is part of a group that isn’t enabled for SSPR, the response will differ from that for a fully nonexistent user.
Microsoft Password Reset Portal Exposes
This situation creates a user-enumeration issue. An attacker armed with a list of addresses acquired from public sources, data breaches, or previous phishing campaigns may identify valid corporate accounts before launching credential attacks.
For users eligible for SSPR, the portal can display registered verification methods such as Microsoft Authenticator codes, SMS, voice calls, or security questions. The type of verification affects the attack resistance.
Accounts secured through an authenticator app or reliable sign-in method are difficult targets compared to ones relying on email OTP or SMS. Thus, attackers can customize fraud attempts based on this data; for example, identifying a target using SMS could facilitate SIM-swapping or live phishing.
LevelBlue researcher Matthew Coady also found that privileged accounts may be easier to detect depending on tenant configurations. Specific password-reset requirements apply to administrator roles, while regular users may be excluded from an organization’s SSPR scope.
If SSPR is limited for standard users, any account that passes through to method selection could indicate a privileged account, making it a prime target for attackers. While not every account moving through the portal is an administrator, the patterns in responses may offer helpful reconnaissance.
Organizations should regard SSPR activities as critical to identity security, especially when observing numerous failed password-reset attempts across multiple usernames.
Defenders need to review SSPR settings, ensuring that only suitable users are included. Strong authentication methods should be favored, and reliance on security questions and alternate emails should be minimized. Furthermore, phishing-resistant MFA is advisable for privileged accounts.
Security teams should also monitor Entra audit and sign-in records for patterns of repeated password reset activities, unusual requests against executive accounts, and account-validation failures.
Despite Microsoft implementing protective measures such as throttling in the password reset process, organizations should not solely depend on these controls. Public identity workflows may serve as reconnaissance opportunities when differing account responses are observable.
The publicly available ResetSpy proof-of-concept showcases how these response discrepancies could be automated for user enumeration and estimating SSPR vulnerabilities.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
Abinayahttps://cybersecuritynews.com/
Abi is a Security Editor and fellow reporter with Cyber Security News. She is covering various cyber security incidents happening in the Cyber Space.