Multi-Factor Authentication Bypass Techniques

MFA stops most credential attacks the way a locked door stops most burglars: it works until someone finds a window. Proofpoint found MFA was already turned on for 59% of the accounts attackers successfully took over. Obsidian Security, looking at its own incident response cases, found MFA failed to stop the attack in 84% of them. Kroll's post-breach investigations turned up an even starker number: 90% of the organizations it examined after a compromise had MFA deployed at the time someone broke in.

Those numbers don't mean MFA is broken. They mean attackers stopped trying to break it.

The attack surface shift from the authentication event to the session that follows it

The old playbook was simple: steal a password, get stopped at the MFA prompt, move on to an easier target. That playbook is mostly dead. The new one lets the victim log in for real, complete the MFA challenge honestly, and then goes after the thing the identity provider hands out once login succeeds, the session token.

SpyCloud recaptured 8.6 billion stolen session cookies and session artifacts in 2025, a figure that signals just how industrialized this theft has become. That's not a typo, and it's not a niche crime. Mandiant's M-Trends 2026 report describes the same shift from the front lines: attackers increasingly harvest long-lived OAuth tokens and session cookies instead of relying on passwords.

Why does this matter to the person building the defense? Because it means the job doesn't end at the login screen anymore. Post-authentication monitoring now carries as much weight as authentication hardening. Session lifetime, token revocation, behavioral signals on already-logged-in sessions, these are load-bearing controls now, not nice-to-haves. It barely matters how strong your MFA method is if the session it produces afterward sits unguarded.

Broadly, the bypass techniques below split into two families. Some skip or manipulate the authentication event itself, a flow that was never built to require MFA. Others let authentication complete honestly, then steal what comes out the other end. Keep that split in mind. It'll help place each technique below, and it sets up the fixes that follow.

Adversary-in-the-Middle phishing: intercepting the session token in real time

Adversary-in-the-Middle, AiTM for short, works through a reverse proxy sitting between the victim and the real login page. The victim sees a pixel-perfect copy of the actual portal, no visual tells, no broken logos. They type in their password. They complete the MFA challenge exactly as they would on a normal day. The proxy quietly relays every step to the real service behind it and, critically, captures the session cookie the real service issues once login succeeds. The attacker then replays that cookie and walks into an authenticated session without ever tripping another MFA prompt.

This used to require custom infrastructure. Now it's a rented service. Kits like Evilginx, Evilproxy, and Tycoon 2FA have turned AiTM into something closer to a subscription product than a bespoke hack. Mamba 2FA specifically targets major cloud identity platforms and builds in anti-bot detection so it doesn't get flagged by automated security scanners. Proofpoint reports Tycoon 2FA became the highest-volume AiTM phishing threat in its visibility, showing this is now widespread beyond research labs. It's commodity crime.

The root cause is architectural: the session token issued after login carries no binding to the device or network that actually performed the authentication. Whoever holds the cookie is, as far as the server's concerned, the user.

SOC teams watch for a specific signature here. Authentication traffic coming from VPS or proxy infrastructure instead of ordinary consumer internet connections. Domain registrations that mimic a real login portal but with a subtle typo or an odd top-level domain. A short gap, sometimes minutes, between credential entry and access showing up from a completely different IP address.

The real fix isn't detection, it's making the theft impossible. FIDO2 and WebAuthn passkeys cryptographically bind the authentication assertion to the origin domain, so a proxied login simply can't satisfy the challenge, no matter how convincing the fake page looks. CISA's guidance points the same direction: phishing-resistant MFA, meaning FIDO/WebAuthn or PKI-based authentication, is the strongest available counter to AiTM. Adoption is the catch. only 19% of companies have deployed FIDO2/WebAuthn passkeys, which leaves the large majority still exposed to a threat that's fully solvable today.

MFA fatigue: engineering approval through volume, not deception

MFA fatigue targets the person holding the phone rather than the authentication system. It targets the person holding the phone.

The mechanics are almost boring in their simplicity. An attacker gets hold of a valid password, through phishing, a breach dump, or an infostealer log. They script repeated login attempts, which floods the victim's device with push notifications, one after another. The exploit here isn't technical, it's cognitive: overload, habituation, and a quiet assumption most employees carry that a prompt from their own company's app must be legitimate. Eventually, worn down, the victim taps Approve just to make it stop. In the more sophisticated versions, the attacker calls or messages the victim over WhatsApp at the same time, posing as IT support and coaching them through the approval.

