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:

Steal username + password (via phishing, breach, or stuffing)
Trigger repeated push MFA requests
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

Practical Example of Defending MFA Fatigue in Azure AD Conditional Access

# Example: Block legacy MFA attempts and enforce user risk checks
# Requires AzureADPreview module

Import-Module AzureADPreview

# Create a Conditional Access policy that blocks legacy authentication
New-AzureADMSConditionalAccessPolicy -DisplayName "Block Legacy Auth" `
  -State "Enabled" `
  -Conditions @{
      Users = @{ IncludeUsers = @("All") }
      ClientAppTypes = @("Other") # Legacy Auth
  } `
  -GrantControls @{
      BuiltInControls = @("Block")
  }

# Enforce MFA on high risk sign-ins only
New-AzureADMSConditionalAccessPolicy -DisplayName "Risk-based MFA" `
  -State "Enabled" `
  -Conditions @{
      Users = @{ IncludeUsers = @("All") }
      SignInRiskLevels = @("High")
  } `
  -GrantControls @{
      BuiltInControls = @("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

Seth Keddy @kedster