Authentication Attacks: Phishing, MFA Fatigue, and Token Theft

MFA blocks the overwhelming majority of automated, opportunistic account-compromise attempts — but a targeted attacker isn't trying to guess a password anymore. Modern authentication attacks are specifically designed to work around MFA, not through it. This article covers how the most common bypass techniques actually work, and which controls genuinely stop each one, as opposed to controls that only look like they help.

Why "we have MFA" stopped being a complete answer

Standard code-based MFA (SMS, authenticator app codes, basic push approval) protects against credential theft alone — an attacker who steals just a password can't get in without the second factor. But none of these methods verify where the authentication is actually happening. That gap is exactly what the attack techniques below exploit.

Adversary-in-the-middle (AiTM) phishing

An adversary-in-the-middle attack uses a proxy server sitting between the victim and the real login page. The victim visits what looks like a normal login page — because it's relaying, in real time, the actual content from the real service. When the victim enters their password and MFA code, the proxy captures both and immediately relays them to the real service, completing a genuine login. Critically, the proxy also captures the session token issued after that successful login — which means the attacker doesn't just get credentials, they get an active, already-authenticated session.

Evilginx and phishing-as-a-service kits

Evilginx is one of several widely available open-source and commercial phishing frameworks that automate adversary-in-the-middle attacks — packaging the reverse-proxy technique above into a point-and-click toolkit. Its wide availability is part of why AiTM phishing has become common even against organizations without a sophisticated, resourced attacker: the technical barrier to running this style of attack has dropped substantially. This is directly relevant for defenders, because it means "we're not a high-value enough target for this" is no longer a safe assumption.

MFA fatigue (push bombing)

MFA fatigue targets push-notification MFA specifically. Instead of trying to steal a code, the attacker — who already has a valid password, typically from a breach or phishing — repeatedly triggers push notification prompts on the victim's device, hoping the victim eventually approves one out of frustration, confusion, or the assumption that a system glitch is causing repeated prompts. No credential theft beyond the original password is needed; the attack works purely on prompting fatigue.

Session hijacking and token theft

Once a user is authenticated, most modern applications issue a session token so the user isn't forced to re-authenticate on every request. If an attacker obtains that token — via the AiTM relay described above, via malware on the victim's device, or via an insecurely stored token — they can often use it directly to impersonate an active session, bypassing authentication entirely because, from the application's perspective, the session is already legitimately authenticated.

Detection

• Sign-in risk detection (e.g., Microsoft Entra ID Protection) flags anomalies — impossible travel, unfamiliar sign-in properties, known-malicious IP ranges — that a stolen token or credential often triggers even when the credential itself was valid.
• Token/session anomaly monitoring — a session token suddenly used from a different device fingerprint or location than where it was issued is a strong compromise signal.
• Conditional Access sign-in logs, reviewed for unexpected patterns, particularly around MFA prompt frequency (a spike in prompts to one user is a fatigue-attack indicator) and legacy authentication attempts.
• User reporting culture — a user who mentions "I kept getting MFA prompts I didn't request" is reporting a real MFA fatigue attempt; this needs to be treated as an actionable signal, not dismissed as an annoyance.

Mitigation

1. Move high-value accounts to phishing-resistant MFA (hardware key or passkey). This is the single most effective control against AiTM phishing specifically, because the cryptographic binding to the real domain makes the relay technique structurally unable to succeed — see Passwordless Authentication and Passkeys.
2. Enable number-matching on push-based MFA to close the fatigue-attack path for any accounts not yet on phishing-resistant methods.
3. Shorten session token lifetimes and require periodic re-authentication for sensitive applications via Conditional Access session controls, limiting the window a stolen token remains useful.
4. Require compliant/managed devices via Conditional Access for sensitive access, since a token stolen via malware on an unmanaged device is less useful if a compliant-device requirement is also enforced.
5. Enable sign-in risk-based Conditional Access policies, automatically requiring additional verification or blocking access when a sign-in shows anomalous risk signals.
6. Train staff to recognize and report repeated, unrequested MFA prompts immediately, and treat a reported pattern as an active incident, not routine noise.

Common mistakes

• Treating "we have MFA" as sufficient without considering method strength. Code-based MFA meaningfully raises the bar over no MFA but does not stop AiTM phishing or MFA fatigue.
• Bare push-notification approval without number-matching. This is the most exploitable form of push MFA and should be reconfigured as a priority, not left as-is.
• No session lifetime limits on sensitive applications, leaving a stolen token useful for an extended period.
• Dismissing user reports of unexpected MFA prompts as user confusion rather than treating them as a likely active attack signal.

FAQ

If phishing-resistant MFA stops AiTM phishing, why isn't it universal yet? Deployment cost and device support are real constraints — hardware keys need to be procured and distributed, and not every application or legacy system supports passkey/FIDO2 authentication yet. The practical answer is prioritizing phishing-resistant methods for the highest-risk accounts first, per Multi-Factor Authentication: Methods and Best Practices.

Can a stolen session token be used even after the user changes their password? Often yes, at least until the token naturally expires or is explicitly revoked — changing a password does not automatically invalidate every existing session token on every platform. This is exactly why session lifetime limits and explicit session revocation (as part of incident response) both matter independently of password rotation.

Is MFA fatigue only a risk for push-notification MFA? Yes, specifically — it targets the bare approve/deny interaction pattern. Code-based methods (typing a code) and phishing-resistant methods (hardware key, passkey) aren't vulnerable to this particular technique, though each has its own separate weaknesses covered above.

Are these attacks only a concern for large enterprises? No — phishing-as-a-service kits like Evilginx have significantly lowered the resource and skill required to run an AiTM campaign, making these techniques accessible against organizations of any size, not just high-profile targets.

Related reading

• Multi-Factor Authentication: Methods and Best Practices
• Passwordless Authentication and Passkeys
• Microsoft Entra Conditional Access: A Practical Guide
• Ransomware Recovery Planning — what to do if a credential compromise like this leads to a ransomware event
• Download: MFA Rollout Checklist