Why Your MFA Bypass Techniques Are About to Become Obsolete

TLDR: Passkeys represent a fundamental shift in authentication by binding credentials to specific domains, effectively killing traditional phishing and adversary-in-the-middle (AITM) attacks. While they are not a silver bullet against compromised endpoints, they force attackers to move away from credential harvesting and toward more complex, endpoint-specific exploitation. Security professionals should prioritize testing for implementation flaws like downgrade attacks rather than relying on legacy MFA bypass methods.

Passwords were a mistake from the start. We have spent decades trying to fix them with increasingly complex requirements, rotation policies, and second factors, but the reality remains that the majority of successful compromises against users still stem from the abuse of legitimate credentials. Whether it is a simple phishing page or a sophisticated AITM proxy, the core issue is that traditional MFA—SMS, TOTP, or push notifications—is fundamentally phishable.

The industry is finally moving toward FIDO2 and WebAuthn, and the shift to passkeys is the most significant change in authentication security in years. If you are still relying on your favorite AITM toolkit to drop shells, you need to understand why that runway is ending.

The Mechanics of Phishing Resistance

At the heart of FIDO2 is a cryptographic challenge-response mechanism that binds the credential to the origin. When a user registers a passkey, the authenticator generates a public-private key pair. The public key is sent to the relying party, while the private key remains on the device, protected by hardware-backed security like a TPM or Secure Enclave.

When a user logs in, the server sends a challenge. The authenticator checks the origin—the actual domain—before signing the challenge. If the domain does not match the one used during registration, the authenticator refuses to sign. This is why tools like Evilginx struggle against FIDO2. In a traditional AITM attack, the proxy sits between the user and the real site, capturing the session cookie. With a passkey, the proxy cannot spoof the origin, and the authenticator will not provide the necessary signature to the attacker.

The New Attack Surface: Downgrades and Endpoints

Attackers are not going to stop just because their favorite phishing kits stopped working. They are shifting their focus to the weakest links in the implementation chain.

One common technique is the downgrade attack. If a service supports passkeys but still allows users to fall back to SMS or TOTP, an attacker can simply ignore the passkey and force the user to authenticate via a phishable method. During a penetration test, your first step should be to map out the authentication flow. Does the application allow you to select a "different way to sign in"? If so, you have found your entry point.

Another, more advanced vector involves compromising the endpoint itself. If an attacker has code execution on the user's machine, they do not need to phish the credentials. They can interact with the browser or the operating system to hijack an active session or, in some cases, manipulate the browser to perform actions on the user's behalf. The research into Browser-in-the-Browser (BitB) attacks demonstrates how attackers can create convincing, fake browser windows that bypass standard origin checks. If an attacker can inject a malicious script into the page, they can potentially manipulate the WebAuthn API calls or use VNC-style access to interact with the browser session directly.

Testing for Implementation Flaws

For a pentester, the focus shifts from "can I phish this user" to "how does this application handle authentication state and recovery?"

When you encounter a target using passkeys, look for:

1. Fallback mechanisms: Can you trigger an SMS or email-based recovery flow that bypasses the FIDO2 requirement?
2. Session persistence: How long does the session last after a successful passkey login? If the session cookie is not properly scoped or if the application lacks robust session management, you might be able to hijack the session even if you cannot bypass the initial login.
3. Registration flows: Can you register your own device as a secondary authenticator? If the application allows adding new passkeys without requiring a high-assurance re-authentication, you have achieved persistence.

The Defensive Reality

Defenders need to stop treating MFA as a binary "on or off" switch. The goal is to reach a state where phishing-resistant authentication is the only option. This means disabling legacy MFA methods like SMS and voice calls entirely.

Organizations should also implement strict Content Security Policies (CSP) to mitigate the risk of cross-site scripting (XSS) that could lead to the BitB attacks mentioned earlier. If you are a developer, ensure your WebAuthn implementation is strictly enforcing the origin and rpId parameters. Never trust the client-side implementation of these checks; they must be validated on the server side.

Passkeys are not a magic wand that makes security problems disappear. They are a powerful tool that raises the cost of attack significantly. As we move forward, the "easy" wins of credential harvesting will vanish, and we will see a surge in more targeted, endpoint-focused research. Start auditing your authentication flows now, because the era of phishable MFA is coming to a close.