MFA fatigue attacks and session hijacking are why “we have MFA” is no longer a complete answer. Attackers push-bomb users into approving a login, stand up adversary-in-the-middle (AiTM) kits to steal cookies, or replay refresh tokens—then operate as the user. ITDR is how you detect and respond when authentication succeeds for the wrong person.
This threat guide covers how fatigue, AiTM, and cookie/token theft work—and how to detect, contain, and harden with identity-focused controls.
This guide covers:
- How MFA push bombing and AiTM session theft typically unfold
- ITDR detection signals worth alerting on
- Containment: revoke sessions/tokens, reset authenticators, notify
- Hardening: number matching, phishing-resistant MFA, shorter sessions
- How SecureSlate helps evidence MFA and IR controls
GIF via GIPHY
Related guides:
- Bypassing MFA: biggest breaches and lessons
- Identity incident response playbook (ITDR)
- Identity-based attack detection playbook
- What is ITDR? Identity threat detection and response
- SOC 2 password requirements: how to stay compliant
Key takeaways
- MFA fatigue succeeds socially—volume of push prompts is a detection signal, not just a user annoyance.
- AiTM steals the session after MFA—cookie/token theft may look like a normal sign-in.
- ITDR response is revoke-centric—kill sessions and refresh tokens before the postmortem.
- Phishing-resistant MFA (passkeys/FIDO2) typically reduces both fatigue and AiTM success paths.
- Train for “deny and report”—users need a safe channel when prompts arrive unexpectedly.
Threat overview: fatigue, AiTM, session theft
| Technique | What the attacker needs | What success looks like | Why classic MFA fails |
|---|---|---|---|
| MFA fatigue / push bombing | Valid password + push MFA enabled | User finally taps Approve | MFA becomes a notification, not a decision |
| Adversary-in-the-middle (AiTM) | Phishing proxy in front of real IdP | Attacker captures password + session cookie | MFA completed against attacker relay |
| Cookie / refresh token theft | Malware, XSS, proxy, or device access | Replay of session without new MFA | Session outlives the login ceremony |
| Session hijacking via sync / device | Access to browser profile or token store | Silent reuse of existing session | No new auth event to catch |
For broader MFA bypass case lessons, see bypassing MFA: biggest breaches and lessons. Detection patterns fit the identity-based attack detection playbook.
MFA fatigue and push bombing
How it typically works
- Attacker obtains a password (phish, spray, leak, purchase).
- Attacker initiates many sign-in attempts that trigger push MFA.
- User is flooded—often at night or during busy work—and eventually approves.
- Attacker lands a valid session and moves into email, VPN, or admin portals.
User and helpdesk tells
- “I got dozens of MFA prompts I didn’t start”
- Helpdesk calls claiming “IT needs you to approve the push”
- Prompt storms followed by a successful auth from a new geo/ASN
Control weaknesses that enable fatigue
- Push MFA without number matching or challenge codes
- No rate limits / risk blocks on repeated MFA failures
- No user education to report unexpected prompts
- Privileged users on the same weak push method as standard users
Adversary-in-the-middle and session theft
AiTM kits sit between the user and the real IdP:
- User is phished to a lookalike login URL.
- Credentials and MFA responses are relayed to the real service.
- Attacker captures the session cookie / token.
- Attacker replays the session from their infrastructure—often without another MFA prompt.
Session hijacking ITDR therefore watches post-auth behavior, not only failed logins:
- New session followed by impossible travel or ASN change mid-session
- Token refresh patterns inconsistent with the user’s device
- Mailbox rule creation or OAuth grant immediately after first-seen session
- Privileged app access from a session that originated via a risky referrer or atypical client
Cookie theft via malware or stolen browser profiles may produce similar “valid session, wrong context” signals.
Detection signals for ITDR
| Signal | Points to | Suggested severity |
|---|---|---|
| High volume of MFA denies/timeouts then success | Fatigue | High / critical if privileged |
| MFA prompts outside user’s normal hours + success | Fatigue | High |
| Sign-in success from new ASN immediately after phish report | AiTM / phish | High |
| Session continues after password reset (token not revoked) | Session persistence gap | Critical (process failure) |
| Concurrent sessions far apart without VPN explanation | Hijack / shared creds | High |
| New inbox rule + new session same hour | Mailbox takeover | High |
| OAuth high-scope grant after suspicious auth | Persistence | High / critical |
| Privileged portal access from unmanaged device first seen | Session risk | High |
Tune carefully: travel and shared NAT can look like impossible travel. Enrich with HR travel, MDM posture, and ticket context.
Response playbook (contain and revoke)
When fatigue or hijacking is suspected, follow the identity incident response playbook:
- Contain — block sign-in / disable account if confirmed; at minimum elevate risk and require re-auth.
- Revoke — all sessions, refresh tokens, and app grants for the identity.
- Reset authenticators — remove push devices that may have been social-engineered; prefer phishing-resistant re-enrollment for privileged users.
- Hunt — mailbox rules, forwarding, OAuth apps, recent role changes, API keys created in the window.
- Notify — user (verified channel), manager, GRC/Legal as severity warrants.
- Document — timestamps for MTTD/MTTC and auditor evidence.
| Step | Fatigue-focused action | AiTM / cookie theft action |
|---|---|---|
| User contact | “Deny all unexpected pushes; report storms” | “Assume link was fake; do not reuse password elsewhere” |
| IdP | Revoke sessions; review MFA method changes | Revoke sessions/cookies; invalidate refresh tokens |
| Check rules/forwarding | Same + search for phish that introduced AiTM | |
| Hardening follow-up | Number matching / passkeys | Passkeys + shorter session lifetimes |
Do not leave “sessions alive until the user changes password tomorrow.” Token lifetime is the attacker’s window.
Defenses that actually reduce risk
Reduce MFA fatigue success
- Enable number matching or challenge codes on push MFA
- Rate-limit / lock out after repeated MFA failures where the IdP allows
- Prefer phishing-resistant MFA (FIDO2/passkeys) for admins and high-risk roles
- Train users: unexpected push = deny + report, never approve to “make it stop”
- Ban helpdesk scripts that ask users to approve MFA on behalf of callers
Reduce AiTM and session hijacking
- Phishing-resistant MFA (AiTM cannot easily relay WebAuthn)
- Shorten session and refresh token lifetimes for privileged apps
- Continuous access evaluation / risk-based re-auth on unusual session context
- Device compliance requirements for sensitive apps
- Monitor and alert on new OAuth grants and inbox rules
- Email security controls that catch AiTM phishing kits early
Password policy still matters for the initial secret—see SOC 2 password requirements—but session security is what stops post-MFA abuse.
Tabletop and metrics
| Exercise | Inject | Pass criteria |
|---|---|---|
| Push bombing | 50 MFA denies then success on exec account | Account contained; sessions revoked < 30–60 min; user interviewed |
| AiTM phish | User reports lookalike login; session appears from new ASN | Tokens revoked; mailbox hunted; passkey enrollment planned |
| Cookie replay | Valid session, no new MFA, anomalous actions | Session killed; device investigation started |
Track:
- Count of MFA fatigue incidents per quarter
- MTTD/MTTC for fatigue and AiTM classes (ITDR metrics guide)
- % of privileged users on phishing-resistant MFA
- User report rate for unexpected MFA prompts (culture signal)
Streamline with SecureSlate
MFA and session attacks create urgent IR work and later audit questions. SecureSlate helps security and compliance teams evidence authenticator policies, access reviews, incident timelines, and corrective actions—so “we moved admins to passkeys” is provable, not anecdotal.
Use SecureSlate to:
- Track MFA / identity risks and remediation owners
- Attach fatigue and hijacking IR evidence to SOC 2 and ISO controls
- Manage policy attestations for acceptable use and access control
- Follow up with access reviews after account takeover events
Get started for free: Create your SecureSlate account
Prefer a walkthrough? Book a demo to align MFA hardening and IR evidence with your frameworks.
FAQ: MFA fatigue and session hijacking
Does number matching stop MFA fatigue?
It typically reduces accidental approvals by forcing the user to read a code. It does not stop AiTM or stolen session cookies.
Will passkeys stop AiTM?
Phishing-resistant MFA (FIDO2/passkeys) typically prevents classic AiTM credential relay. You should still revoke sessions and monitor tokens for other theft paths.
What should users do during a push storm?
Deny prompts, do not approve to stop them, and report via a known-good channel (not a number in the phishing email).
Is session hijacking in scope for ITDR?
Yes. Session and token abuse is core identity threat detection and response—even when MFA succeeded earlier.
How does SecureSlate help?
It organizes identity risk, policy proof, access reviews, and incident evidence so MFA hardening and IR work stand up in audits.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
