Abusing Entra ID Misconfigurations to Bypass MFA

On a recent external assessment, I stumbled upon a method to bypass a client’s MFA requirement:  access a single-sign on (SSO) token and leverage that token to access internal applications that—by policy—should have been locked behind an MFA prompt, all without triggering an MFA alert on the end-user’s mobile device. This was possible due to a misconfiguration in the client’s Entra ID Conditional Access Policy for third-party MFA and a first-party integration with the myaccount.microsoft.com portal. 

To understand the vulnerability, there are a few things to understand about the Entra ID authentication flow. Within any Entra ID environment, there are numerous cloud applications that are leveraged when a user authenticates. The application with the misconfiguration is “My Profile” which utilizes “My Account”, “My Apps”, and “My Signins” for additional functionality within the “My Profile” portal. These separate applications are unique and can be individually configured with conditional access policies.

For this vulnerability to be present, four specific requirements must first be met: 

1. The attacker must have valid credentials to sign into the Entra ID domain. These credentials can be brute forced through password sprays, found in online dumps, or obtained through social engineering.
2. Entra ID must be configured to use Duo authenticator (or potentially other third-party MFA provider solutions) as the only method for MFA per the instructions on the Duo website.
3. The “Require Duo MFA” conditional access policy must be configured for “Select Cloud Apps” rather than “All Cloud Apps” (See Image 1 Below). 
4. The cloud application “My Profile” must not be included in the conditional access policy while other applications utilized by the “My Profile” application — like “My Account” or “My Sign-Ins” — are included.

When these four conditions are present in an Entra ID Environment, the myaccount.microsoft.com page loads fully into the browser and provides an SSO token to the user before the conditional access policy is executed and a redirect to the Duo authenticator domain occurs to enforce the MFA authentication.

This odd load-time behavior is what alerted me to the potential for an MFA bypass. See the video below to observe how, briefly, the myaccount.microsoft.com page loads fully into the browser window before the redirect to the MFA prompt domain occurs.

In order to test whether this strange behavior was due to the myaccount.microsoft.com page not respecting the conditional access policy or a misconfiguration in the conditional access policy, in the testing environment we changed one variable—Assignments: All Cloud Apps—rather than the vulnerable “Select Cloud Apps.” The results of that test can be seen below and show that the authentication process on myaccount.microsoft.com functions in a manner where the page is not loaded into the browser prior to the MFA prompt.

The exploit to bypass the misconfiguration is trivial. Using Burp Suite, or an HTTP/s proxying software of your choosing, simply proxy the traffic while authenticating to the myaccount.microsoft.com portal and manually forward packets until there is enough content loaded for you to select a new element on the page and add that to the navigation flow. If the packets are manually forwarded and a new element is selected before the authorization redirect to the Duo portal is loaded into the page, the attacker is able to navigate through the myaccount.microsoft.com portal to access internal applications and manipulate user account details such as password and MFA devices prior to authorization with MFA.

Limitations:

While this misconfiguration can lead to compromise of internal resources, there are some limitations to what it can accomplish that are all based on client-configurations within the conditional access policies. 

Since cloud-native Microsoft 365 applications are typically configured as part of the conditional access policy that requires MFA, this attack is not useful for accessing M365 resources such as Word Online, Teams, Outlook, or other Microsoft applications through the My Apps portal. Likewise, any other cloud applications that are configured to require multi-factor authentication will still be protected even when being accessed through the My Apps portal. There is also not a known method to elevate this basic token to a more robust token to access portals such as portal.office.com or entra.microsoft.com.

During testing and work with the Microsoft Security and Response Center, we examined four different Microsoft Entra ID environments. Of these four environments, only two contained the application “My Profile”. I compared licensing, where possible, and found no correlation between licensing and the existence of the “My Profile” application within the tenant.

I attempted to bypass this limitation in environments that did not contain the application by adding the application ID to the conditional access policy using the Entra ID PowerShell Modules. This was unsuccessful for the environments that didn’t list the application since it appears that those environments do not recognize the application by ID or name. 

Microsoft has been made aware of this odd behavior within the Entra Tenants and is working on a solution to address the lack of “My Profile” applications in some tenants.

Effectiveness of the attack: 

Many organizations must balance user-experience and convenience with security measures. When implementing a multi-factor authentication policy at an organization, many users do not want to approve multiple notifications just to access a single application. Many organizations will implement a structure of protecting the initial sign in or externally facing applications with MFA when being accessed from untrusted networks and leaving applications only accessible from trusted zones unsecured with MFA. 

In this example, and in real-world tests, bypassing the MFA prompt on myaccount.microsoft.com allowed the attacker to pause web application pages from loading and navigate from a non-trusted zone myaccount.microsoft.com portal to the trusted zone of myapps.microsoft.com without providing an MFA token and access business data on internal applications. 

The business logic behind the decision to not enforce MFA on these internal applications is valid, as the initial MFA prompt should have been completed before being able to access the myapps.microsoft.com portal. However, this vulnerability takes advantage of a slight delay in timing and allows the attacker access to a valid SSO token before authenticating with Duo authenticator and bypasses the business logic in place to prevent access to internal applications without MFA. 

Additionally, finding a multifactor-authentication provider that functions well with all vendors and applications leveraged by a business is nearly impossible. As MFA continues to become a business standard process and procedure across domains, multi-factor authentication providers have varying levels of support with the numerous cloud applications within a business environment. These limitations provide ample targets for attackers looking to leverage this vulnerability against Entra ID subscribers who are only applying MFA requirements through conditional access policies to specific applications either due to business-requirements or lack of support with the specific multi-factor vendor. 

Remediation:

In the environments that do have the “My Profile” Enterprise application to ensure the MFA prompt is triggered at the correct time when the user navigates to the myaccount.microsoft.com portal, the tenant administrator must configure a conditional access policy to target the “My Profile” application.

In the environments that did not include “My Profile” the only method to enforce MFA on myaccount.microsoft.com is to enforce MFA on “All Cloud Applications.” Since the “My Profile” application does not appear in all environments, the misconfiguration occurs from users believing all first-party Microsoft applications are covered by the conditional access policy. 

Conclusion: 

Although basic in its implementation and execution, finding this vulnerability was a stark reminder that although complex security systems are in use across enterprises, sometimes a simple misconfiguration can lead to compromise of secure data within the environment with minimal time investment or technical knowledge. As a penetration tester, it is easy to get bogged down in the technicalities of complex exploits and the prestige that comes along with executing a complex exploit chain. But sometimes it’s good to remember that simple misconfigurations with simple exploits can cause just as much damage to an environment and it is always good to check the basics.

Find more stories like these in our Azure Pentesting eBook.