MFA Fatigue Attacks and Session Hijacking: How Threat Actors Bypass Modern Defenses

Multi-factor authentication (MFA) is no longer a silver bullet. Threat actors have evolved. If your security model ends at "just enable MFA"—you’ve already lost.

This article dives deep into how modern attackers:

• Bypass MFA using fatigue and phishing
  


• Hijack sessions via stolen tokens
  


• Exploit SAML/SSO trust relationships
  


• Target enterprise environments through DevOps blind spots
  

TL;DR

• 
  MFA fatigue (push bombing) targets human behavior, not code.
  


• 
  Token/session hijacking bypasses MFA after it’s been completed.
  


• 
  SAML/SSO can be abused if tokens or trust chains are intercepted.
  


• 
  DevOps pipelines are rarely hardened for lateral movement via session theft.
  

What is an MFA Fatigue Attack?

"MFA Fatigue" = Overwhelming a user with push notifications until they approve one by accident or frustration.

Attack Flow:

1. Steal username + password (via phishing, breach, or stuffing)
   


2. Trigger repeated push MFA requests
   


3. Hope the user taps “approve” to stop the noise
   

Real-World Example: Uber (2022)

• Attacker obtained credentials via social engineering
  


• Spammed the user with MFA requests for hours
  


• User eventually approved one
  


• Gained VPN access → internal tools → domain admin
  


• MFA didn’t fail—user behavior did
  

Session Hijacking: MFA Is Useless After Login

Once a user authenticates, a session token (JWT, SAML assertion, OAuth bearer token) is issued.

If an attacker steals the token:

• MFA is bypassed
  


• They impersonate the user
  


• Lateral movement becomes easy
  

Attack Vectors:

• XSS in internal apps → steals cookies
  


• Phishing proxies (Evilginx2, Muraena)
  


• Browser malware → exfiltrates cookies
  


• Misconfigured NGINX reverse proxies
  

Example:

GET /dashboard HTTP/1.1

Host: admin.example.com

Authorization: Bearer eyJhbGciOiJIUzI1...

Replay that token—you're in.

SAML and SSO Bypass

SSO + SAML/OAuth is common in enterprises. But if the Identity Provider (IdP) is compromised:

• Tokens can be forged
  


• Tokens can be replayed across services
  


• Validation can be bypassed
  

Golden SAML Attack (SolarWinds):

• Attacker compromised IdP private key
  


• Minted arbitrary SAML tokens
  


• Impersonated any user, including admins
  


• Bypassed all login, password, and MFA mechanisms
  

Why DevOps Pipelines Are an MFA Blind Spot

DevOps environments = soft underbelly:

• CI/CD tokens
  


• Cloud credentials
  


• GitHub/GitLab PATs
  


• API keys in environment vars
  

Problem:

• MFA is applied to humans
  


• Not to service principals, PATs, or automation pipelines
  

Real Scenarios:

• Long-lived tokens are rarely rotated
  


• Role assumptions (e.g., AWS STS) bypass MFA
  


• Attackers pivot via DevOps tools to cloud infra
  

Defense Strategies That Actually Work

✅ 1. Enforce Conditional Access and Risk-Based MFA

• Azure AD Conditional Access
  


• Okta Risk Scoring
  


• Cisco Duo Adaptive Policies
  

Example: Allow access only if:

• Compliant device
  


• Safe IP range
  


• MDM enrolled
  

Block or reauth if:

• Impossible travel
  


• High-risk device
  


• First-time app sign-in
  

✅ 2. Replace Push-Based MFA With FIDO2 or Passkeys

Push MFA is phishable and fatigue-prone.

Use:

• FIDO2 hardware keys (YubiKey, SoloKey)
  


• Platform authenticators (Windows Hello, FaceID)
  

Advantages:

• Bound to origin (blocks phishing proxies)
  


• No push prompts
  


• No shared secrets
  

✅ 3. Shorten Token Lifespans

Attackers love long sessions.

Best Practices:

• OAuth tokens: expire in 1–2 hours
  


• SAML assertions: short validity, reauth on sensitive actions
  


• Idle timeout policies
  


• Rotate refresh tokens
  


• Revoke sessions on sign-out, password change, or anomaly detection
  

✅ 4. Monitor and Audit Session Use

Use telemetry to catch abuse:

• SIEM logs → same token, multiple IPs
  


• Azure sign-in logs → "MFA not performed"
  


• AWS CloudTrail → STS token reuse
  


• GitHub audit logs → PAT creation
  

Alert on:

• Tokens reused in different geolocations
  


• SAML from expired or invalid IdPs
  


• Repeated logins without MFA
  

✅ 5. Lock Down DevOps and CI/CD Access

Key actions:

• Use short-lived OIDC tokens (e.g., GitHub Actions → AWS)
  


• Remove long-lived PATs
  


• Rotate service principal secrets regularly
  


• Protect .env files from leaks
  

Example leak:

AWS_SECRET_ACCESS_KEY=longtermleakyboi

Fix:

• Use tools like Gitleaks or TruffleHog to scan for secrets
  


• Store secrets in vaults (e.g., AWS Secrets Manager, HashiCorp Vault)
  


• Enforce commit hooks to block secret commits
  

Final Thoughts

MFA is necessary—but not enough.

Attackers are:

• Weaponizing human behavior
  


• Exploiting protocol and logic flaws
  


• Hijacking post-auth tokens
  


• Targeting DevOps soft spots
  

What You Can Do Today

• Replace push MFA with FIDO2
  


• Monitor for suspicious token reuse
  


• Harden CI/CD and SSO trust chains
  


• Rotate secrets and shorten token lifetimes
  


• Educate users on why “just tapping approve” is dangerous
  

Resources

• 
  Microsoft: Protect against MFA fatigue attacks
  


• 
  Okta’s Golden SAML Attack Explained
  


• 
  MITRE ATT&CK: MFA Fatigue
  


• 
  Evilginx2 GitHub
  


• 
  Yubico FIDO2 Keys
  


• 
  TruffleHog Secrets Scanner