What MFA Actually Protects Against
MFA is genuinely effective against a specific and important class of attacks: credential stuffing, password spraying, and brute-force attacks where the attacker has a valid password but not a second factor. Microsoft's own data suggests that MFA blocks approximately 99.9% of automated account takeover attempts that rely on compromised passwords alone.
That statistic is real and meaningful. Before MFA, a list of leaked passwords from a data breach was a direct path to account access. With MFA, that same list becomes far less dangerous because the attacker also needs the second factor. This is why MFA adoption is important — it eliminates the easiest attack path entirely.
But "blocks 99.9% of password-based attacks" is not the same as "blocks 99.9% of account takeover attempts." It's a narrower claim. The attackers who have adapted to widespread MFA adoption are not trying to bypass the 99.9% — they've moved on to the 0.1% of cases where the specific attack technique doesn't care about your MFA at all.
MFA Bypass Technique 1: MFA Fatigue / Push Bombing
MFA fatigue exploits the human element of push notification-based MFA — specifically, the fact that a user who receives enough push notifications will eventually approve one just to make them stop.
An 18-year-old attacker obtained the credentials of an Uber contractor, then bombarded that contractor's phone with MFA push notifications for over an hour. When the contractor didn't respond, the attacker sent a WhatsApp message claiming to be from Uber IT support, saying the MFA requests would stop once the contractor approved one. The contractor approved. The attacker was in. Within hours, they had accessed Uber's internal tools, Slack workspace, HackerOne vulnerability reports, AWS environment, and internal documentation. The entire breach began with a single approved MFA push. Uber's entire identity stack — including MFA — was rendered irrelevant by social engineering a single tired human into one tap.
The technical countermeasures to MFA fatigue are now well-established: number matching (requiring the user to enter a number displayed on the login screen into the MFA app, making accidental approval impossible) and additional context in push notifications (showing the application being accessed and the sign-in location). Microsoft Authenticator and Duo both support these controls. If you're using push-based MFA without number matching enabled, you're vulnerable to this attack.
Detection: Entra ID and Okta both log MFA push denials. A pattern of multiple denials followed by a successful authentication from the same user in a short window is an MFA fatigue attack. This should generate a high-priority alert and an immediate verification call to the user.
MFA Bypass Technique 2: Adversary-in-the-Middle (AiTM) Phishing
AiTM phishing with toolkits like Evilginx2, Modlishka, and Muraena represents the most technically sophisticated MFA bypass technique in common use. Rather than trying to compromise the authentication process directly, the attacker inserts a transparent proxy between the user and the legitimate service.
The attack flow works like this: the victim receives a convincing phishing email with a link to what appears to be a Microsoft 365 or Okta login page. The URL is a lookalike domain, but the page is a perfect visual replica because the attacker's proxy is fetching the real login page and relaying it to the victim in real time. The victim enters their username and password — the attacker captures those credentials. The victim then receives a legitimate MFA prompt — which the attacker's proxy also relays to the real service. The victim approves the MFA. Authentication succeeds.
At this point, the attacker's proxy captures the authenticated session cookie — the proof of a successful authentication that the browser sends on every subsequent request. The attacker now has a valid, authenticated session cookie for the victim's account. They inject this cookie into their own browser and have full access, without needing the password or the second factor, because the session already has both.
MFA itself cannot detect this attack because from the authentication system's perspective, the right credentials and the right MFA response were provided. Detection requires behavioral analysis of what happens after authentication: sign-ins from unexpected geographic locations or IP addresses immediately followed by high-risk actions, session tokens being used from IP addresses different from the authentication source, or accessing sensitive resources at unusual hours.
MFA Bypass Technique 3: Session Token Theft
Session token theft is conceptually simpler than AiTM but equally effective. After a user successfully authenticates with MFA, their browser stores a session token — a cryptographic credential that proves they've already authenticated, so they don't have to enter credentials on every page load.
Attackers steal session tokens through several mechanisms: malicious browser extensions that have access to cookie storage, JavaScript-based credential theft from compromised websites, endpoint malware that reads the browser's cookie database directly from disk, or by compromising a device through a different vector and extracting tokens from the running browser process.
Once an attacker has a valid session token for a high-value application — Microsoft 365, AWS console, Okta, Salesforce — they have authenticated access for the lifetime of that token without ever needing to go through authentication or MFA again. Depending on the application, tokens may be valid for hours, days, or indefinitely until explicitly revoked.
Detecting Session Token Theft
The primary behavioral signal for session token theft is a session being used from an IP address or geographic location inconsistent with the authentication event that created it. The user authenticated from a London corporate IP but subsequent requests in the same session are coming from a Netherlands residential ISP — that's token theft in action.
Conditional Access policies with continuous access evaluation (in Entra ID) and session binding can mitigate some token theft scenarios by re-evaluating access conditions on every API call rather than only at authentication time.
MFA Bypass Technique 4: SIM Swapping
SIM swapping attacks target SMS-based MFA specifically — the most common MFA implementation despite being the weakest. The attacker calls the victim's mobile carrier, impersonating the victim, and convinces the carrier to transfer the victim's phone number to a SIM card the attacker controls. From that moment, any SMS OTP sent to the victim's number goes to the attacker instead.
High-profile SIM swap attacks have targeted cryptocurrency exchanges, executives, and public figures. The technique requires social engineering a mobile carrier's customer service representative, which varies in difficulty depending on the carrier's identity verification procedures. Some carriers have very poor controls; others require in-store ID verification for SIM transfers.
The security community's response: stop using SMS-based MFA for any high-value accounts. SMS OTP is better than no MFA, but it should be considered the floor of acceptable MFA security, not the target. TOTP-based authenticators (Google Authenticator, Microsoft Authenticator in TOTP mode) are not vulnerable to SIM swapping because the OTP is generated locally, not received via SMS.
MFA Bypass Technique 5: Legacy Authentication Protocols
The simplest MFA bypass doesn't require sophisticated technology at all — it requires knowledge that legacy protocols exist. SMTP AUTH, IMAP, POP3, and Exchange ActiveSync are email protocols that predate MFA. When a client authenticates using these protocols, it uses username and password directly. MFA is not in the flow.
If your Microsoft 365 tenant allows legacy authentication (many older tenants do, to support legacy email clients), and an attacker has a valid username and password for any account, they can authenticate via IMAP with just those credentials regardless of MFA settings. Microsoft has been deprecating legacy authentication since 2021, but many organizations still have it partially enabled to support legacy applications or devices they haven't migrated.
Detection: Any successful authentication using a legacy protocol for an account that normally uses modern authentication is a high-confidence attack indicator. Entra ID sign-in logs include the clientAppUsed field, which identifies the authentication protocol. Block it at the Conditional Access layer where possible.
What Comes After MFA: A Defense-in-Depth Identity Strategy
The answer to MFA's limitations is not to abandon MFA — it's to stop treating MFA as the final defense and layer additional controls that detect post-MFA compromise:
- Upgrade MFA to phishing-resistant methods: FIDO2/WebAuthn hardware keys or passkeys are bound to the specific origin (domain) of the authenticating service. An AiTM proxy operating on a lookalike domain cannot relay a FIDO2 authentication because the origin check fails. This is the only MFA method that is genuinely resistant to AiTM phishing.
- Implement number matching on push notifications: Eliminates MFA fatigue attacks entirely. Should be enabled for all users today — it's a configuration change in your MFA platform, not a deployment project.
- Enable Conditional Access with continuous evaluation: Rather than evaluating access conditions only at authentication, continuous evaluation re-checks conditions on every resource access request — detecting mid-session anomalies like IP address changes that indicate session token theft.
- Behavioral analytics as the layer that can't be bypassed: An attacker who has successfully bypassed MFA will still behave differently from the legitimate user. They'll access different resources, at different times, from different locations, in different sequences. This is where behavioral detection catches what authentication gates miss.
Behavioral Analytics as the Identity Layer That Can't Be Bypassed
Behavioral analytics operates on a fundamentally different principle from authentication. Instead of asking "did you prove you're who you say you are at login time?", it continuously asks "are you behaving the way this user normally behaves?"
An attacker who has bypassed MFA — through AiTM phishing, session token theft, SIM swapping, or any other technique — now has a valid authenticated session. But they still have to do something with that access. They need to read specific emails, download specific files, modify specific configurations, or add specific accounts. And the sequence, timing, volume, and target of those actions will differ from the legitimate user's normal patterns.
ZonForge Sentinel builds per-user behavioral baselines across all connected identity sources — Entra ID, Okta, M365 activity, AWS IAM, application access logs — and detects deviations that suggest the authenticated session is being used by someone other than the account owner. This detection fires after authentication has succeeded, which is exactly where authentication-layer controls have nothing left to offer.
Phishing-Resistant MFA: FIDO2/WebAuthn
FIDO2 and WebAuthn represent the current gold standard for MFA security. The key property that makes them phishing-resistant is origin binding: the cryptographic credential used during authentication is bound to the specific domain of the service being authenticated to. The credential cannot be used on any other domain — including AiTM phishing lookalike domains.
Hardware security keys (YubiKey, Google Titan Key) implement FIDO2 in a tamper-resistant hardware form factor. Passkeys implement the same FIDO2 standard in software, using device biometrics or PIN as the second factor — making them deployable to every user without specialized hardware.
The practical challenge with FIDO2 rollout is legacy application support. Not all enterprise applications support WebAuthn yet. A phased approach — FIDO2 for all privileged and high-risk users first, followed by gradual rollout to the full user population as application support improves — is more achievable than a big-bang deployment.
How ZonForge Sentinel Detects Post-MFA Identity Attacks
ZonForge Sentinel's identity threat detection layer is designed specifically for the attack scenarios MFA cannot stop. The platform ingests sign-in logs from Entra ID and Okta in near-real-time, applying both rule-based detections (MFA push spray patterns, legacy authentication events, impossible travel) and behavioral baselining (per-user access patterns, resource access sequences, session characteristics).
When an AiTM attack succeeds and an attacker begins using a stolen session, ZonForge Sentinel detects the behavioral divergence — the session that authenticated from a known corporate IP address but is now making requests from an Eastern European data center, accessing resources the user has never touched, downloading volumes of data inconsistent with normal behavior. The authentication event said "valid." The behavior says "attacker."
The combination of authentication layer signals (MFA anomalies, impossible travel, legacy auth) with post-authentication behavioral signals (session anomalies, access pattern deviations, bulk resource access) gives security teams detection coverage across the full identity attack lifecycle — not just at the authentication gate.
Conclusion: MFA Is Necessary but No Longer Sufficient
MFA is not going away, and it shouldn't — it still blocks the vast majority of automated credential attacks. But treating MFA as a complete identity security solution is a dangerous oversimplification. Modern adversaries have adapted. MFA fatigue, AiTM phishing, session token theft, SIM swapping, and legacy authentication bypasses are all operational techniques in active use.
The MFA security limitations problem resolves when you treat MFA as one layer in a defense-in-depth identity strategy: upgrade to phishing-resistant FIDO2/WebAuthn for privileged users, enable number matching on push MFA for everyone else, block legacy authentication at the Conditional Access layer, and deploy behavioral analytics that detect the post-MFA activity patterns that indicate compromise regardless of how authentication was bypassed.
ZonForge Sentinel provides the behavioral analytics layer that catches what authentication gates cannot. If your current security posture stops at MFA, you have a gap — and sophisticated attackers know exactly where it is.
Frequently Asked Questions
MFA fatigue (also called push bombing) is an attack where an adversary repeatedly sends MFA push notification requests to a victim's device — sometimes dozens or hundreds over hours — hoping the victim will eventually approve one to stop the notifications. The attack exploits the human tendency to approve unexpected prompts under conditions of stress or annoyance, particularly when accompanied by social engineering (a call or message claiming to be IT support). Countermeasures include enabling number matching on push MFA, which requires the user to enter a code from the login screen rather than simply tapping "approve."
Adversary-in-the-Middle (AiTM) phishing uses a reverse proxy placed between the victim and the legitimate authentication service. The victim visits what appears to be a normal login page, enters their credentials and MFA code — which are relayed to the real service by the proxy — and the authentication succeeds. The proxy captures the authenticated session cookie, which the attacker then uses to access the account without needing credentials or MFA. Toolkits like Evilginx2 automate this attack. The only reliable defense is phishing-resistant MFA (FIDO2/WebAuthn), which is cryptographically bound to the legitimate domain and cannot be relayed by a proxy on a different domain.
Phishing-resistant MFA refers to authentication methods that cannot be captured and replayed by an adversary on a different domain. The primary standard is FIDO2/WebAuthn, implemented as hardware security keys (YubiKey, Google Titan) or passkeys on modern devices. FIDO2 authentication is cryptographically bound to the specific origin (domain) of the authenticating service — a credential registered for login.microsoftonline.com cannot be used on a phishing domain like login.micros0ftonline.com. CISA recommends FIDO2 as the only category of MFA that is genuinely phishing-resistant; push notification MFA and TOTP codes can both be intercepted by AiTM proxies.
MFA bypass detection requires monitoring at two levels. At the authentication layer: alert on patterns of multiple MFA push denials followed by success (fatigue attack), impossible travel between authentication events, successful authentications using legacy protocols, and sign-ins from high-risk IP addresses or anonymizing proxies. At the behavioral layer: detect post-authentication anomalies like sessions used from unexpected geolocations (token theft), access to resources the user has never accessed, bulk data downloads inconsistent with normal behavior, and admin actions at unusual hours. Authentication-layer signals catch some bypass attempts at the moment of compromise; behavioral signals catch the ones that get through authentication successfully.
Yes, significantly so. TOTP (Time-based One-Time Password) codes generated by authenticator apps like Google Authenticator, Microsoft Authenticator, or Authy are generated locally on the device using a shared secret established during setup. They cannot be intercepted through SIM swapping because they're never transmitted over the phone network. SMS OTPs, by contrast, are transmitted to the phone number over the cellular network — meaning a SIM swap attack or SS7 protocol interception can redirect them to an attacker. That said, TOTP codes can still be captured by AiTM phishing proxies that relay them in real time. Both TOTP and SMS MFA are inferior to FIDO2 for high-value accounts.