Hardware security keys were supposed to end phishing. They did not. Adversary-in-the-Middle attacks using tools like Evilginx2 proxy the entire authentication session in real time, including FIDO2 challenges, and steal the session cookie after authentication completes. The key did its job. The attacker got in anyway.
Analysis Briefing
- Topic: AiTM phishing attacks bypassing FIDO2 hardware key authentication
- Analyst: Mike D (@MrComputerScience)
- Context: A structured investigation kicked off by Grok 4
- Source: Pithy Cyborg | Pithy Security
- Key Question: If an attacker can steal your session after your hardware key authenticates you, what does the key actually protect?
How Evilginx2 Proxies Through Your Hardware Key
Evilginx2 is an open-source adversary-in-the-middle framework that sits between a victim and a legitimate web application. When the victim visits a phishing URL, Evilginx proxies the entire login flow in real time through the legitimate service. The victim sees the real login page, served through the attacker’s proxy. Every interaction, including hardware key authentication, completes successfully against the real service.
The victim’s hardware key receives a legitimate FIDO2 challenge from the real origin server, routed through the proxy. It signs the challenge. The authentication succeeds. The real server issues a session cookie. The proxy captures that cookie before forwarding the response to the victim.
The attacker now has a valid, authenticated session cookie with no further need for credentials or the hardware key. The victim’s browser also has a valid session. Both can use the service simultaneously until the session expires or is revoked.
This attack bypasses TOTP codes, SMS OTP, push notifications, and most hardware key deployments because it steals the post-authentication artifact, not the credential itself. The credential is irrelevant once the session exists.
The Origin Binding That Actually Stops the Attack
FIDO2’s protection against AiTM attacks comes from origin binding. When a hardware key signs an authentication challenge, it includes the origin of the requesting page in its response. The server verifies that the signed origin matches the expected origin for the application. A proxy serving the page from a different domain sends a different origin to the key, and the server rejects the authentication.
The protection works when correctly implemented. The failure mode is implementation gaps. Applications that do not enforce origin binding, or that accept authentication responses without verifying the signed origin, are vulnerable to AiTM proxy attacks even with FIDO2 hardware keys.
Passkeys, the FIDO2 implementation built into modern operating systems and browsers, implement origin binding correctly in current versions. An application that accepts passkeys and enforces origin binding on the server side is genuinely resistant to Evilginx2-style attacks. The passkey cannot be used to authenticate to a proxied page because the origin will not match.
The session cookie theft problem remains even with correct origin binding. After successful authentication, the session can be stolen from the proxy’s position. Binding sessions to client certificates or IP addresses reduces the value of stolen cookies but does not eliminate the theft itself.
What Token Binding Was Supposed to Fix and Why It Failed
Token Binding was an IETF standard designed to cryptographically bind authentication tokens to the TLS connection they were issued over. A token bound to a specific TLS channel cannot be replayed over a different connection. An attacker who steals a bound token cannot use it from a different machine.
Microsoft implemented Token Binding in Edge and Internet Explorer. Google implemented it in Chrome. The standard was then deprecated. Chrome removed support in 2020. The removal happened because Token Binding required coordination across browsers, servers, and intermediaries, and the deployment complexity was too high to achieve the critical mass needed for the protection to be meaningful.
The failure of Token Binding means that session-level protection against AiTM attacks relies on heuristics: IP binding, device fingerprinting, anomaly detection on session behavior, and short session lifetimes that limit the value of stolen cookies. None of these are cryptographic guarantees.
What This Means For You
- Verify that your application enforces FIDO2 origin binding server-side, not just that it accepts hardware key responses. Accepting a signed response without validating the origin is the implementation gap that makes hardware keys vulnerable to AiTM.
- Implement Conditional Access policies that evaluate session risk continuously, not just at login. A session cookie stolen post-authentication can be detected by access from an unexpected location, device, or IP. Conditional Access that re-challenges suspicious sessions limits the damage window.
- Reduce session lifetime for sensitive applications. A stolen session cookie with a 30-minute lifetime is significantly less valuable than one with an 8-hour lifetime. Session duration is a cost-benefit trade-off between user friction and attacker utility.
- Test your authentication implementation against Evilginx2 in a lab environment before assuming hardware key deployment is phishing-resistant. The test is not complicated to set up and will tell you immediately whether origin binding is enforced correctly.
Enjoyed this deep dive? Join my inner circle:
- Pithy Cyborg → AI news made simple without hype.
- Pithy Security → Stay ahead of cybersecurity threats.