Bypassing Phishing-Resistant MFA: The Windows Hello for Business Downgrade Attack

TLDR: Researchers have identified a critical authentication-downgrade vulnerability in Windows Hello for Business (WHfB) that allows attackers to bypass phishing-resistant MFA. By intercepting the authentication flow and modifying the isFidoSupported parameter to false, an attacker can force a fallback to weaker, phishable authentication methods like passwords and OTPs. This technique, demonstrated using Evilginx, highlights the danger of relying on default authentication settings and underscores the necessity of enforcing strict Conditional Access policies.

Authentication security is often treated as a binary state: you either have MFA or you do not. For years, the industry has pushed toward phishing-resistant hardware tokens and platform authenticators like Windows Hello for Business. The assumption is that once a user is enrolled in these methods, the threat of credential harvesting via traditional proxy phishing vanishes. That assumption is dangerous. Recent research demonstrates that even when a user is fully enrolled in phishing-resistant MFA, the underlying authentication protocol can be manipulated to force a downgrade to legacy, phishable methods.

The Mechanics of the Downgrade

The vulnerability lies in the negotiation phase of the WebAuthn authentication flow. When a user initiates a login, the client browser communicates with the server to determine which authentication methods are supported. This negotiation includes parameters that signal the capabilities of the client platform.

During a standard authentication request, the client sends a JSON payload to the server. This payload contains a specific boolean flag, isFidoSupported. When set to true, the server expects a FIDO2 or WHfB assertion. However, if an attacker acts as an adversary-in-the-middle (AITM) using a tool like Evilginx, they can intercept this request before it reaches the server. By modifying the isFidoSupported parameter to false, the attacker effectively tells the server that the client is incapable of performing FIDO2-based authentication.

The server, seeing this flag, assumes the client is legacy or misconfigured and gracefully falls back to the next available authentication method. In many enterprise environments, this fallback is a password followed by an SMS or push-based OTP. Because the attacker is already proxying the connection, they can capture the password and the OTP in real-time, effectively bypassing the phishing-resistant requirement entirely.

Technical Execution and Interception

To execute this, an attacker needs to position themselves between the user and the target identity provider, such as Microsoft Entra ID. Using Burp Suite or a custom proxy, the attacker monitors the traffic for the specific endpoint responsible for credential type negotiation.

The following snippet represents the type of JSON structure an attacker targets during the interception:

{
  "username": "user@company.com",
  "isFidoSupported": true,
  "isPasswordSupported": true,
  "isOtpSupported": true
}

By changing isFidoSupported to false, the attacker forces the server to ignore the hardware-backed authentication path. The server then responds with a challenge for a password and an OTP. Since the attacker is proxying the entire session, they simply pass these requests to the user, collect the responses, and use them to authenticate to the actual service. The user, believing they are performing a standard login, provides the credentials, and the attacker gains a valid session cookie.

Real-World Applicability

For a pentester or red teamer, this technique is a game-changer. Many organizations believe that by enabling "Passwordless" or "FIDO2" authentication, they have eliminated the risk of account takeover via phishing. This research proves that the risk remains if the identity provider is configured to allow fallback methods.

During an engagement, you should look for environments where MFA is enforced but where legacy authentication protocols are still enabled for compatibility. If you can successfully proxy the login page, you are not limited by the user's security settings. You are limited only by the server's willingness to accept a downgraded authentication request. If the server accepts the modified isFidoSupported flag, the phishing-resistant MFA is effectively neutralized.

Hardening the Perimeter

Defending against this requires moving beyond simple MFA enforcement. Administrators must configure Conditional Access policies to explicitly require "Phishing-resistant MFA" as an authentication strength. By setting this requirement, the server will reject any authentication attempt that does not provide a valid FIDO2 or WHfB assertion, regardless of what the client claims it supports.

Furthermore, organizations should audit their identity provider settings to disable legacy authentication methods entirely. If a user is enrolled in a phishing-resistant method, there is rarely a valid business reason to allow them to fall back to SMS or email-based OTPs. Limiting the registration of new security information to managed, compliant devices also reduces the surface area for an attacker to register their own rogue authenticators.

Authentication is only as strong as its weakest allowed path. If your configuration allows a downgrade, your phishing-resistant MFA is merely a suggestion, not a requirement. Test your policies, audit your fallback methods, and ensure that your identity provider is configured to reject anything less than the strongest possible authentication.