PhiShark Logo
Back to blog
Phishing DefenseJune 12, 20266 min readPhiShark Team

MFA Is Not a Wall: How Fatigue Bombing and AiTM Bypass 2FA in 2026

Multi-factor authentication is treated as the finish line of identity security. In 2026, MFA fatigue bombing and Adversary-in-the-Middle session cookie theft turn that assumption inside out. Here's how the bypasses work and what defends them.

MFA BypassAiTMMFA FatigueSession HijackingPhishing Defense2026

"Enable MFA and you are done." That sentence has been the closing line of security awareness training for nearly a decade. In 2026, it is also one of the most dangerous things a security program can believe. Multi-factor authentication is a control, not a conclusion. Two specific techniques - MFA fatigue bombing and Adversary-in-the-Middle (AiTM) session theft - have matured to the point where MFA alone no longer stops a determined attacker. They do not break the cryptographic second factor. They route around it.

The two bypasses every team should understand

These are not theoretical. Both appear regularly in incident response engagements through 2025 and into 2026, and both defeat organizations whose only identity control is MFA on top of a password.

MFA fatigue bombing (push-bombing)

Modern MFA is overwhelmingly push-based. A user authenticates with a password, the identity provider sends a push notification to a registered device, and the user approves. The security model assumes the approval is a deliberate, attentive act.

Fatigue bombing shatters that assumption. The attacker has the password (bought from a stealer log, leaked in a breach, or phished) and spams the victim with approval requests - tens or hundreds in a row, often at 3 AM. Users, groggy and annoyed, tap "Approve" to make the buzzing stop. The approval is real. The authentication succeeds. The second factor was technically present.

What makes this effective in 2026 is the combination of number-matching evasion and notification fatigue. Early defenses added number-matching prompts ("approve only if you see 4823"), but attackers operating in real time through phishing proxies can present the matching number to the user as part of their cloned login flow, eliminating the protection the prompt was supposed to provide.

Adversary-in-the-Middle (AiTM) session theft

AiTM is the more insidious bypass because it defeats even MFA methods that were supposed to be phishing-resistant.

The attacker stands up a phishing page that does not just collect credentials - it relays them, in real time, to the legitimate identity provider. When the user types their password, it is forwarded and entered into the real login. When the provider issues the MFA challenge, the attacker forwards it to the user. When the user completes the MFA, the attacker replays it. The legitimate service is satisfied, and crucially, hands back a session cookie. That session cookie is captured by the proxy - not the user's browser - and from that moment on the attacker has an authenticated session without needing the password or the second factor ever again.

The credential and the second factor were both used. They just were used by the attacker, through the user, against the real service. The MFA "worked." The account is still compromised.

Why traditional defenses miss these attacks

The reason these bypasses succeed at scale is that the most common identity protections were not designed for them.

Email filters do not see the relay

AiTM kits are frequently distributed as phishing links that look like ordinary Microsoft 365 or Okta login URLs. A secure email gateway scanning the link at delivery time sees a freshly registered domain and, depending on configuration, either blocks it (helpful, when it happens) or passes it because the page has not yet been classified. Many AiTM kits rotate domains hourly, so a reputation check that returns "unknown" is not equivalent to "safe."

The MFA approval itself looks legitimate

For fatigue bombing, every signal an identity provider logs says the authentication was legitimate. The right password. The right device. An approval event. The only anomaly - a burst of approval requests - is rarely alerted on by default. Teams discover the compromise hours or days later when the attacker starts creating forwarding rules or exfiltrating data.

EDR is not the threat surface

Endpoint detection focuses on the device. AiTM and fatigue attacks compromise an identity, not a laptop. The attacker uses a valid session from an unknown IP, an unknown geography, sometimes an unknown browser. Device-based controls have nothing to grip.

What actually defends against MFA bypasses

There is no single setting that neutralizes both attacks. Effective defense is layered, and each layer addresses a specific failure mode of password-plus-MFA.

Require phishing-resistant MFA

Not all second factors are equal. Push approvals, OTP codes delivered by SMS, and time-based codes shown on a screen can all be relayed or replayed. Phishing-resistant methods - FIDO2 security keys, passkeys backed by hardware, device-bound credentials - cryptographically bind the authentication to the legitimate origin. An AiTM proxy cannot relay a FIDO2 assertion because the authenticator refuses to sign it for a domain it does not recognize. This is the single most impactful control, but adoption lags because it touches user experience and device inventory.

Detect the fatigue pattern

For push-based MFA you cannot yet replace, detect bom-burst behavior: more than N approvals in a window, an approval originating from a sequence of rapid declines, approvals at unusual hours, or approvals following a credentials-leak indicator. These signals are present in identity logs already. Alerting on them turns a successful compromise into a caught one.

Block the landing page at the browser

AiTM requires the victim to load the proxy. If the browser refuses to load the page, the relay never starts. This is where browser-native, real-time page analysis matters: detecting brand impersonation, recognizing credential-collection flows, and blocking the destination before the user types anything. The PhiShark Browser Extension does exactly this at load time.

Treat session cookies as the real perimeter

If the credential and the second factor can both be relayed, the session cookie is the true boundary. Monitor sessions, enforce conditional access on session origin, and shorten session lifetimes for high-risk contexts. A stolen cookie invalidates itself within minutes if the lifetime is short and the access policy re-evaluates the origin.

Correlate across signals with evidence

A single MFA approval at 3 AM might be noise. The same approval followed by a login from a new country an hour later, followed by a mailbox-rule creation, is a complete attack chain. Agentic AI that correlates signals and explains the reasoning is what turns raw telemetry into a defendable decision. This is precisely the role of PhiShark AIPA in incident workflows - surfacing not just the alert but the evidence behind it.

What this means for security teams

If MFA is the last line of identity defense, MFA bypass is the last word on whether identity is secured. The teams that hold the line in 2026 are the ones who stopped treating MFA as a finish line.

  • MFA is a control, not a conclusion. The question is whether your second factor is phishing-resistant.
  • Push approvals are the soft target. Without fatigue-pattern detection and number-match integrity, push is bypassable by annoyance alone.
  • AiTM steals the session, not the password. Identity perimeter shifts from credentials to sessions; protect and monitor them accordingly.
  • The browser is the gate to the relay. Block the proxy before the user types, and the AiTM chain never starts.
  • Evidence-based correlation beats isolated alerts. A 3 AM approval is nothing; a 3 AM approval plus cookie replay plus new geography is an attack.

MFA did not fail. The assumption that it is enough did.

The second factor still does what it was designed to do. What changed in 2026 is that attackers stopped trying to defeat the cryptography and started defeating the human and the relay around it. The fix is not a better password. It is phishing-resistant authentication, session-aware monitoring, and browser-level blocking of the pages built to harvest consent.

See how PhiShark closes the AiTM and fatigue-bombing gaps - explore the platform and put evidence-based, browser-native phishing defense where your identity perimeter actually lives.

Want to go deeper? Browse our blog for more phishing defense analysis, or visit the glossary for definitions of key phishing and cybersecurity terms.