Why Phishing-Resistant MFA Matters — UprootSecurity Bootcamp

The previous lesson described each MFA factor and ranked them on a phishing resistance spectrum. This video makes the ranking concrete by walking through a real-world phishing attack that defeats traditional MFA in real time, then showing exactly why FIDO2/WebAuthn stops the same attack. The difference is not abstract — it is the difference between an attacker gaining full access to your corporate environment and the attack failing silently.

Attack demonstration

This video demonstrates adversary-in-the-middle phishing techniques for educational purposes. The tools and methods shown are publicly documented and actively used by real threat actors. Understanding how these attacks work is essential for recommending appropriate MFA controls — you cannot defend against what you do not understand.

Why Phishing-Resistant MFA Matters: Attack Walkthrough

The attack: Adversary-in-the-middle phishing

The attack begins with a phishing email containing a link to a login page that looks identical to the real one — same branding, same layout, same URL structure with a subtle domain variation. But this page is not static. It is running a reverse proxy (tools like Evilginx2 or Modlishka) that sits between the user and the legitimate service.

When the user enters their username and password, the proxy forwards those credentials to the real login page in real time. The real service responds with an MFA challenge. The proxy relays that challenge back to the user. The user enters their TOTP code or approves a push notification. The proxy captures the MFA response and forwards it to the real service. The real service issues a session token. The proxy captures the session token.

The attacker now has a valid, fully authenticated session. They did not need to crack the password or brute-force the MFA code. They sat in the middle and let the user do the authentication for them.

Why TOTP and SMS fail against this attack

TOTP and SMS both fail for the same fundamental reason: the user is the transport mechanism for the second factor, and neither mechanism verifies the identity of the site requesting the code.

When a user types a TOTP code into a phishing proxy, the code is valid — it was generated from the real shared secret and the current time. The proxy forwards it to the real site within the 30-second window. The real site accepts it because it is a legitimate code. The TOTP spec has no concept of "who is asking for this code" — it only verifies "is this the right code for this time window."

SMS is even worse. The code is sent to the user's phone via a channel the user trusts (a text message from the service). The user reads the code and types it into whatever page is in front of them. The phishing proxy forwards it. Authentication succeeds.

Push notifications face a similar problem. The real service sends a legitimate push notification to the user's phone because the proxy triggered a real login attempt. The user sees a genuine push notification from their genuine authenticator app and approves it. The proxy completes the session.

In all three cases, the MFA mechanism is functioning correctly from a cryptographic standpoint. The codes are valid. The approvals are genuine. The failure is architectural: none of these factors verify the origin of the request.

Why FIDO2 stops it

FIDO2 authenticators — hardware keys and passkeys — are bound to the origin (domain) of the service during enrollment. When the browser sends an authentication challenge to the authenticator, it includes the origin of the requesting page. The authenticator checks: does this origin match the origin I registered with?

If the user is on accounts.google.com, the origin matches and the authenticator signs the challenge. If the user is on accounts-g00gle.com (the phishing proxy), the origin does not match. The authenticator refuses to sign. There is no code to type, no prompt to approve, no action the user can take to override the check. The attack fails at the protocol level.

This is not a user-behavior defense ("train users to check the URL"). This is a cryptographic defense built into the authenticator hardware. The authenticator does not trust the user to verify the domain — it verifies the domain itself through the browser's Web Authentication API.

Real incident: Twilio and Cloudflare, August 2022

In August 2022, a coordinated phishing campaign targeted employees at Twilio, Cloudflare, and over 130 other organizations. The attack used SMS phishing messages directing employees to a fake login page running an adversary-in-the-middle proxy. The page captured credentials and TOTP codes in real time.

At Twilio, the attack succeeded. Employees who used TOTP-based MFA entered their codes into the phishing proxy, which replayed them to the real Okta login. The attackers gained access to internal systems and customer data.

At Cloudflare, the attack failed. Cloudflare employees had been issued FIDO2 hardware keys (YubiKeys) as their required MFA factor. When the phishing proxy presented the authentication challenge, the employees' YubiKeys refused to sign because the origin did not match cloudflare.com. Every targeted Cloudflare employee was protected — not because they recognized the phishing attempt, but because their hardware keys did.

Same attack, same day, same phishing infrastructure. The only difference was the MFA factor. TOTP was compromised. FIDO2 was not.

Policy recommendation

As a GRC Engineer, the Twilio/Cloudflare incident gives you a concrete, documented case to support phishing-resistant MFA recommendations. The policy tiers you should recommend: First, require phishing-resistant MFA (FIDO2 hardware keys or passkeys) for all privileged accounts — cloud infrastructure admins, identity system admins, security team members, and anyone with access to production systems or customer data. Second, require phishing-resistant MFA for all employees accessing sensitive data — engineering, finance, HR, legal. Third, require TOTP or push with number matching as the minimum for general workforce accounts where hardware key logistics are prohibitive. Fourth, eliminate SMS-based MFA entirely where possible, and document the residual risk where it cannot be eliminated. Frame this as a risk-based approach aligned with NIST 800-63B, not an all-or-nothing mandate.

What to carry forward

Phishing-resistant MFA is not a nice-to-have security enhancement — it is the only MFA mechanism that reliably stops adversary-in-the-middle attacks that are actively used against enterprises today. The Twilio/Cloudflare incident is the case study you will reference in risk assessments, in board presentations, and in conversations with engineering teams who push back on hardware key deployments.

The next lesson puts this knowledge to work: you will evaluate real-world scenarios and choose the right MFA factor based on the user population, the threat model, and the practical constraints of each environment.