The 2022 Uber breach followed this exact pattern. An attacker spammed a contractor with push notifications for over an hour, then reached out over a messaging app posing as IT support. One approval opened access to multiple employee accounts and internal tools. Uber later said sensitive user data wasn't accessed, but the attacker gained access to multiple employee accounts and internal tools starting with a single tap.

This isn't a one-off case study, either. CISA's advisory on Scattered Spider (AA23-320A) describes the group continuously sending MFA notification prompts specifically to wear employees down into accepting. APT29 has used the same technique. CISA updated that advisory as recently as July 29, 2025, which tells you this isn't a historical footnote, it's an active, ongoing method. MITRE ATT&CK even has a dedicated entry for it: T1621, Multi-Factor Authentication Request Generation.

The root cause is a design flaw in the push notification itself: a binary approve-or-deny choice with zero context about what triggered it. The user has no way to tell a legitimate login attempt from an attacker sitting on the other end of the same request.

Three fixes actually address this, rather than just papering over it. Number matching forces the user to type a code shown on the login screen instead of tapping a button, so an attacker can't replicate the interaction without the mismatch becoming obvious. FIDO2 hardware tokens or passkeys remove push notifications from the equation. And rate limiting on push attempts, paired with alerts on burst patterns, catches the flood before the victim gets worn down.

Session hijacking, token theft, and post-authentication risk

AiTM steals the token while login is happening. Session hijacking steals it afterward, from wherever it's been sitting. Different attack surface, same outcome: an attacker holding a valid session without ever facing an MFA prompt.

The paths in vary. Vulnerabilities in VPNs, web gateways, or application servers can expose session tokens directly. Infostealer malware sitting on a victim's machine harvests session cookies straight out of the browser's storage. And OAuth token theft targets something even more durable: long-lived tokens that survive a password reset and even survive re-enrolling MFA, because nobody built them to expire when credentials change.

The CitrixBleed vulnerability, tracked as CVE-2023-4966, gave LockBit affiliates a real-world demonstration of scale. Session tokens were harvested straight out of Citrix NetScaler appliances, and MFA was bypassed entirely, because the attacker never needed to authenticate at all, just to hold the token someone else already had. Verizon's 2025 DBIR flags suspicious login patterns as a recurring signal of credential theft and MFA bypass, and calls out token theft and session hijacking, alongside prompt bombing and AiTM, as notable concerns in its dataset.

OAuth token theft deserves particular attention because of how sticky it is. A stolen long-lived token doesn't care that the victim reset their password last week. Worse, an attacker holding one can sometimes mint fresh tokens or register brand-new MFA devices, effectively locking in access that survives the very remediation steps a security team would normally reach for first.

Detection here leans on a few reliable tells: sessions logging in from two places at once that are geographically impossible to reach between logins, multiple concurrent sessions for a single account, and authentication flows that somehow complete without the MFA prompt anyone would expect to see.

The fix is layered rather than singular. Short session lifetimes limit how long a stolen token stays useful. Token binding ties a session to the device that created it. Continuous behavioral monitoring after login catches what authentication hardening never will. And aggressive review of OAuth scopes keeps a stolen token from being worth much even if someone gets hold of one.

Help desk social engineering: bypassing MFA by resetting it

Not every bypass needs a phishing kit. Some just need a phone call.

The pattern runs in two phases. First comes reconnaissance: an attacker calls IT support, not to attack anything yet, just to learn how password resets work, what security questions get asked, and what counts as verification. No red flags raised, no alarms tripped. Then comes the impersonation call. The attacker phones back, poses as the employee, uses everything learned in phase one to sail through identity verification, and talks the help desk into resetting the target's MFA. From there, the attacker logs in with stolen credentials and faces no second factor at all, because the help desk just removed it.

CISA's AA23-320A advisory documents exactly this pattern from Scattered Spider, using spearphishing calls to trick help desk staff into resetting passwords and MFA tokens, leading to account takeovers inside single sign-on environments. This is an established pattern, not a new discovery. Contracted or outsourced help desks tend to be softer targets here, simply because identity verification standards are often looser than what an in-house team would enforce.

