Between April and November 2025, a single threat actor ran a credential-phishing campaign against at least 18 U.S. universities — including the University of Michigan, UC Santa Cruz, and Virginia Commonwealth — using roughly 70 rotating domains routed through Cloudflare. Attackers sent personalized emails with TinyURL links mimicking legitimate single sign-on portals. When a user clicked, Evilginx intercepted the login process, stealing credentials and the session cookie granted after MFA completion, thereby hijacking accounts. Every victim had MFA enabled. Every victim completed MFA successfully. Every victim’s account was compromised anyway.
This is not an edge case. It is the normal shape of a 2025 credential attack. The most expensive assumption in enterprise security right now is that MFA — any MFA — constitutes a control against modern phishing. The Verizon and CISA data shows it isn’t, and the regulatory bodies that used to treat “MFA enabled” as sufficient have already moved. NIST SP 800-63-4, finalized July 31, 2025, now requires phishing-resistant authentication at AAL3 and requires verifiers to offer a phishing-resistant option at AAL2. OMB Memorandum M-22-09 mandates it for federal agencies. Most private-sector organizations are running MFA that wouldn’t clear either bar.
What “MFA” Actually Means in Most Deployments
The term “multi-factor authentication” covers a range of methods with wildly different security properties. In the typical enterprise, the word usually means one of four things: an SMS code, an email link, a TOTP code from an authenticator app (Google Authenticator, Authy), or a push notification the user approves in Microsoft Authenticator or Duo. All four are better than a password alone. None is resistant to the techniques attackers are currently using.
The shared weakness is that all four produce a secret — a code, an approval, a session — that passes through the user. Anything that passes through the user can be intercepted, relayed, or coerced. The entire category is sometimes called shared-secret MFA, and its failure mode is not theoretical. The Verizon 2025 Data Breach Investigations Report found that prompt bombing now appears in 14% of social engineering incidents, while sophisticated MFA bypass techniques like adversary-in-the-middle, password dumping, and SIM swapping together account for just 4% of breaches. Push-fatigue attacks succeed at roughly 3.5 times the rate of technical bypasses because they don’t require any technical bypass — they require a tired user.
The Four Ways Attackers Walk Around Your MFA
AiTM phishing is the most important of these because it renders the entire category of shared-secret MFA moot. When a victim clicks the lure, they land on a reverse-proxy server running a kit such as Evilginx, Tycoon 2FA, EvilProxy, or Sneaky 2FA. The proxy silently forwards the victim’s browser traffic to the real Microsoft or Google login endpoint. The user sees a real login page — because it is the real login page, relayed through a proxy — enters credentials, completes the MFA challenge, and is issued a valid session cookie. The proxy captures that cookie. The attacker replays it. From the identity provider’s perspective, nothing abnormal happened: valid credentials, valid MFA, valid session.
The economics are what make this a commodity threat rather than an APT capability. Sekoia.io identified eleven major AiTM phishing kits in active use during early 2025, with Tycoon 2FA earning the highest threat score. The phishing-as-a-service business model operates on a subscription basis, with access to fully featured kits ranging from $100 to $1,000 per month. A criminal with no technical skill can run an MFA-bypassing campaign against Microsoft 365 for less than the cost of a team SaaS license. Named actors using these kits include the Russian state-affiliated Star Blizzard group, the prolific cybercriminal operator Storm-0485, and the Scattered Spider / LAPSUS$ / ShinyHunters ecosystem that has driven many of the highest-profile 2024–2025 identity breaches.
The academic picture is just as uncomfortable. A 2025 study measured Evilginx’s ability to bypass MFA with minimal proxy-induced delays that are difficult to detect, and surveyed 48 websites in Japan and 54 global websites, revealing that 80% of major web services are vulnerable to Evilginx attacks, particularly those using traditional MFA methods.
What “Real” MFA Actually Means
The term the regulatory bodies now use is phishing-resistant MFA. It has a specific technical definition, not a marketing one. Phishing-resistant MFA is a form of multi-factor authentication that uses asymmetric cryptography and domain binding to make credential theft structurally impossible. CISA recognizes two implementations: FIDO/WebAuthn and PKI-based authentication. Private keys never leave the authenticator device, and each authentication challenge binds to a specific domain. If a user visits a phishing site, the authenticator cannot produce a valid response because the domain doesn’t match.
Two properties matter, and both have to be present:
Origin binding. The authenticator refuses to produce a signature for any domain other than the one it was registered to. An Evilginx proxy running on login-microsoft-sso[.]com is not login.microsoftonline.com, so a FIDO2 key silently refuses to complete the ceremony. There is no code to enter, no prompt to approve, no cookie to intercept. The user cannot be phished because the user is not the verifier — the hardware is.
Non-exportable private keys. The cryptographic secret stays inside the authenticator (a security key, a TPM, a secure enclave). It cannot be stolen with malware, relayed with a proxy, or extracted by a sufficiently convincing help desk. This is the property NIST SP 800-63-4 formalizes at AAL3.
| Method | AiTM | Fatigue | SIM Swap | NIST AAL |
|---|---|---|---|---|
| SMS code | FAIL | N/A | FAIL | Not permitted |
| Email OTP | FAIL | N/A | N/A | Not permitted |
| TOTP app (Google Auth, Authy) | FAIL | N/A | OK | AAL2 (limited) |
| Push approval (no number match) | FAIL | FAIL | OK | Not sufficient |
| Push + number matching | FAIL | OK | OK | AAL2 (limited) |
| Synced passkey (FIDO2) | PASS | PASS | PASS | AAL2 |
| Hardware key (YubiKey, PIV/CAC) | PASS | PASS | PASS | AAL3 |
CISA’s guidance is unambiguous on the endpoint of this conversation: FIDO standards and the WebAuthn protocol are the only widely available phishing-resistant forms of MFA. The fallback category — PKI-based authentication with smart cards (PIV/CAC) — covers regulated and federal use cases but shares the same core properties: origin binding plus a non-exportable private key.
The Operational Reality of Deploying It
The argument against phishing-resistant MFA has historically been that FIDO2 doesn’t cover every use case, that legacy apps can’t handle WebAuthn, that security keys cost money, and that passkey recovery is messy. Those concerns were legitimate five years ago. In 2026 they mostly aren’t. FIDO2, WebAuthn and passkeys are supported across all major operating systems and browsers; Apple, Google and Microsoft all support passkeys natively; Cloud identity providers and Identity-as-a-Service vendors offer straightforward FIDO2 authentication workflows.
The remaining hard problems are narrower than the industry sometimes admits:
- Legacy applications. Anything still running against on-prem AD FS or ancient SAML implementations may need a protocol bridge. This is a migration problem, not a reason to keep issuing TOTP codes for the cloud stack that already supports WebAuthn.
- Account recovery. If recovery routes through SMS or an email link, you have rebuilt the attack surface you just eliminated. Help-desk-initiated resets need to require in-person verification or video ID with live challenge for anything high-privilege.
- Public / customer-facing portals. Consumer passkey adoption is still uneven, so organizations typically offer passkeys prominently while leaving fallback options available. That’s acceptable for public users; it is not acceptable for admins.
The reasonable deployment sequence, consistent with both CISA’s playbook and the USDA’s documented rollout of roughly 40,000 users onto FIDO2 and Windows Hello for Business: start with privileged accounts (admins, finance, executives) and high-value apps (email, file storage, remote access, SSO itself), enforce phishing-resistant MFA there first, then expand outward. The federal playbook calls this AAL3 for privileged access, AAL2 for general workforce, with SMS and push-only methods deprecated rather than banned outright.
The Uncomfortable Conclusion
“We have MFA” is now closer to a compliance statement than a security statement. The Verizon DBIR has documented identity-based attacks as the dominant path into enterprises for three consecutive years. CrowdStrike’s 2026 Global Threat Report found that 82% of detections in 2025 were malware-free, meaning adversaries are increasingly relying on identity abuse rather than malicious code to breach environments. PwC’s phrasing — attackers are “logging in rather than breaking in” — describes the actual threat model.
The practical test is simple. If your MFA produces something the user can be tricked into handing over — a code, an approval, a cookie collected by a proxy — it is not phishing-resistant. If your MFA requires the user’s hardware to sign a challenge bound to a specific domain, with a private key that never leaves the device, it is. The middle ground that most enterprises currently occupy is the ground attackers have already learned to walk across.
The honest framing: MFA is not a control against skilled phishing. Phishing-resistant MFA is. The two have been treated as the same product for a decade, and the universities, hospitals, casinos, and Fortune 500s that have been breached through AiTM, push bombing, and SIM swaps over the past eighteen months were all running MFA when it happened.
