Can phishing bypass MFA?

Yes - and routinely. Standard MFA (SMS code, TOTP authenticator app, push approval) is bypassed by Adversary-in-the-Middle proxy phishing, OAuth consent grant abuse, MFA push fatigue, SIM swap attacks and session-cookie theft. The shift since around 2022 is that these techniques moved from elite threat actors to commodity tooling that any attacker can deploy. Phishing-resistant MFA - FIDO2 hardware keys, passkeys, certificate-based authentication - remains effective because it cryptographically binds the challenge to the legitimate origin.

What is MFA fatigue or push bombing?

Once an attacker has a username and password (from a previous credential leak or basic phishing), they trigger MFA push notifications repeatedly - sometimes dozens per minute. The user, annoyed or confused, eventually taps Approve to make the alerts stop. The attacker is in. Defenses: number-matching push prompts (user must enter a 2-digit number from the login screen rather than just tapping Approve), rate limits on MFA challenge attempts and user training on what to do when push fatigue starts.

Does SIM swap really still work in 2026?

Yes, especially for SMS-based MFA. The attacker social-engineers the carrier into porting the victim's phone number to an attacker-controlled SIM, then receives MFA SMS codes themselves. US carriers have improved KYC since 2020 but the attack remains practical against employees of organizations that haven't moved off SMS. The defense: get off SMS as a second factor - TOTP authenticator apps are better; FIDO2 / passkeys are best.

What is the FIDO2 / passkey defense, in plain terms?

FIDO2 / WebAuthn / passkeys are an authentication standard where the user's device holds a private key bound to the legitimate origin (e.g., bound specifically to accounts.google.com). When a login attempt happens, the browser confirms the origin matches and runs a cryptographic challenge with the device. A phishing proxy on a different domain cannot complete the challenge - the browser refuses to participate. The result: AiTM, consent prompts that pretend to be the legitimate origin and clone sign-in pages all fail at the cryptographic layer rather than the human layer.

Where does phishing simulation training fit if MFA is broken?

MFA isn't broken - standard MFA is incomplete. Two layers of defense remain critical: (1) phishing-resistant MFA at the technical layer to defeat AiTM and consent phish; (2) phishing simulation training at the human layer so employees recognize the lures before they enter credentials and so they recognize push-fatigue patterns before they tap Approve. The two layers are complementary, not interchangeable. Programs that lean on one and skip the other have demonstrable gaps.

MFA Bypass Phishing: The 5 Attack Patterns That Defeat Multi-Factor Auth

Q: What is AiTM phishing and why is standard MFA defeated?

Adversary-in-the-Middle (AiTM) phishing uses a reverse-proxy site between the user and the real login page. The user enters credentials AND completes the MFA challenge on the proxy; the proxy forwards both to the real service in real time, captures the resulting session cookie and ships it to the attacker. The attacker imports the cookie and is logged in as the user. Standard MFA is defeated because the proxy completes the MFA ceremony on the user's behalf. Phishing-resistant MFA defeats AiTM because the cryptographic challenge is bound to the legitimate origin - a proxy on a different domain cannot complete the challenge.

MFA Bypass Phishing: The 5 Attack Patterns That Defeat Multi-Factor Authentication

"We have MFA, so we're protected from phishing." That sentence was reasonable five years ago. In 2026 it is incomplete in a way that has burned several large incidents into the public record. Standard MFA - SMS codes, TOTP authenticator apps, push approvals - is routinely bypassed by attack patterns that have moved from elite threat-actor capability into commodity tooling. Anyone with a low-cost reverse-proxy phishing kit can defeat the SMS or push MFA most organizations rely on.

This post walks through the five MFA-bypass phishing patterns IT teams need to defend against in 2026, what each one actually does at a technical level and which defenses work for which.

1. Adversary-in-the-Middle (AiTM) reverse-proxy phishing

The biggest shift in the threat landscape since 2022. AiTM uses a reverse-proxy site that sits between the user and the real login page (login.microsoftonline.com, accounts.google.com, your-bank.com, anything). The user enters credentials, completes the MFA challenge - push, TOTP, SMS - on the proxy. The proxy relays the conversation to the real service in real time, captures the resulting session cookie and ships it to the attacker. The attacker imports the cookie and is logged in as the user.

Tools like Evilginx and Caffeine made this attack accessible to anyone who can stand up a domain. The proxy site looks visually identical to the real one because it IS the real one - relayed through.

Why standard MFA fails: the proxy completes the MFA ceremony on the user's behalf in real time. The MFA prompt was satisfied; the cookie is valid.

Defense that works: phishing-resistant MFA (FIDO2 hardware keys, platform passkeys, WebAuthn). The cryptographic challenge is bound to the legitimate origin; a proxy on a different domain cannot complete it. Browser-side, the WebAuthn API checks the origin and refuses to sign for a mismatched domain.

For platform-specific patterns see our M365 phishing defense and Google Workspace phishing defense pieces.

2. OAuth consent grant phishing

An attacker registers an OAuth client (in Microsoft Entra, Google Cloud Console, GitHub, Slack - anywhere with OAuth). They request scopes that grant access to the user's data: read mail, read files, send mail as user. They send the user a link that triggers the legitimate provider's consent screen for that app. The user clicks Allow.

The user never types a password. MFA never prompts. The attacker has refresh tokens that work indefinitely until explicit revocation.

