September 15, 2022, 12:30 AM. An Uber contractor receives an MFA push notification. They decline it. Another notification. Decline. For over an hour, notifications arrive every few minutes. Exhausted and assuming a system glitch, they finally approve one. Within minutes, the attacker has access to Uber's internal systems, Slack, and source code repositories. The MFA worked exactly as designed. The human didn't.
Most organizations believe Multi-Factor Authentication (MFA) protects them from account compromise. In reality, MFA protects the authentication moment, not the session that follows. This distinction matters because attackers have shifted their focus from breaking MFA to bypassing it entirely through techniques that exploit human behavior, session management weaknesses, and the invisible layer of OAuth tokens that connect SaaS applications.
This guide explains how MFA bypass attacks work, why they succeed, and how security teams can detect and prevent them in modern SaaS environments.
Key Takeaways
MFA protects authentication, not what happens after - Attackers increasingly steal session tokens and OAuth refresh tokens that grant access without re-authentication
Nine primary bypass techniques dominate the threat landscape, from MFA fatigue attacks to adversary-in-the-middle (AiTM) proxies that capture tokens in real-time
AiTM attacks surged 146% in the past year, with nearly 40,000 incidents detected daily and eleven major phishing kits now circulating commercially
Behavioral detection reveals what authentication logs hide - Successful login events look identical whether legitimate or compromised; post-authentication behavior exposes the difference
Defense requires depth beyond MFA - Phishing-resistant authentication, OAuth governance, session monitoring, and legacy protocol blocking form essential layers
What is an MFA Bypass Attack?
An MFA bypass attack is any technique that allows an attacker to gain unauthorized access to an account or system despite the presence of multi-factor authentication controls. Rather than breaking the cryptographic mechanisms of MFA itself, these attacks exploit implementation weaknesses, human factors, session management gaps, and the architecture of modern authentication flows.
The uncomfortable truth: MFA protects the authentication moment, not the authenticated session. Once a user successfully authenticates with MFA, they receive session tokens, cookies, or OAuth tokens that grant ongoing access without requiring re-authentication. Attackers who steal or manipulate these post-authentication artifacts bypass MFA entirely.
Why Attackers Target MFA
MFA has become the last line of defense for most organizations. Passwords alone no longer suffice, and security teams have widely deployed MFA as the critical control preventing account takeover. This makes MFA the target attackers must defeat to achieve their objectives.
Consider the attacker's perspective: Breaking into systems through technical vulnerabilities requires specialized skills and often fails against patched, hardened infrastructure. Bypassing MFA through social engineering, token theft, or session hijacking works against the weakest link: human behavior and trust relationships between systems.
Identity-based attacks rose 32% in the first half of 2025, with more than 97% originating from large-scale password attacks that attempt to leverage stolen credentials against MFA-protected accounts. The attackers aren't trying to crack MFA codes. They're looking for the gaps around MFA where tokens live, humans make decisions, and legacy systems lack protection.
The Post-Authentication Reality
When a user successfully completes MFA, the authentication system issues tokens that prove the user's identity for a period of time. These include:
- Session cookies that maintain login state in web browsers
- OAuth access tokens that grant applications permission to act on the user's behalf
- OAuth refresh tokens that obtain new access tokens without re-authentication
- SAML assertions that enable single sign-on across federated services
Each of these artifacts functions like a bearer token: whoever possesses it can use it. The token itself contains no biometric data, no second factor, no continuous verification that the person using it is the person who authenticated. This architectural reality creates the fundamental vulnerability that MFA bypass attacks exploit.
Understanding how session hijacking works helps security teams recognize why MFA alone cannot prevent account compromise in modern cloud environments.
Nine MFA Bypass Techniques Attackers Use in 2026
The landscape of MFA Bypass: Attack Techniques and Defense Strategies has evolved dramatically. Attackers now employ sophisticated methods that exploit both human psychology and technical architecture. Here are the nine most prevalent techniques security teams face today.
1. MFA Fatigue / Push Bombing
How it works: Attackers flood users with repeated MFA push notifications until the victim approves one out of frustration, confusion, or the assumption that the notifications represent a system error.
The Uber breach of 2022 demonstrated this technique's effectiveness. An attacker compromised a contractor's credentials and sent MFA push notifications continuously for over an hour. Eventually, the exhausted contractor approved one, granting the attacker access to Uber's internal systems, Slack channels, and source code repositories.
The Lapsus$ threat group repeatedly used MFA fatigue attacks throughout their 2022 campaign against Microsoft, Nvidia, Samsung, and other high-profile targets. They would initiate dozens or hundreds of push notifications while simultaneously contacting victims through other channels (phone calls, messages) claiming to be IT support who needed the user to approve the "system update" or "security verification."
Why it works: Humans are the weakest link. Push-based MFA relies on users making correct security decisions dozens or hundreds of times daily. Attackers only need them to make one mistake. The cognitive load of constant interruptions wears down even security-aware users.
2. Adversary-in-the-Middle (AiTM) Attacks
How it works: The attacker positions a proxy server between the victim and the legitimate authentication service. When users enter credentials and complete MFA, they authenticate to the real service through the attacker's proxy. The proxy captures the session token or cookie that results from successful authentication, then uses it to access the account directly.
AiTM attacks surged 146% in the past year, with nearly 40,000 incidents detected daily according to Microsoft's Digital Defense Report. Eleven major AiTM phishing kits now circulate commercially as Phishing-as-a-Service platforms, including Tycoon 2FA, EvilProxy, Mamba, and Evilginx2. Attackers can rent access to these platforms for a few hundred pounds per month.
The victim's experience appears completely normal: they visit what looks like their company's login page, enter credentials, complete MFA with their authenticator app or push notification, and successfully access their account. Behind the scenes, the attacker's proxy has captured the session cookie that proves authentication, allowing them to access the account from their own infrastructure without triggering additional MFA challenges.
MFA is "bypassed" by stealing what comes after authentication. The second factor worked perfectly. The session token simply doesn't require it again. Learn more about how attackers bypass email security using similar techniques.
3. SIM Swapping
How it works: Attackers convince mobile carriers to transfer a victim's phone number to a SIM card controlled by the attacker. Once the number is transferred, SMS-based MFA codes arrive on the attacker's device instead of the victim's.
SIM swapping requires social engineering of telecommunications employees. Attackers typically gather personal information about targets through reconnaissance, then contact carrier support claiming to have lost their phone and requesting a SIM transfer. Some attacks involve bribing or coercing carrier employees.
This technique works exclusively against SMS-based MFA. It has no effect on authenticator apps, hardware tokens, or push notifications tied to specific devices. However, SMS remains widely deployed as an MFA method, particularly for consumer accounts and legacy enterprise systems that haven't upgraded to more secure alternatives.
High-profile SIM swap attacks have targeted cryptocurrency investors, executives, and celebrities, resulting in millions of dollars in theft and unauthorized account access.
4. Session Hijacking / Cookie Theft
How it works: Attackers steal session tokens or cookies after a user successfully authenticates with MFA. These tokens grant access without requiring re-authentication, effectively bypassing MFA by using the artifact that proves authentication already occurred.
Multiple attack vectors enable session token theft:
- Malware installed on user devices that exfiltrates browser cookies and session data
- Malicious browser extensions that harvest authentication tokens from active sessions
- AiTM attacks (described above) that capture tokens during the authentication flow
- Cross-site scripting (XSS) vulnerabilities that expose session cookies to attackers
- Network interception on compromised or malicious WiFi networks
Info-stealer malware has become particularly prevalent, with families like RedLine, Raccoon, and Vidar specifically designed to harvest browser cookies, saved passwords, and authentication tokens from infected systems. Once stolen, these tokens are sold on underground markets or used directly by attackers.
MFA protected the initial login. The attacker uses what that login produced. Understanding pass-the-cookie attacks reveals how session token theft enables persistent access.
5. Social Engineering Help Desks
How it works: Attackers impersonate legitimate users and contact IT help desks requesting MFA resets, claiming they've lost their device, changed phone numbers, or experienced other issues preventing authentication.
The MGM breach of 2023 demonstrated this technique's effectiveness. Attackers researched an employee on LinkedIn, called the Okta help desk impersonating that employee, and convinced help desk staff to reset MFA. Once MFA was removed from the account, the attackers logged in with compromised credentials and gained initial access that ultimately led to a ransomware attack costing MGM over $100 million.
Attackers frequently target help desk verification processes by:
- Impersonating executives or VIPs whose requests receive expedited handling
- Exploiting weak identity proofing that relies on easily researched personal information
- Social engineering help desk staff with urgent scenarios that pressure quick action
- Leveraging compromised accounts to submit internal requests that appear legitimate
Organizations with inconsistent help desk procedures, undertrained support staff, or weak verification requirements face particular risk from this bypass technique.
6. Exploiting Legacy Protocols
How it works: Older email protocols like IMAP, POP3, SMTP, and Exchange ActiveSync were designed before MFA existed and often don't support modern authentication methods. Attackers target these legacy endpoints directly, bypassing MFA entirely by using protocols that never required it.
This technique is particularly common in Microsoft 365 environments where organizations have not disabled basic authentication. Even when MFA is enforced for web-based access and modern authentication flows, legacy protocols may still accept username and password alone.
If basic authentication is allowed, MFA becomes irrelevant for attackers who know to target the right endpoint. They simply configure email clients or scripts to access accounts through legacy protocols using stolen credentials.
Microsoft has been gradually deprecating basic authentication across Microsoft 365, but many organizations have delayed enforcement due to compatibility concerns with legacy applications, devices, or workflows. Each delay extends the window of vulnerability.
7. Token Theft and Replay
How it works: Attackers steal OAuth tokens or session cookies from browsers, credential stores, code repositories, or network traffic, then replay them from attacker-controlled infrastructure to access APIs and services without re-authentication.
OAuth tokens bypass MFA entirely by design. When a user authorizes a third-party application through OAuth, they authenticate with MFA once. The OAuth token issued to that application works indefinitely (or until expiration) without requiring additional MFA. The token itself proves authorization; it doesn't care who uses it or from where.
The Salesloft-Drift incident demonstrated how OAuth token theft enables SaaS supply chain attacks. A compromised integration token granted access that extended through trusted connections into customer environments, affecting over 700 companies. The attackers never authenticated. They simply replayed stolen tokens.
Refresh tokens present particular risk because they persist longer than access tokens and can generate new access tokens without user interaction. These tokens often live in:
- Browser local storage and session storage
- Application configuration files
- Code repositories (accidentally committed)
- Log files and debugging output
- Backup systems and archives
Once stolen, tokens enable attackers to act as the authorized application or user without triggering MFA, authentication logs, or traditional security controls. Learn more about OAuth token abuse and its implications for SaaS security.
8. Targeting Systems Without MFA
How it works: Attackers identify and exploit gaps in MFA coverage by finding systems, accounts, or access paths that lack multi-factor protection. The chain is only as strong as its weakest link.
Common gaps include:
- Legacy applications that don't support modern authentication
- Service accounts that authenticate with API keys or static credentials
- Administrative portals with separate authentication systems
- Development and test environments with relaxed security controls
- Third-party integrations that use long-lived tokens
- Emergency access accounts designed to bypass normal controls
The Snowflake data breaches of 2024 illustrated this vulnerability. Many customers had not enabled MFA on their data warehouse accounts, despite MFA being available. Attackers used stolen credentials to access accounts that lacked the protection most organizations assumed was universal.
Finding the gaps is often easier than bypassing MFA. Attackers perform reconnaissance to identify which systems, accounts, or access paths lack multi-factor protection, then focus their efforts accordingly.
9. Real-Time Phishing with OTP Relay
How it works: Attackers create phishing sites that capture credentials and one-time passwords simultaneously, then relay both to the legitimate service in real-time while the OTP remains valid.
This technique works even against time-based one-time passwords (TOTP) from authenticator apps. The attack flow:
- Victim receives phishing email and clicks link to fake login page
- Victim enters username and password on phishing site
- Attacker's backend immediately submits credentials to real service
- Real service responds with MFA challenge
- Phishing site displays identical MFA prompt to victim
- Victim enters OTP from authenticator app
- Attacker relays OTP to real service within validity window (typically 30-60 seconds)
- Real service grants access and issues session token
- Attacker captures session token for persistent access
This requires real-time coordination but modern phishing kits automate the entire process. Over 90% of credential compromise attacks are expected to involve sophisticated phishing kits by the end of 2026.
The attack succeeds because the OTP is valid when used. The victim authenticated to the real service through the attacker's proxy. From the service's perspective, authentication completed successfully with valid credentials and a correct second factor.
Why MFA Bypass Matters for SaaS Security
The shift to cloud-based SaaS applications has fundamentally changed where and how attackers operate. Understanding MFA Bypass: Attack Techniques and Defense Strategies in the SaaS context requires recognizing that modern attacks don't stop at authentication. They begin there.
Post-Authentication is Where Attackers Operate
MFA protects the front door. Attackers want what's behind the door: sensitive data, persistent access, lateral movement paths, and the ability to extend compromise across the SaaS supply chain.
Once inside an authenticated session, attackers can:
- Exfiltrate data from cloud storage, email, CRM systems, and collaboration tools
- Establish persistence through OAuth app authorizations, email forwarding rules, or additional compromised accounts
- Move laterally to connected SaaS applications using trusted integration tokens
- Escalate privileges by compromising admin accounts or exploiting misconfigured permissions
- Manipulate business processes through access to financial systems, HR platforms, or development tools
Traditional security controls often miss this activity because it occurs within authenticated sessions using valid credentials. The authentication logs show success. The session appears legitimate. Without behavioral context, you can't distinguish the attacker from the authorized user.
OAuth Tokens Bypass MFA Entirely
OAuth has become the standard for enabling integrations between SaaS applications. When users authorize third-party apps, they authenticate with MFA once. The OAuth token issued to that application works without requiring re-authentication, often for extended periods or indefinitely until revoked.
This architectural design creates a fundamental MFA bypass:
User authenticates with MFA OAuth token issued to third-party app Token works forever without MFA
The token itself becomes the authentication. It doesn't matter who uses it, from where, or for what purpose. The token proves authorization was granted. This is how SaaS-to-SaaS attacks propagate through trusted connections that quietly extend trust across organizational boundaries.
Consider the attack chain:
- Attacker compromises vendor's SaaS environment (often without MFA)
- Vendor has OAuth integrations with customer SaaS applications
- Attacker steals OAuth tokens from vendor environment
- Attacker replays tokens to access customer SaaS applications
- Customer's MFA is irrelevant; the token bypasses it
- Attacker moves laterally through customer's SaaS ecosystem
This is not theoretical. The Salesloft-Drift breach demonstrated exactly this pattern, with OAuth tokens enabling access that extended through trusted connections into over 700 customer environments.
The Detection Gap
MFA bypass is invisible in authentication logs. A successful authentication event looks identical whether the user or an attacker completed it. Traditional security tools that focus on authentication success/failure miss the critical context:
- SIEM sees successful login (no alert generated)
- CASB sees traffic patterns that match normal usage (no anomaly detected)
- EDR sees nothing (attack occurs in cloud, not on endpoints)
- MFA logs show successful authentication (working as designed)
The attacker operates in blind spots between tools, using valid credentials, authenticated sessions, and trusted applications. Detection requires behavioral analysis of what happens after authentication, not just whether authentication succeeded.
Organizations need visibility into:
- Post-authentication access patterns and data movements
- OAuth app authorizations and token usage
- Geographic and network anomalies in authenticated sessions
- Lateral movement between SaaS applications
- Changes to security settings, forwarding rules, or permissions
This is the hidden layer where attackers operate after bypassing MFA. Understanding SaaS-to-SaaS lateral movement helps security teams recognize how compromise extends beyond the initial entry point.
Detecting MFA Bypass Attacks
Authentication logs show success. Behavioral detection shows anomaly. The session after authentication reveals the attacker.
Traditional security tools focus on whether authentication succeeded or failed. This binary view misses the critical distinction between legitimate authenticated sessions and compromised ones. Both show successful authentication. The difference appears in what happens next.
Behavioral Signals of MFA Bypass
When attackers bypass MFA and gain access to accounts, their behavior differs from legitimate users in measurable ways:
Geographic and Network Anomalies
- Successful authentication followed by access from unexpected geographic location
- Session used from IP address or ASN the user has never accessed from previously
- Impossible travel: access from two distant locations within timeframe that doesn't allow physical travel
- Connection from hosting provider or VPN service when user typically connects from corporate or residential networks
Device and Session Characteristics
- New device or browser fingerprint never seen for this user
- User-Agent string that doesn't match user's typical devices
- Operating system or browser version inconsistent with user's known environment
- Session attributes that indicate automated access rather than human interaction
Post-Authentication Security Changes
- OAuth applications authorized immediately after login
- Email forwarding rules created within minutes of access
- MFA methods added or removed shortly after authentication
- Password changes or security setting modifications
- Admin role assignments or privilege escalations
Data Access Patterns
- Bulk downloads of files or emails
- Access to sensitive data the user has never viewed previously
- API calls at volumes inconsistent with normal usage
- Systematic enumeration of resources (users, files, groups)
- Data exfiltration to external locations
Lateral Movement Indicators
- Access to SaaS applications the user has never used
- OAuth tokens used to access connected services
- Privilege escalation through service accounts or integrations
- Movement between applications following trust relationships
- Third-party app access patterns that deviate from baseline
Each of these signals individually might represent legitimate user behavior. The combination, timing, and context reveal compromise. An employee traveling for business might authenticate from a new location. An attacker who bypassed MFA will authenticate from a new location AND immediately create email forwarding rules AND access sensitive data they've never viewed AND authorize new OAuth apps.
What Traditional Security Misses
The detection gap exists because traditional tools lack the context to distinguish legitimate authenticated sessions from compromised ones:
SIEM (Security Information and Event Management)
- Sees: Successful authentication event
- Misses: Behavioral anomalies in the session that follows
- Blind spot: No baseline of normal user behavior to compare against
CASB (Cloud Access Security Broker)
- Sees: Traffic to sanctioned SaaS applications
- Misses: Behavioral context of who is accessing what and why
- Blind spot: Cannot correlate activity across multiple SaaS platforms
EDR (Endpoint Detection and Response)
- Sees: Activity on managed endpoints
- Misses: Cloud-native attacks that never touch endpoints
- Blind spot: OAuth tokens used from attacker infrastructure
MFA Logs
- Sees: Successful multi-factor authentication
- Misses: Token theft, session hijacking, or replay attacks that occur after authentication
- Blind spot: Post-authentication session activity
The attacker operates in the gaps between these tools, using valid credentials, authenticated sessions, and trusted applications. Detection requires a security approach that:
- Establishes behavioral baselines for each user, application, and integration
- Correlates activity across SaaS platforms to detect lateral movement
- Analyzes post-authentication behavior rather than just authentication success
- Identifies anomalies in context of normal patterns and peer groups
- Detects OAuth token abuse and integration-based attacks
Obsidian Security's approach uses behavioral detection and a Knowledge Graph that maps relationships between users, applications, OAuth tokens, and data access patterns. This enables detection of compromised sessions that traditional tools miss because they look only at authentication, not at the behavior that reveals compromise.
Understanding techniques of SaaS compromise helps security teams recognize the full attack lifecycle beyond initial access.
Moving Beyond MFA: Defense in Depth for SaaS
MFA is essential but not sufficient. Defense against MFA bypass requires multiple layers of control that address both the authentication moment and the session that follows.
1. Deploy Phishing-Resistant MFA
Not all MFA methods offer equal protection against bypass techniques. FIDO2 and passkeys eliminate entire categories of attacks:
- Resistant to AiTM attacks: Cryptographic binding to origin prevents proxy-based token theft
- Resistant to phishing: Users cannot be tricked into entering credentials on fake sites
- Resistant to MFA fatigue: No push notifications to approve
- Resistant to SIM swapping: No SMS codes to intercept
Organizations should prioritize phishing-resistant MFA for high-risk accounts:
- Administrators and privileged users
- Accounts with access to sensitive data
- Service accounts that support MFA
- Third-party vendor access
Where FIDO2 deployment faces obstacles, hardware tokens (like YubiKey) provide stronger protection than push notifications or SMS. Authenticator apps (TOTP) offer better security than SMS but remain vulnerable to real-time phishing with OTP relay.
2. Implement Conditional Access Policies
Conditional access adds context-aware controls that evaluate risk factors beyond authentication success:
- Device compliance: Require managed, compliant devices for access to sensitive resources
- Location restrictions: Block access from unexpected geographic regions or high-risk countries
- Network requirements: Enforce access from trusted networks for administrative functions
- Application sensitivity: Apply stricter controls for high-risk applications
- Risk-based authentication: Require step-up authentication when anomalies detected
These policies create defense in depth. Even if attackers bypass MFA, they face additional hurdles when accessing from non-compliant devices, unexpected locations, or untrusted networks.
3. Block Legacy Protocols
Disable basic authentication across all services:
- IMAP, POP3, SMTP authentication
- Exchange ActiveSync
- Legacy Exchange Web Services
- Any protocol that doesn't support modern authentication
Organizations should:
- Audit current usage of legacy protocols to identify dependencies
- Migrate applications to modern authentication methods
- Disable basic auth once migration complete
- Monitor for attempted use of blocked protocols
Microsoft provides tools to identify and disable basic authentication in Microsoft 365. Similar controls exist for other SaaS platforms. The operational burden of migration is far less than the security risk of leaving legacy protocols enabled.
4. Monitor Sessions, Not Just Authentication
Behavioral detection reveals what authentication logs hide. Security teams need visibility into:
- Session characteristics: Device, location, network, User-Agent
- Access patterns: What resources accessed, when, and how frequently
- Data movements: Downloads, uploads, sharing, exfiltration
- Security changes: OAuth apps, forwarding rules, MFA modifications
- Lateral movement: Access to connected applications and services
This requires security tools that:
- Establish behavioral baselines for users and applications
- Correlate activity across multiple SaaS platforms
- Detect anomalies in context of normal patterns
- Alert on post-authentication indicators of compromise
Traditional SIEM and CASB tools lack this context. SaaS security platforms like Obsidian provide the behavioral detection and cross-application visibility needed to identify compromised sessions.
5. Govern OAuth and Integration Tokens
OAuth tokens bypass MFA by design. Governance requires:
- Visibility into all OAuth apps authorized by users and admins
- Risk assessment of third-party applications based on permissions, usage, and vendor
- Policy enforcement to block high-risk apps or excessive permissions
- Continuous monitoring of token usage for anomalies
- Automated remediation when risky apps or suspicious token activity detected
Organizations should:
- Inventory OAuth apps across all SaaS platforms
- Classify by risk based on permissions, data access, and vendor trustworthiness
- Revoke unused or high-risk apps that don't serve business purposes
- Monitor token usage for geographic, temporal, or volumetric anomalies
- Implement approval workflows for new OAuth app authorizations
Understanding OAuth security and token management is critical for preventing SaaS supply chain attacks.
6. Strengthen Help Desk Verification
Social engineering of help desks enables MFA bypass. Stronger identity proofing prevents this:
- Multi-factor verification for MFA reset requests (not just security questions)
- Out-of-band confirmation via registered contact methods
- Manager approval for high-risk account changes
- Documented procedures that help desk staff must follow
- Training on social engineering tactics and impersonation attempts
Organizations should:
- Never rely solely on easily researched personal information (mother's maiden name, birthdate)
- Require verification through multiple independent channels
- Implement waiting periods for MFA resets on sensitive accounts
- Log and audit all help desk MFA modifications
- Alert security teams when privileged accounts undergo MFA changes
The MGM breach demonstrated the cost of weak help desk verification. Investment in identity proofing procedures pays dividends in preventing social engineering-based MFA bypass.
Detect MFA Bypass Before Attackers Move Laterally
Attackers who bypass MFA look like legitimate users in your authentication logs. The difference appears in what happens next: unusual data access, new OAuth apps, email rules forwarding sensitive
