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
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**
## 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