Why MFA fails: no password is involved. The attacker authenticated to the OAuth flow, not to the user's account.

Defense: admin-level restriction of OAuth consent (admin-only consent or verified-publisher allowlist), user training that teaches what the consent screen actually means and audit logging of all granted-scope events for after-the-fact detection.

3. MFA fatigue / push bombing

Attacker has the username and password (from leak, basic phishing or info-stealer malware). They trigger MFA push notifications repeatedly - dozens per minute. The user is in a meeting, picking up groceries, asleep. They eventually tap Approve to make the prompts stop. The attacker is in.

This is the pattern that featured in several published 2022-2024 incidents at large technology companies. The cost to the attacker is near-zero; the cost to the user is irritation that they cure with a tap.

Why MFA fails: the user voluntarily approves. The cryptographic ceremony succeeded.

Defense: number-matching push prompts (user enters a 2-digit code displayed on the login screen rather than just tapping Approve), rate limits on MFA attempts and user training on what push-fatigue patterns look like and how to report them.

4. SIM swap (SMS MFA bypass)

The attacker social-engineers the victim's mobile carrier into porting the phone number to an attacker-controlled SIM. SMS-delivered MFA codes go to the attacker. They reset passwords, complete MFA, take over accounts.

US carrier KYC has improved since 2020 but SIM swap remains practical, particularly for high-value targets where attackers will spend extra effort. Hardly a day passes without a report.

Why SMS-MFA fails: the attacker controls the receiving device.

Defense: stop using SMS as a second factor for any account that matters. TOTP authenticator apps remove the carrier from the trust chain; FIDO2 / passkeys remove the device-channel from it entirely. Major carriers also offer "port-out PIN" / "number lock" features that require a customer-provided PIN before any port - enable them.

5. Session-cookie theft (malware-driven)

Info-stealer malware (RedLine, Vidar, Lumma, etc.) running on a victim's machine extracts session cookies from browser stores. The attacker imports the cookies and is logged in as the user - same effect as AiTM but via endpoint compromise rather than network interception.

Why MFA fails: the session was already authenticated when the cookie was issued. The attacker isn't authenticating; they're impersonating an existing session.

Defense: shorter session lifetimes for sensitive apps, Conditional Access (require compliant device, IP, etc.), endpoint security that catches info-stealers (EDR) and phishing-resistant MFA combined with token binding so cookies are only valid on the device that originally authenticated.

What standard MFA still gets you

Standard MFA hasn't become useless. It still defeats:

Pure password-only credential theft from non-AiTM phishing pages
Credential reuse from non-targeted leaks
Brute-force and password-spray attacks

Those remain the volume majority of attacks. But the loss-per-incident is much higher when an attacker invests in AiTM or consent phish - and those are the attacks that hit when an organization is specifically targeted. The pattern: standard MFA reduces volume; phishing-resistant MFA reduces severity.

The realistic 2026 control stack

The control stack that actually defends against modern MFA-bypass phishing:

Phishing-resistant MFA - FIDO2 hardware keys for high-privilege accounts (admins, finance, executives), platform passkeys for everyone else where supported. Roll out admin-first; expand from there.
OAuth consent restriction - admin-only consent or verified-publisher allowlist on Entra/Workspace; periodic audit of granted apps.
Number-matching push prompts - eliminates the lazy-tap-Approve failure mode of MFA fatigue.
SMS MFA migration - get off SMS for everything that matters; carrier "number lock" PINs for the accounts that can't migrate yet.
Conditional Access / device compliance - only allow sign-in from compliant devices for sensitive apps; reduces session-cookie theft impact.
Continuous phishing simulation training - multi-channel (email + SMS + voice), with templates that include AiTM patterns, consent screens and push-fatigue recognition. Auto-assigned remediation when users fall for any of them.
EDR + token binding - endpoint security to catch info-stealers; token binding so stolen cookies don't replay on attacker devices.

None of these alone is enough. The combination is what defeats modern MFA-bypass phishing.

For cyber insurance and compliance buyers

Cyber insurance carriers increasingly ask whether organizations are using phishing-resistant MFA, particularly for privileged accounts. The cyber-insurer renewal walkthrough covers the broader question set; the MFA-specific bit is now standard. Carriers reading "we have MFA" without specifying type weight that less favorably than carriers reading "we have FIDO2 keys for admins, passkeys for the rest and a documented rollout plan."

For SOC 2 and HIPAA, the same. The control language used to say "MFA"; auditors now ask "what kind."

Where Bait & Phish fits

Bait & Phish ships with template categories that mimic AiTM lures (visually-correct sign-in pages with mismatched URLs), OAuth consent prompt impersonations and push-fatigue simulation patterns. Multi-channel coverage means users encounter the patterns where attackers actually deploy them - email, SMS and voice. Auto-assigned remediation training fires the moment a user fails. Start a free trial up to 25 users and run an MFA-bypass-themed campaign in your environment, or contact us to walk through how the simulation library maps to the five attack patterns above.

This post is informational. Specific FIDO2 / passkey rollout plans and Conditional Access policy decisions are organization-specific - consult your identity and IAM teams for tailored guidance.

See also: Phishing Trends 2026 - annual roundup covering AiTM commoditization, AI-generated lure quality, collaboration-tool phishing, ransomware dwell-time compression and other patterns that defined the year.

4feb