MFA bypass refers to techniques attackers use to circumvent multi-factor authentication controls—including push notification fatigue, adversary-in-the-middle (AiTM) phishing, SIM swapping, session token theft, and token manipulation—without triggering standard authentication failure alerts. Because MFA bypass produces a successful authentication event, log-only monitoring tools can’t detect it.
Key takeaways
- MFA bypass produces a successful authentication event—making it invisible to log-only monitoring tools and SIEM correlation rules built around failure counts
- The five main techniques are push bombing, AiTM phishing, SIM swapping, session hijacking, and token theft and replay—each exploiting a different weakness in the authentication flow
- AiTM phishing is the most consequential: it captures the session token after a legitimate MFA completion, bypassing all TOTP and push-based MFA methods
- ITDR detects MFA bypass not by reading the auth log outcome, but by correlating behavioral signals—impossible travel, new device enrollment, MFA approval sequence anomalies—against per-account baselines
- Phishing-resistant FIDO2 authentication is the only MFA method immune to AiTM phishing; detection remains essential for everything else
MFA bypass is one of the most prevalent initial access techniques in enterprise breaches—and one of the most misunderstood, because it produces a successful authentication event that logs treat as legitimate. For the full taxonomy of identity-based attack types that MFA bypass fits within, see what are identity-based attacks? This page goes deep on MFA bypass specifically: how each technique works, why auth logs can’t detect it, and the behavioral signals that identity threat detection and response (ITDR) uses to catch what log-only monitoring misses.
What are the five main MFA bypass techniques?
MFA bypass isn’t a single technique—it’s a category of attack methods that each exploit a different weakness in the MFA implementation or the authentication flow. The five most prevalent in enterprise environments:
- Push notification fatigue (push bombing)
The attacker has the target’s valid credentials (sourced from phishing or a breach dataset) and triggers repeated MFA push notification requests to the user’s authenticator app—sometimes dozens within minutes, at off-hours, or combined with a spoofed support call claiming the requests are legitimate. The user, exhausted or confused, approves a request. The attacker gains access.
- Adversary-in-the-middle (AiTM) phishing
AiTM infrastructure sits between the user and the legitimate identity provider. The user believes they’re authenticating normally—they receive and approve a real MFA prompt. But the AiTM proxy captures the resulting session token in real time and hands it to the attacker. The MFA check was completed legitimately; the session is now controlled by the attacker. This technique bypasses all TOTP and push-based MFA—only phishing-resistant FIDO2 authentication is immune.
- SIM swapping
The attacker social-engineers a mobile carrier into transferring the target’s phone number to an attacker-controlled SIM card. SMS-based MFA codes now go to the attacker. This technique targets SMS MFA specifically and is most effective against high-value individual targets (executives, IT admins, finance personnel).
- Session hijacking
Rather than bypassing MFA at authentication time, the attacker steals the session cookie or token from an already-authenticated session—through malware on the endpoint, a man-in-the-browser attack, or token exfiltration from browser storage. The stolen token grants access without requiring re-authentication.
- Token theft and replay
Attackers steal OAuth tokens, SAML assertions, or Kerberos tickets using techniques like pass-the-token or through compromised cloud identity systems. These tokens are replayed to authenticate to target systems without triggering a new MFA challenge.
How does AiTM phishing work?
AiTM phishing is the most technically sophisticated—and most consequential—MFA bypass technique currently in widespread use. Understanding the mechanics is essential for detection.
Step 1: Phishing lure delivery
The target receives a phishing email with a link to what appears to be a legitimate login page (Microsoft 365, Okta, Google Workspace). The URL is slightly modified or uses a convincing lookalike domain.
Step 2: Proxy interception
When the target clicks the link, they’re connecting to an attacker-controlled AiTM proxy server—not the real identity provider. The proxy forwards all traffic to the real IdP in real time, acting as a transparent relay.
Step 3: Legitimate authentication
The target sees the real login interface (proxied). They enter their credentials and complete their MFA challenge—push approval, TOTP code, hardware key (for everything except FIDO2). The real IdP receives a legitimate authentication request and issues a valid session token.
Step 4: Token capture
The AiTM proxy intercepts the session token issued by the IdP before passing it to the target’s browser. The target is now authenticated—they see the expected application. The attacker also has a copy of the session token.
Step 5: Session takeover
The attacker injects the stolen session token into their own browser session, gaining access to the application as the authenticated user—without needing credentials or MFA again. The session is valid, authenticated, and indistinguishable from the legitimate user’s session in standard auth logs.
Why do auth logs fail to detect MFA bypass?
This is the core detection problem: MFA bypass produces a successful authentication event. The auth log records exactly what a legitimate login looks like.
For push bombing: the log shows an MFA approval. It was a real approval—the user made it under duress or confusion. The log can’t distinguish coerced approval from voluntary approval.
For AiTM phishing: the log shows a successful authentication from an IP address that resolves to the AiTM proxy infrastructure. Without behavioral context—is this IP associated with a device this account has used before? Is this IP in the expected geographic range for this user?—the event looks normal.
For session hijacking: the stolen token is presented to the application. The application sees a valid, in-policy session token. There’s no new authentication event at all—just continued session activity from an unexpected location or device.
Log-only monitoring tools—including SIEM correlation rules based on authentication event types—can’t surface these attacks because they evaluate the event type (success/failure) rather than the behavioral context (is this normal for this account?). For more on why SIEM has structural limits on identity attack detection, see ITDR vs. SIEM.
What are the ITDR detection signals for MFA bypass?
ITDR detects MFA bypass by correlating authentication success events with behavioral signals that indicate the authentication was anomalous—even if the auth log shows a successful MFA completion.
| Signal | What it indicates | ITDR detection |
|---|---|---|
|
Impossible travel after MFA success |
Authentication from location A, then location B within in impossible timeframe | Flags even when MFA succeeded—AiTM pattern |
|
New device or ASN post-MFA success |
Successful authentication from an unrecognized device or network block | Baseline deviation—first-time device/network for this account |
|
Multiple MFA push rejections followed by approval |
User rejected several requests before approving—classic push bombing pattern | Behavioral anomaly on MFA approval sequence |
| MFA method change | Authentication app swapped, new phone enrolled, backup codes generated | High-signal configuration change—often a precursor to account persistence |
| Session accessed from new geolocation | Post-MFA session activity from location inconsistent with the authentication source | Session token replay indicator |
| MFA enrollment for new account or service principal | New accounts immediately given MFA credentials—shadow admin creation pattern | Behavioral baseline deviation |
| Rapid re-authentication | Multiple authentication events in short succession—brute-force or tool automation pattern | Volume anomaly against per-account baseline |
Expel’s identity threat detection surfaces these signals in real time across cloud IAM, Okta, Azure Entra ID, and SaaS platforms—with 24×7 analyst review for confirmed MFA bypass events.
How can organizations prevent MFA bypass?
Detection is essential—but prevention reduces the attack surface. The layered approach:
Phishing-resistant MFA (FIDO2/WebAuthn): FIDO2 hardware security keys (YubiKey, Titan Key) and platform authenticators (Windows Hello, Touch ID) are the only MFA methods immune to AiTM phishing. FIDO2 authentication is cryptographically bound to the origin domain—a proxy can’t intercept it. For high-risk accounts (privileged admins, executives, finance personnel), FIDO2 is the strongest available control.
Conditional access policies: Enforce that MFA alone is insufficient for sensitive access—require compliant device status, managed device enrollment, or named location restrictions. This raises the bar for session token replay attacks, which can’t satisfy device compliance requirements.
Session controls and token lifetime limits: Short-lived tokens and continuous access evaluation (available in Microsoft Entra and Okta) reduce the window of value from a stolen session token. A token that expires in 15 minutes limits attacker dwell time even after successful session hijacking.
MFA configuration monitoring: Alert on MFA method changes, new authenticator enrollment, and backup code generation—especially for privileged accounts. These events frequently precede or follow an MFA bypass attack as attackers establish persistence.
User awareness—but not as a primary control: Training users to reject unexpected MFA push requests helps reduce push bombing success rates. It’s not a reliable primary control—it depends on user judgment under pressure. Phishing-resistant MFA is the correct primary prevention.
Expel’s take
In 2025, nearly half of all identity incidents Expel’s SOC investigated resulted in successful account takeover—attackers got in despite MFA being in place. The reason MFA bypass is so effective isn’t a technical failure; it’s a detection architecture problem. Auth logs record the outcome (success or failure), not the behavioral context—push bombing produces an approval, and AiTM phishing produces a legitimate MFA completion with a session token the attacker already has a copy of. The log looks identical to a normal login. Catching it requires behavioral baselines per identity, not just log analysis.
Frequently asked questions
What are the most common MFA bypass techniques?
The five most prevalent MFA bypass techniques are: push notification fatigue (push bombing), adversary-in-the-middle (AiTM) phishing that intercepts session tokens, SIM swapping targeting SMS-based MFA, session hijacking through stolen cookies or tokens, and token theft and replay using OAuth tokens, SAML assertions, or Kerberos tickets.
How does AiTM phishing bypass MFA?
AiTM phishing uses a proxy server positioned between the target and the real identity provider. The user authenticates normally and completes their MFA challenge—but the proxy intercepts the resulting session token before passing it to the user’s browser. The attacker uses the stolen token to access the account without needing credentials or MFA again.
Why can’t auth logs detect MFA bypass?
Auth logs record the authentication outcome—success or failure. MFA bypass techniques like push bombing and AiTM phishing produce successful authentication events that are indistinguishable from legitimate logins in the log. Detecting them requires behavioral context: is this device recognized? Is this location consistent with the account’s history? Does the MFA approval sequence look normal? Auth logs record events; ITDR interprets behavior.
What detection signals indicate MFA bypass?
Key ITDR detection signals include: impossible travel after a successful MFA event, successful authentication from a new unrecognized device or network, multiple MFA push rejections followed by an approval, MFA configuration changes (new authenticator enrollment, method changes), and session activity from a geolocation inconsistent with the authentication source.
What is the best way to prevent MFA bypass?
Phishing-resistant FIDO2 authentication (hardware security keys or platform authenticators) is the only MFA method immune to AiTM phishing. Complement it with conditional access policies, short session token lifetimes, MFA configuration monitoring, and ITDR behavioral detection for attacks that still succeed.