Microsoft Entra Conditional Access Misconfigurations: How to Prevent MFA Bypass

Microsoft Entra Conditional Access is a powerful tool for securing access to your organization's resources by enforcing conditions like Multi-Factor Authentication (MFA), device compliance, location restrictions, and more. However, as with any security tool, its effectiveness is directly tied to how it's configured and it can be easy to misconfigure if you are unaware of the potential pitfalls.

We'll also walk through a real-world example of how attackers can exploit misconfigurations by bypassing your MFA requirements, ultimately compromising the security of your organization.

Understanding Microsoft Entra Conditional Access Policies

Microsoft Entra Conditional Access policies are designed to enforce security measures based on a set of predefined conditions. These conditions can include:

• Device platform (e.g., Android, iOS, Windows, macOS)
• Location (e.g., trusted IP ranges)
• Sign-in risk (e.g., low, medium, high)
• User or group memberships
• Client apps (e.g., browser, mobile apps, desktop clients)

When a user attempts to access a resource, Microsoft Entra conditional access policies evaluate these conditions to determine whether access should be granted, denied, or if additional security measures (like MFA) should be enforced.

The Pitfall: Conditional Access policy misconfiguration

One common mistake many organizations make is configuring their Conditional Access policies with conditions that inadvertently leave gaps attackers can exploit. For example, let's say you've set up a policy to require MFA for all users accessing your resources, but you've scoped it to specific device platforms by checking the boxes for all the available platforms.

While this may seem like a comprehensive approach to ensuring security across different device types, it opens up a critical loophole.

Exploiting the Device Platform Condition: MFA bypass

The device platform condition relies on the user agent string provided by the client during the authentication process. This string indicates the type of device or browser making the request (e.g., "Windows NT 10.0" for Windows devices, "iPhone" for iOS devices).

However, what happens if the user agent string is missing or manipulated?

Attackers can easily modify or completely strip out the user agent string in their requests, resulting in an "unknown" or blank platform. This means that if your Conditional Access policy is scoped only to specific platforms (like Android, iOS, Windows, etc.), it may not trigger the MFA requirement for devices that don’t match any of these conditions. This will result in an MFA bypass.

Example Attack Scenario:

1. Policy Setup: You configure a Conditional Access policy to require MFA for all device platforms by checking the boxes for all the available device platforms.
2. Attacker's Approach: An attacker attempts to access a corporate resource using a tool like Burp Suite or Zed Attack Proxy. By modifying the user agent string to be blank the attacker's request does not match any of the specified platforms.
3. Result: Since the policy only enforces MFA for recognized platforms, the attacker's connection bypasses the MFA requirement, potentially gaining unauthorized access to sensitive resources.

Why This Happens

This loophole exists because Conditional Access policies that use conditions default to allowing access if the condition is not explicitly identified. This is especially problematic if there's no fallback policy in place that covers all devices and users regardless of conditions.

Conditional Access best practices to avoid this issue:

To protect your environment from this type of vulnerability, consider the following best practices:

1. Use Inclusionary Policies:
• Instead of using inclusionary conditions (i.e., specifying certain device platforms), create base policies that includes everything with no conditions. Then for specific needs exclude users, devices, or groups as required and create a secondary policy that applies the required conditions. This will allow anything that does not match the secondary policy to fall back to the original policy requiring the control you are implementing such as MFA.
• For example, have a default policy that enforces MFA for all devices, regardless of the platform. For service accounts that require authentication without MFA create a group named “MFA Bypass for trusted locations and service accounts”. Exclude this group from the base MFA policy that applied to all logins with no conditions and create a secondary policy the grants access for the specified group without an MFA requirement while including a network condition that includes only the IP addresses you know they will be utilized from.
2. Leverage the "Require All" Operator:
• Use the "require all" operator when assigning users to a policy that will be the base policy of any critical security control such as MFA, session, token, IP restriction, device compliance, hybrid join requirements policies or anything else you are utilizing to ensure access is legitimate. If you don’t want the policy to apply to everyone that is ok, just create a secondary policy that includes them with different requirements and exclude them from the base catch-all policy.
3. The "Catch-All" or Base Policy:
• The catch-all or base policy ensures that when a threat actor finds a way to bypass any conditions you have put in place they hit this policy rather than bypassing controls. To use the example from earlier where a company sets a condition for device type, there may be legitimate reasons to treat one device type differently from another when creating your policies. Simply create a dynamic device group that includes all of those devices, exclude that group from your base policy, and apply a new policy with the requirements that are specific to that platform to that same dynamic group. You will have the same functionality you were seeking to implement without the vulnerability outlined in this article.
4. Regularly Review Conditional Access Policies:
• Periodically audit your Conditional Access policies to identify any potential gaps. Microsoft Entra provides tools like Sign-in logs and Microsoft Entra Conditional Access insights to help you understand how your policies are being applied. In most organizations multiple people will have access to make changes in these areas. I recommend also creating custom alerts that trigger whenever these policies are modified, deleted, or created so they can be reviewed to ensure these principles remain in place. This article has details that should be get you started (Microsoft Azure - Create Alert For Conditional Access Policy Changes - GeeksforGeeks).
5. Monitor and Test for Security Gaps:
• Use security tools to simulate sign-ins with modified user agent strings to see if your Conditional Access policies are truly effective. Penetration testing can be invaluable in identifying these types of misconfigurations.
6. Review Microsoft's recommendations for recovering from misconfigurations.
• Recover from misconfigurations in Microsoft Entra ID - Microsoft Entra | Microsoft Learn

Conclusion

Don't let a simple misconfiguration become the weakest link in your security chain. Make sure your Conditional Access policies are set up to cover all scenarios, even those you might not have initially considered. You can read about a similar misconfiguration and how to avoid it here Misconfigured Block for Legacy Authentication: A Hidden Security Risk in Microsoft Entra.