AI voice cloning has raised the ceiling on how convincing this gets. Generating audio that sounds like a specific executive is now a documented corporate risk rather than a scenario confined to fictional depictions. The WPP CEO voice clone incident is a real-world example of AI-assisted social engineering reaching into a corporate environment.

Help desk verification usually leans on knowledge factors, employee ID, the last four digits of a Social Security number, a manager's name, all of which are findable through OSINT or leftover data from an earlier phishing attempt. None of that actually proves who's on the phone.

Fixing this means changing the verification model. Privileged account MFA resets should require in-person or video verification instead of a phone script. Security teams should alert on unusual volumes of MFA reset requests, especially outside business hours. Security teams should treat any help desk interaction followed by the installation of a remote access tool like TeamViewer or AnyDesk as grounds for an immediate audit, since that combination repeatedly appears as a post-compromise indicator.

Implementation flaws that let attackers skip MFA at the application level

Everything above requires some form of phishing infrastructure or social engineering. This category doesn't require phishing infrastructure or social engineering, because these bypasses come from logic bugs baked into the application during development. These bypasses come from logic bugs baked into the application during development, and they let an attacker skip MFA entirely without tricking a single human being.

Force browsing is the most common version. In a poorly built flow, the session gets marked "authenticated" the moment the password check passes, and the 2FA challenge is just a screen the user sees, not a gate the server actually enforces. An attacker who captures the session cookie right after the password step can skip the MFA page entirely and call protected API endpoints directly, things like profile, settings, or payment endpoints. If the server only checks that a session exists instead of confirming MFA was actually completed on those routes, the endpoint hands over data or accepts changes with no second factor ever verified.

Response manipulation is a close cousin. An attacker intercepts the HTTP response coming back from the MFA verification endpoint and, using a proxy, flips a failure response into a success response before it reaches the browser. If the application trusts that client-side signal instead of enforcing the check on the server, it grants access based on a lie.

Some password reset flows introduce their own hole. Certain implementations disable MFA automatically the moment a reset is initiated, sometimes before the new password is even set. An attacker who already knows a victim's email and password can trigger the reset, watch MFA get disabled as a side effect, then log in with the existing password and no second factor standing in the way. The root cause is a backend dependency between password state and MFA state that nobody designed with an adversary in mind.

And then there's the embarrassingly simple version: hardcoded or default OTP values, things like 0000, 1111, or 123456, left active from testing and never stripped out before the app went to production. Test fixtures that aren't gated behind an environment check make it into the live system, and anyone who finds them gets a free pass.

The fix across all four of these is consistent: enforce MFA completion checks on the server for every protected route, including beyond just the login redirect. Validate MFA responses server-side where they can't be tampered with in transit. Gate test values behind environment checks so they never ship to production. And treat MFA state as something to audit explicitly inside password reset logic, not an afterthought.

SIM swapping and SS7 exploitation against SMS-based MFA

SMS-based MFA has a structural weakness that has nothing to do with the code itself: the phone number receiving it can be stolen.

SIM swapping starts with reconnaissance, gathering enough personal information through OSINT or an earlier phishing attempt to convincingly impersonate the victim. The attacker then calls the victim's mobile carrier, poses as them, and talks the carrier into porting the phone number over to a SIM card the attacker controls. From that moment on, every SMS-based MFA code meant for the victim routes straight to the attacker instead. CISA's AA23-320A advisory documents Scattered Spider using SIM swapping systematically as a standard step in its data extortion playbook.

SS7 exploitation attacks the same weakness from a different angle. SS7, the signaling protocol designed back in the 1970s, still forms the backbone of global mobile communications today. An attacker with access to an SS7 network can redirect SMS traffic and intercept MFA codes in real time, without ever touching the victim's phone or carrier account directly. Both paths land in the same place: a code meant for one person's device ends up in someone else's hands, and the "second factor" never functioned as one.

None of the seven techniques above break cryptography. They exploit flows that were never built to withstand a determined adversary, sessions that outlive the login they came from, and people who are, understandably, only human. Knowing exactly which of these seven map onto a given MFA deployment is the only real way to answer the question that matters: would it survive contact with an attacker who already knows all seven?