How Attackers Bypass MFA: From Fatigue Attacks to AiTM Phishing to Session Hijacking, and the Defenses That Stop Them

An MFA bypass attack circumvents the second-factor challenge to access protected systems, and attackers now execute these techniques so effectively that, among organizations Kroll investigated after a breach, 90% already had multi factor authentication deployed at the time of unauthorized access.

This article examines every major MFA bypass technique security teams face today, from the push bombing campaign that brought down Uber's internal systems to the adversary-in-the-middle phishing kits that intercept session tokens from Microsoft 365 and Google Workspace in real time.

It also covers why SIM swapping continues to undermine SMS-based authentication, and how OAuth consent phishing creates persistent supply chain access that survives password resets.

This article explains how each technique works, which real-world breaches exploited it, and the layered defense strategy spanning phishing-resistant MFA, conditional access, behavioral detection, and security awareness training that measurably reduces bypass risk across an organization.

Organizations seeking to instruct employees around MFA bypass techniques are encouraged to explore an Adaptive Security self guided tour.

Key Takeaways

• Attackers bypass MFA using at least six distinct techniques: push bombing, adversary-in-the-middle (AiTM) phishing, session hijacking, SIM swapping, help desk social engineering, and OAuth consent phishing.
• Kroll research found that 90% of breached organizations had multi-factor authentication enabled at the time of compromise.
• AiTM phishing kits such as Evilginx and Tycoon 2FA intercept session tokens in real time, defeating multi-factor authentication without cracking a single password.
• FIDO2 and WebAuthn passkeys remain the only widely available methods that cryptographically resist AiTM and phishing-based bypass, yet only 19% of companies have deployed them.
• Stopping MFA bypass requires a layered defense: phishing-resistant authentication, conditional access policies, post-authentication behavioral monitoring, and ongoing security awareness training.

MFA Fatigue: How Attackers Bypass MFA With Push Bombing

When attackers bypass MFA through push bombing, a single approved notification hands over full session access to internal systems. From there, lateral movement across G-Suite, Slack, code repositories, and cloud infrastructure follows within minutes.

The 2022 Uber breach demonstrated the catastrophic speed of this attack chain: a contractor approved one push notification after an hour-long bombardment, and the attacker immediately accessed multiple employee accounts, internal tools, and sensitive data. MFA fatigue turns a widely trusted security control into the entry point, exploiting human psychology rather than cryptographic weakness.

MFA fatigue, also called push bombing, prompt bombing, or MFA notification flooding, is a social engineering attack in which an adversary who already holds valid primary credentials triggers a relentless stream of MFA push notifications to the legitimate user's device. The attacker does not break the cryptographic integrity of the second factor.

Instead, they bet that a human being subjected to dozens or hundreds of prompts will eventually approve one out of frustration, confusion, or the mistaken belief that the IT department is performing maintenance. MITRE ATT&CK catalogs this technique as Multi-Factor Authentication Request Generation (T1621), and it has driven some of the most damaging breaches of recent years.

The Mechanics of Push Bombing

The attack unfolds in a predictable sequence, each phase designed to increase the odds that the target will tap "Approve."

Step 1: Credential acquisition. The attacker begins with a working username and password pair. These credentials are harvested through phishing, credential stuffing from previous breaches, infostealer malware logs sold on criminal forums, or simply purchased from initial access brokers. The credentials clear the first authentication gate, the password check, but cannot satisfy the MFA challenge on their own.

Step 2: Triggering the push flood. Using the stolen credentials, the attacker repeatedly attempts to log in. Each attempt sends a push notification to the legitimate user's authentication app or device. The attacker scripts this process to fire prompts every few seconds, generating a barrage that makes the victim's phone buzz or light up relentlessly.

Step 3: Psychological exploitation. Three cognitive vulnerabilities work in the attacker's favor. First, cognitive load: the sheer volume of prompts overwhelms the user's decision-making bandwidth, pushing them toward reflexive rather than deliberate action. Second, habituation: the human brain quickly normalizes repeated stimuli; by the twentieth notification, a user stops reading and just wants the buzzing to stop. Third, the authority gap: employees are conditioned to assume that unexpected authentication prompts originate from legitimate IT activity rather than an adversary.

Step 4: The approval. Eventually the user taps "Approve." Some do it to silence their phone. Others assume a backend system is malfunctioning and the prompt needs to be cleared. In the most dangerous variant, the attacker contacts the target directly, posing as IT support, and instructs them to accept the notification. That single tap provides the session token MFA was designed to protect.

Step 5: Persistence and lateral movement. The foothold is fragile, so attackers move instantly. Within minutes of approval, they register a new MFA device, change recovery settings, reset passwords, or mint fresh OAuth tokens to lock in access. From there, they enumerate internal tools, escalate privileges, and move laterally across the environment.

The Uber Breach: Anatomy of an MFA Fatigue Attack

The September 2022 breach of Uber by the Lapsus$ group remains the definitive case study of MFA fatigue executed at devastating scale. Uber attributed the attack directly to Lapsus$ in its archived SEC filing, noting the group had previously breached Microsoft, Cisco, Samsung, Nvidia, and Okta using similar techniques.

The attack began with the compromise of an external contractor's primary credentials, likely purchased or harvested through a prior breach. Rather than attempt to crack the MFA layer, the attacker triggered repeated push notifications to the contractor's device. When the contractor initially refused to approve the prompts, the attacker escalated. They contacted the contractor on WhatsApp, posing as Uber IT support, and instructed the target to accept the notification. The contractor complied.

That single approval unlocked the door. The attacker immediately accessed multiple employee accounts, then pivoted to G-Suite and Slack, where they posted a message to a company-wide channel. They reconfigured Uber's OpenDNS settings to display a graphic image to employees on internal sites and accessed the company's HackerOne vulnerability dashboard. They also downloaded internal Slack messages and an internal finance tool used for invoice management. Uber's codebase was locked down as a precaution, and the company rotated keys across its internal services.

The CISA Scattered Spider advisory, updated in July 2025, confirms that criminal groups continue to rely on MFA fatigue as a primary access technique, combining repeated push notification flooding with social engineering to bypass authentication controls. The breach exposed a hard truth: the presence of MFA creates a false sense of security when the implementation relies on simple push approval without additional context or verification.

Multi-Channel Pressure Tactics

Modern MFA fatigue attacks have evolved beyond the single-channel push flood. Attackers now orchestrate pressure across multiple communication channels simultaneously, each reinforcing the manufactured legitimacy of the authentication request.

A push notification barrage is the foundation. But today's attackers layer SMS messages on top of the push flood: "Did you request this login? Reply YES to confirm." Phone calls follow, often with a spoofed IT helpdesk number on caller ID. WhatsApp, Telegram, and Slack messages add a third channel, with attackers posing as internal support staff and urging the target to approve the prompt to "resolve the access issue."

The multi-channel approach works because it exploits a cognitive bias across platforms. When an employee sees a push notification, then receives an SMS, then fields a call from "IT," each channel validates the others. The request feels official because it arrives everywhere at once. This coordination is not theoretical: the Lapsus$ group used WhatsApp alongside push notification flooding to breach Uber, and similar multi-channel tactics have been documented in intrusions at Okta and Microsoft.

Timing amplifies the pressure. Attackers frequently launch push bombing campaigns during late-night hours or weekends, when IT support staff are unavailable and the target is groggy and less likely to think critically about an unexpected prompt. A flurry of notifications at 2 a.m. triggers a different response than one at 10 a.m.

The victim, half-asleep and annoyed, is far more likely to approve the prompt just to make it stop. During business hours, attackers lean more heavily on the social engineering component, impersonating helpdesk staff to create urgency around a fabricated access issue.

The countermeasure for security teams is straightforward but demands disciplined execution: deploy phishing-resistant MFA with number matching for all high-value access, train employees to treat any unexpected push notification as a potential attack and report it, and implement rate-limiting that caps prompt frequency per user per time window.

Platforms that simulate these exact multi-channel phishing simulations give employees firsthand experience with the pressure tactics attackers use, transforming them from the attack's target into its detection layer. That detection instinct becomes critical as attackers continue refining the social engineering playbook that turns authentication prompts into access credentials.

Adversary-in-the-Middle Phishing: How Attackers Bypass MFA in Real Time

When an employee clicks a phishing link, enters their credentials, and approves an MFA prompt on a page that looks exactly like the Microsoft 365 or Google Workspace login they use every day, they have done nothing wrong. The attacker now holds a fully authenticated session token.

Adversary-in-the-middle (AiTM) phishing does not crack passwords or defeat multi-factor authentication codes through brute force. It sidesteps both entirely by inserting a reverse proxy between the victim and the legitimate identity provider, relaying every credential and MFA challenge in real time and capturing the resulting session cookie on the other side.

How Attackers Bypass MFA With Reverse Proxy AiTM

The reverse proxy mechanism is what makes AiTM phishing fundamentally different from traditional credential harvesting. In a conventional phishing attack, the victim lands on a static fake login page, types in their username and password, and the attacker collects those credentials for later use. If MFA is enabled, the stolen password alone cannot complete authentication. The attacker gets stopped at the second gate.

AiTM changes the physics of the attack. The attacker deploys a reverse proxy server, typically running a framework like Evilginx, Modlishka, or Muraena, that sits between the victim's browser and the real identity provider.

When the victim clicks the phishing link, their browser connects to the attacker's proxy instead of directly to Microsoft 365, Google Workspace, or Okta. The proxy fetches the real login page from the legitimate service and serves it to the victim, pixel for pixel. The URL bar may show something like login.microsoftonline.com.auth.verify-portal[.]xyz, close enough at a glance.

The victim enters their username and password. The proxy captures those credentials and immediately relays them to the real identity provider. The identity provider, seeing a legitimate login attempt, issues an MFA challenge. The proxy passes that challenge back to the victim's browser, which displays the familiar "Approve sign-in?" prompt or number-matching screen. The victim approves it. The proxy captures that MFA response, relays it to the identity provider, and the real service completes authentication, issuing a session token.

That token is the prize. The proxy intercepts it before the victim ever sees a dashboard, and the attacker loads it into their own browser. The session is live, fully authenticated, and indistinguishable from a legitimate login because, technically, it is one. The identity provider certified that authentication succeeded, and the token carries that certification.

"Unlike token theft, an AiTM phishing attack does not steal a token already issued to a valid user," writes Alex Weinert, Vice President of Identity Security at Microsoft, in the Microsoft Entra blog on defeating AiTM attacks. "Instead, it involves tricking a user into going to a legitimate-looking copy of a website, entering their credentials, and performing MFA to authenticate on behalf of the adversary."

To the victim, the experience often ends with a benign-looking error page or a redirect to the real service, leaving no obvious indication that anything was compromised. Meanwhile the attacker moves quickly.

Evilginx and the PhaaS Ecosystem

Evilginx is the most widely deployed AiTM framework and the reference implementation that shaped an entire generation of phishing tooling. First released as an open-source project and later commercialized as Evilginx Pro, it uses modular "phishlets," YAML configuration files that define how the proxy should handle specific identity providers. A Microsoft 365 phishlet instructs Evilginx which domains to proxy, which cookies to capture, and how to rewrite URLs so the victim's browser never communicates directly with Microsoft servers.

In its default configuration, Evilginx leaves several detectable signatures. Lure URLs follow a distinctive pattern: the domain plus an eight-character mixed-case alphanumeric path, for example, portal-auth[.]com/XkLm3PqR.

The framework uses LetsEncrypt for TLS certificates by default, which by itself is not suspicious, but when combined with a newly registered domain and a short-lived phishing page, the TLS fingerprint diverges from what a legitimate enterprise certificate chain would produce.

What makes AiTM a systemic threat rather than a niche technique is the phishing-as-a-service (PhaaS) model that has industrialized around these frameworks. PhaaS kits package the reverse proxy capability into turnkey platforms that require no technical expertise to operate.

Tycoon 2FA, one of the most prolific kits, pushed tens of millions of phishing messages at more than 500,000 organizations monthly, with access sold for approximately $120, according to Microsoft Security's analysis of the PhaaS operation.

The kit includes Cloudflare Turnstile integration to block automated scanners, IP and User-Agent filtering to evade researchers, and a delayed URL activation mechanism that shows benign content unless the visitor matches a target profile.

Alongside Tycoon 2FA, the current PhaaS landscape includes EvilProxy, a commercialized derivative that adds traffic routing through residential proxies to mask the attacker's origin IP, as well as Rockstar 2FA, Greatness, and Mamba 2FA, each iterating on the same reverse proxy concept with layered evasion.

HEAT Classification

AiTM phishing fits squarely within the Highly Evasive Adaptive Threats (HEAT) classification because it systematically defeats the three controls that traditional secure web gateways and URL filtering rely on. First, HEAT attacks evade signature-based detection: because the proxy serves live content from the real identity provider rather than a static phishing page, the HTML, JavaScript, and visual rendering are identical to the legitimate site.

A URL reputation scanner sees a domain that is too new to have a negative reputation, serving content that pixel-matches the real login page. Second, AiTM attacks adapt dynamically to the target environment, presenting different content based on the visitor's IP range, User-Agent, or behavior, showing benign pages to known security scanner IPs and phishing pages only to targeted users.

Third, the attack chain is multi-stage: the phishing link often passes through a CAPTCHA or a Cloudflare Turnstile challenge before presenting the login page, which breaks automated analysis pipelines that expect a single-page response. Every stage of the AiTM kill chain, from lure delivery and proxy relay to token capture and replay, operates through channels conventional web gateways were never built to inspect at the session layer.

Defending against AiTM requires training employees to scrutinize the URL bar before entering credentials, deploying phishing simulations that replicate the reverse proxy experience, and implementing phishing-resistant authentication like FIDO2 passkeys that cryptographically bind login to the legitimate domain, making proxy interception structurally impossible. The same session-layer thinking that enables AiTM attacks also points toward the next evolution in credential theft, where the attacker does not even need a proxy.

How Attackers Bypass MFA Through Session Hijacking and Token Theft

Once inside, attackers move laterally through OAuth-connected SaaS applications, exfiltrate data, and establish persistence while SIEM, EDR, CASB, and MFA logs register zero anomalies because the token itself is legitimate.

Cookie Theft, Malware, and Session Fixation: The Three Primary Mechanisms

Session cookies are the digital equivalent of a coat-check ticket. Hand the ticket to the server, and it returns an authenticated session, no questions asked. Attackers have three primary methods for obtaining that ticket after MFA completes.

Info-stealer malware exfiltrates browser cookies directly from local storage. Once installed on a victim's machine through a malicious download or compromised browser extension, info-stealers like RedLine, Vidar, and Raccoon extract every stored session cookie, OAuth token, and autofill credential. The attacker imports these into their own browser and inherits the victim's authenticated state across every service they were signed into.

In June 2021, attackers purchased stolen session cookies for $10 from the Genesis dark web marketplace and used them to access an Electronic Arts employee's Slack account. From there, they social-engineered IT support into granting further access and exfiltrated 780GB of source code for FIFA 21 and the Frostbite engine. No password cracking or MFA bypass was necessary at the point of entry.

Packet sniffing on unencrypted or poorly configured networks provides the second vector. While HTTPS adoption has narrowed this attack surface considerably, public Wi-Fi networks, misconfigured corporate VPNs, and ARP spoofing attacks still expose session identifiers in transit. Attackers positioned on the same network segment capture token-bearing packets and replay them before expiration.

The 2022 0ktapus campaign, which targeted over 130 organizations including Twilio and Cloudflare, demonstrated a more sophisticated variant: adversary-in-the-middle proxies that relayed victims' credentials and MFA challenges to the real service in real time, capturing the session token the moment authentication completed. Twilio confirmed that 209 customers had their data accessed through this method.

Session fixation exploits a subtler weakness. Rather than stealing a token, the attacker forces the victim to authenticate using a session identifier the attacker already controls. This typically unfolds through a crafted link sent via email or instant message that embeds a predetermined session ID.

When the victim clicks the link and logs in, the server associates the authenticated state with the attacker-controlled identifier. The attacker then refreshes their browser, and the session is theirs. Unlike cookie theft, session fixation leaves no malware signature and triggers no anomalous authentication alert because the login itself was legitimate.

OAuth Token Replay and Persistent Access

OAuth access tokens and refresh tokens represent an order-of-magnitude escalation over session cookies. A session cookie expires when the user logs out or the server terminates the session. OAuth refresh tokens, by design, survive password changes, MFA re-enrollment, and even account recovery procedures. Their entire purpose is persistent access.

The August 2025 Salesloft-Drift breach crystallized this risk at scale. Attackers gained access to Salesloft's GitHub environment, pivoted to the Drift AWS infrastructure, and stole OAuth refresh tokens issued by customers to enable Drift's Salesforce integration. From August 8 through August 18, they used those tokens to query customer environments.

Over 700 organizations spanning finance, healthcare, and government had their Salesforce data exposed because a trusted integration they had authorized months earlier had its tokens stolen, even though their own systems remained uncompromised. The OAuth tokens made attacker queries indistinguishable from legitimate chatbot activity. No unusual login, no MFA prompt, no impossible-travel alert fired because the token was already authenticated and trusted.

Refresh tokens are the reason standard incident response playbooks fail against post-authentication compromise. Resetting a user's password invalidates their credentials but does nothing to revoke existing OAuth grants. Even removing and re-enrolling MFA credentials leaves active refresh tokens intact in many implementations.

The attacker maintains a ghost session that survives every remediation action short of explicit token revocation. The Reddit 2023 breach demonstrated the same principle: attackers phished an employee's credentials and MFA token through a cloned intranet gateway, then used the captured session to access internal documents, source code, and business systems over an extended period before detection.

The Post-Authentication Detection Gap

Traditional security infrastructure is architected to scrutinize the authentication event but remains effectively blind to what happens after. A SIEM correlates login failures, impossible-travel alerts, and suspicious MFA prompts. An EDR watches for process injection, credential dumping, and malware execution. A CASB inspects authentication flows into sanctioned SaaS applications. None of these tools evaluate whether an already-authenticated session is behaving anomalously.

The behavioral signals that reveal token-based compromise are both observable and specific. When a session that authenticated from a corporate IP in Chicago suddenly originates from a residential proxy in Voronezh, the token has been replayed. When a user who accesses three applications daily suddenly queries CRM records at 3:00 a.m. local time, the session has been hijacked.

Device fingerprinting changes mid-session, a shift from Chrome on Windows to Firefox on Linux without re-authentication, is not a user preference change. It is token theft.

Post-authentication security setting modifications carry particularly high signal value: attackers with stolen sessions routinely register new MFA devices, create app passwords, and authorize new OAuth applications to establish persistence that survives the original session's eventual expiration. Lateral movement through SaaS-to-SaaS connections, where a hijacked session in one application rides OAuth trust relationships into connected platforms, reveals the blast radius long before data exfiltration begins.

These signals exist. What is missing in most security operations centers is the instrumentation to collect and correlate them at the session layer. Security teams that continue monitoring authentication events while ignoring the behavioral integrity of active sessions will detect compromise only after data appears on a dark web forum. The threat does not end with token theft. Attackers who cannot steal a session outright have learned to simply demand access until the target gives in.

SIM Swapping and OTP Interception: How Attackers Bypass Phone-Based MFA

When attackers successfully SIM swap a phone number or intercept one-time passcodes in real time, SMS-based multi-factor authentication collapses entirely as a security control. The attacker receives every text message intended for the victim, resets account passwords, and drains financial accounts, often before the target realizes their phone has lost service.

The UK's fraud prevention service Cifas recorded a 1,055% surge in unauthorized SIM swaps that same year. Even app-generated OTP codes face interception through phishing proxies that relay them to attackers within the typical 30-to-60-second validity window, turning any time-based MFA into a race attackers are increasingly engineered to win.

How Attackers Bypass MFA via SIM Swapping

SIM swapping is not a technical exploit. It is a social engineering attack directed at mobile carrier employees, and it works with alarming speed. An attacker gathers personal information about the target, date of birth, billing address, last four digits of a Social Security number, often purchased from data brokers or harvested from the dark web following major breaches.

Armed with that data, the attacker contacts the target's mobile carrier, impersonates the subscriber, and claims they lost their phone and need service activated on a new SIM card.

The entire attack can execute in minutes. Once the carrier employee transfers the number, the victim's phone goes dead, displaying "No Service" or "SOS Only," while the attacker immediately receives all incoming calls and texts, including password reset links and SMS-based MFA codes. High-value accounts are drained before the victim understands what happened.

The insider threat dimension makes this attack particularly difficult to defend against. Investigations have revealed that attackers openly offer telecom employees as much as $300 per fraudulent swap to bypass security protocols entirely. This "insider-as-a-service" model means even account PINs and security questions become useless if a compromised employee has authority to override them.

High-profile cases demonstrate the stakes. Cryptocurrency investors have been hit hardest due to the irreversible nature of blockchain transactions. In March 2025, T-Mobile was ordered to pay $33 million in an arbitration case after a single SIM swap allowed thieves to drain a customer's cryptocurrency wallet. Enterprise executives have also been targeted, with attackers using the compromised number to pivot into corporate accounts, reset credentials, and escalate privileges across connected systems.

Real-Time OTP Relay Attacks

Even when organizations move beyond SMS to authenticator apps, attackers have adapted. Real-time OTP relay attacks use phishing proxies, often called adversary-in-the-middle (AiTM) proxies, to capture both credentials and time-based one-time passwords as victims enter them, then relay them to the legitimate service before the code expires.

The attack flow is automated and seamless: the victim lands on a phishing page that looks identical to a legitimate login portal, enters their username and password, and the attacker's backend immediately submits those credentials to the real service. The real service responds with an MFA challenge.

The phishing page displays an identical prompt. The victim enters their six-digit TOTP code from Google Authenticator or a similar app. Within seconds, the attacker relays that code to the real service, which grants access and issues a session token, which the attacker then steals for persistent entry.

Attackers can rent these kits for a few hundred dollars per month. The OTP works exactly as designed. The problem is the person typing it does not realize they are handing it to an attacker in real time.

This defeats the core value proposition of time-based codes: the assumption that a 30-second expiration window makes interception impractical. Modern phishing kits relay the code faster than the user can notice anything is wrong.

Why SMS MFA Remains the Most Exploited Channel

SMS-based MFA is the most widely deployed second factor globally, and the most exploited. The problem is structural. SMS authentication was designed to prove possession of a phone number rather than identity. A SIM swap breaks that model entirely because the attacker now possesses the phone number from the carrier's perspective instead of the victim.

Authenticator apps (TOTP) provide better security because codes are generated on-device and not tied to a phone number, but they remain vulnerable to real-time relay as described above.

Push notifications add a layer of user judgment, the "is this you?" prompt, but as MFA fatigue attacks demonstrate, that judgment can be worn down through repetition. Hardware security keys and FIDO2 passkeys are the only methods resistant to both SIM swapping and real-time phishing because they cryptographically bind authentication to the legitimate domain, making proxy-based interception impossible.

Despite clear vulnerabilities, SMS remains stubbornly entrenched. Legacy enterprise systems, consumer banking platforms, and government services default to SMS as the path of least resistance.

Every organization still relying on it is running its second factor through a channel attackers have proven they can compromise in minutes. Adaptive Security's phishing simulations train employees to recognize the social engineering patterns that precede these attacks. Organizations regain control by decoupling identity verification from a phone number, which any compromised carrier employee can hand to a cyberattacker.

How Attackers Bypass MFA Through Help Desk Social Engineering

When attackers socially engineer an IT help desk into resetting multi-factor authentication credentials, they bypass the organization's strongest authentication controls without deploying a single exploit. The attacker becomes the legitimate account holder. Within minutes, they move laterally through the network with trusted credentials and can deploy ransomware, exfiltrate data, or escalate to domain administrator.

The 2025 Unit 42 Global Incident Response Report documented multiple cases where threat actors used help desk manipulation to defeat MFA and escalate privileges in under 40 minutes without deploying malware at all.

The MGM Resorts Breach: How a Phone Call Defeated MFA

In September 2023, attackers associated with the Scattered Spider group executed what remains the most expensive help desk social engineering attack on record. The playbook was disarming in its simplicity. Attackers gathered publicly available personal information about an MGM employee from social media profiles, data broker sites, and prior breach databases.

They called the MGM help desk, impersonated that employee, answered knowledge-based verification questions using the harvested data, and convinced a support agent to reset the employee's password and MFA credentials. Within minutes, the attackers had legitimate access to MGM's internal systems.

What followed was operational devastation across MGM's properties. The company shut down slot machines, hotel booking systems, restaurant point-of-sale terminals, and digital room keys. Guests reported waiting hours to check in using paper records.

The company later disclosed in SEC filings that the cyberattack caused roughly $100 million in direct quarterly losses, with remediation, legal fees, and reputational harm extending the total cost significantly higher.

The breach also exposed personal information of approximately 37 million customers, according to Forbes reporting on the subsequent settlement. Every dollar of that damage traces back to a single help desk call where an agent trusted a voice on the phone.

The MGM attack revealed an uncomfortable truth about modern authentication architecture: MFA is only as strong as the identity verification process that sits behind it. When that process relies on knowledge-based authentication using information attackers can buy, scrape, or steal, MFA becomes a locked door with the spare key hidden under the welcome mat.

The Identity Verification Gap

Most enterprise help desks were designed for efficiency over security. The standard verification workflow asks callers to confirm details like employee ID, date of birth, manager name, or the answer to a static security question. All of it is information adversaries can compile through open-source intelligence (OSINT) gathering. LinkedIn provides reporting structures and tenure. Data broker sites sell phone numbers and addresses. Breach databases supply Social Security numbers and birth dates.

This creates a structural MFA bypass risk that no authentication app can close. The Unit 42 report found that 36% of all incident response cases between May 2024 and May 2025 began with social engineering, and threat actors increasingly targeted identity recovery workflows at IT help desks to reset credentials and bypass MFA entirely.

Attackers do not need to steal a token, intercept a push notification, or clone a SIM card. They simply need to sound convincing enough on a phone call to make the help desk do the work for them.

The psychological dynamics make this attack vector especially dangerous. Help desk staff are trained and measured on resolution speed and caller satisfaction instead of adversarial interrogation. Attackers exploit this by layering urgency, authority, and emotional pressure to short-circuit verification instincts.

One Unit 42 case study described an attacker who made repeated low-pressure calls over several days, building rapport with support staff and mapping internal escalation protocols before striking with a time-sensitive MFA reset request that sailed through.

Hardening Help Desk Processes Against MFA Reset Attacks

Closing the identity verification gap requires treating MFA resets as privileged security events rather than routine support tickets. Several practical controls dramatically reduce this attack surface.

Out-of-band verification should be mandatory for any MFA reset or device enrollment request. The help desk must initiate a confirmation through a pre-registered channel that the attacker cannot intercept.

A callback to the phone number on file in the HR system. A video call through a corporate-managed device. A push confirmation to a manager's authenticated account. The key principle is that the verification channel must exist outside the conversation the attacker initiated.

Manager confirmation workflows add a second layer of human validation. When an employee requests an MFA reset, the help desk routes a quick approval request to the employee's direct manager through a trusted channel before processing the change. This places the identity burden on someone who actually knows the employee and can recognize impersonation attempts that slip past scripted verification questions.

Mandatory video verification for high-risk resets raises the bar further. Requiring the caller to appear on camera through a corporate video platform allows help desk agents to match the face to a company directory photo stored in a system the attacker cannot alter. This control would have stopped the MGM attack entirely. The Scattered Spider operators relied entirely on voice impersonation because they knew no visual confirmation would be required.

Organizations should also log every MFA reset and privileged credential change, feeding those events into security monitoring systems that flag anomalies. Repeated resets from the same phone number, requests outside business hours, and clusters of resets targeting accounts with elevated access all warrant immediate investigation.

The Unit 42 report specifically recommended that organizations lock down identity recovery paths and monitor for unusual request patterns, noting that help desk staff should receive regular training grounded in real-world threat activity. Simulation-based training that exposes support teams to realistic social engineering calls, including vishing attempts using AI-generated voices, builds the recognition skills that static policy documents cannot.

Consent Phishing and OAuth Abuse: How Attackers Bypass MFA via SaaS Supply Chains

Consent phishing exploits a structural blind spot in the OAuth 2.0 framework that powers most enterprise SaaS integrations. When an attacker registers a malicious OAuth application and tricks a user into granting it access to organizational data, the user authenticates legitimately and consents through Microsoft's own authorization screen, satisfying every MFA requirement in the process.

The attacker never steals a password, never triggers a suspicious login alert, and walks away with an OAuth token that persists through password changes and session resets. Microsoft's documentation on illicit consent grants confirms that these attacks bypass credential-based defenses because "the user has already authenticated and authorized the application." The refresh token issued during consent remains valid even after the user rotates their password, giving attackers a durable backchannel that survives most routine security hygiene measures.

How Attackers Bypass MFA With Consent Phishing

The attacker registers an application in a platform like Microsoft Entra ID, configuring it to request specific API permissions, often Mail.Read, Files.ReadWrite.All, or Contacts.Read, that appear unremarkable in the context of a legitimate productivity tool.

The victim receives a phishing email directing them to a genuine Microsoft consent screen, where they are asked to approve the application. Because the prompt originates from Microsoft's actual infrastructure rather than a spoofed domain, the security indicators users are trained to scrutinize pass inspection: the URL, the padlock icon, and the certificate all appear legitimate.

What makes this attack particularly difficult to detect is that every step occurs within authorized channels. The user performs a legitimate authentication with their actual credentials, satisfying any conditional access or MFA policies. Once consent is granted, the attacker's application receives an access token and, critically, a refresh token that can be used repeatedly to obtain new access tokens without further user interaction.

SaaS-to-SaaS Supply Chain Attacks

The most dangerous evolution of consent phishing is the SaaS-to-SaaS supply chain attack, where compromised OAuth integrations propagate across connected applications without ever touching the victim's identity infrastructure. The August 2025 Salesloft-Drift breach provides a definitive case study.

Attackers infiltrated Salesloft's development environment between March and June 2025, then stole OAuth refresh tokens from Drift's AWS environment in August. Using tokens customers had legitimately granted to Drift's chatbot integration, the attackers queried over 700 organizations' Salesforce instances, as well as connected Google Workspace and Slack environments, for ten days before detection.

No malware was deployed, no credentials were phished from end users, and no suspicious logins appeared in identity logs. The activity originated from a trusted, pre-approved integration, making it indistinguishable from legitimate chatbot behavior.

"Traditional monitoring failed because the activity originated from a trusted, pre-approved integration," the Cloud Security Alliance's analysis noted. "OAuth tokens made attacker queries indistinguishable from legitimate chatbot activity." This is the supply chain attack model for the SaaS era: compromising one vendor's OAuth tokens inherits the trust of every customer who ever clicked "Accept."

Detecting and Preventing Illicit Consent Grants

Defending against consent phishing requires shifting from credential-centric security to application-centric governance. The first line of defense is restricting which applications users can consent to. Microsoft Entra ID allows organizations to disable user consent entirely or limit it to applications from verified publishers. Publisher verification, which requires developers to prove organizational identity through Microsoft Partner Network validation, raises the bar significantly, though it does not eliminate risk entirely.

Continuous audit of OAuth app registrations is equally critical. Security teams should inventory every application with delegated permissions, review the scopes granted against actual business need, and revoke any integration that has not been used within a defined window.

Monitoring for anomalous token behavior, such as bulk data exports at unusual hours, API calls from unexpected geographies, or a single application accessing data across hundreds of users, can surface abuse before exfiltration completes.

Organizations running phishing simulations that include consent phishing scenarios give employees the lived experience of recognizing these deceptive authorization prompts before encountering a real one, turning the same OAuth framework attackers weaponize into a controlled training surface.

How Attackers Bypass MFA Through Legacy Protocols and Architectural Weaknesses

MFA authentication systems are only as strong as the weakest protocol still running underneath them. Legacy email protocols like IMAP, POP3, SMTP, and Exchange ActiveSync were designed before modern authentication existed and cannot process a second-factor challenge. Microsoft acknowledged this structural limitation explicitly, stating that MFA enforcement is not possible while basic authentication remains enabled.

Legacy Protocol Exploitation: IMAP, POP3, SMTP, and ActiveSync as MFA Bypass Vectors

Protocols that predate modern authentication standards represent the cleanest MFA bypass available to an attacker. IMAP, POP3, SMTP, and Exchange ActiveSync use basic authentication, a mechanism that transmits a username and password with every request and has no capacity to challenge the user for a second factor. If an organization has MFA enforced across its Microsoft 365 tenant but leaves these legacy protocols enabled, an attacker with stolen credentials can authenticate directly to the mailbox without ever seeing an MFA prompt.

Microsoft spent years warning customers about this risk before disabling basic authentication across Exchange Online, calling it an "outdated industry standard" that made MFA enforcement "not simple or in some cases, possible." The scale of the threat is not theoretical.

Microsoft's own analysis confirms that more than 97% of credential stuffing attacks use legacy authentication.

The Colonial Pipeline attack illustrates what happens when legacy access pathways remain open. Attackers compromised the company's network through a decommissioned VPN profile that lacked multifactor authentication, an account the organization had stopped actively managing but never disabled. Colonial Pipeline CEO Joseph Blount testified before the Senate that the legacy VPN profile did not offer MFA protection, allowing DarkSide ransomware operators to breach the network with a single compromised password.

The resulting shutdown cut off nearly half of the East Coast's fuel supply and cost the company a $4.4 million ransom payment. The same structural blind spot exists in thousands of enterprise environments today. Forgotten protocols and stale access paths that sit outside MFA enforcement persist in the form of SMTP AUTH endpoints, old ActiveSync device pairings, or service accounts using POP3 connectors that nobody remembers.

Fail-Open Architecture and Trusted IP Exploitation

Many organizations configure conditional access policies to skip MFA challenges when users authenticate from trusted corporate IP ranges. The logic is reasonable: if someone is physically on the corporate network, they have already cleared a security boundary. The flaw is that IP addresses can be spoofed, VPNs can be compromised, and internal networks are not the safe zones they once were.

An attacker who gains initial access through a separate vector can authenticate to cloud resources from a "trusted" IP without ever encountering an MFA prompt. Those vectors include a compromised endpoint, a rogue device on the guest Wi-Fi, or a VPN hijack.

The fail-open design pattern introduces a related vulnerability. Some authentication architectures are configured to allow access when the MFA service becomes unreachable, a pragmatic choice to avoid locking users out during cloud provider outages. Attackers exploit this by disrupting connectivity to the MFA provider, forcing the system into a degraded state where it defaults to single-factor authentication.

The technique requires more sophistication than credential theft alone, but it turns infrastructure resilience into a security liability. CISA's Binding Operational Directive 25-01, issued in December 2024, mandates that federal agencies block legacy authentication entirely, recognizing that any protocol unable to support MFA is a structural bypass waiting to be exploited.

Identity Lifecycle Gaps and Third-Party Exposure

The accounts most likely to bypass MFA are the ones nobody is tracking. Poor provisioning workflows create users who are onboarded outside the identity provider that enforces MFA. Delegated administration allows local IT teams to generate accounts that never inherit global conditional access policies. Recovery workflows often reduce authentication to a single factor during a moment of urgency. Password resets, account reactivation, and help-desk bypass codes each create a window where MFA is temporarily absent.

Charles Carmakal, Chief Technology Officer at Mandiant, described in a January 2025 FBI podcast how Scattered Spider operators call service desks, impersonate employees, and request MFA resets or credential recovery.

The success of the campaign depends entirely on whether the agent approves the request without proper identity verification. In most organizations, that call triggers a knowledge-based question or manager approval that weakens under the pressure of a live conversation.

Contractor and third-party identities compound every one of these gaps. External partners, vendors, and contractors routinely operate inside corporate environments using identities provisioned with minimal governance, often authenticating through separate identity providers where MFA enforcement is unknown or absent.

These accounts are typically overprivileged relative to their actual scope of work and survive long past the end of the engagement because no automated offboarding trigger exists for non-employees. A single unmanaged contractor account with access to a code repository or file share can provide the initial foothold an attacker needs, sitting entirely outside the MFA enforcement boundary the security team believes is universal.

"Organizations build strong authentication on weak foundations.," said Mouhamad Mbacke, Identity Security Evangelist at ID Dataweb, writing in Security Magazine (May 2026). Closing these gaps demands visibility across the full identity lifecycle instead of relying solely on stronger factors at the login screen. That visibility is what turns human risk management from a periodic audit into a continuous defensive capability.

Phishing-Resistant MFA: Defenses That Stop Attackers From Bypassing It

Deploy phishing-resistant MFA built on FIDO2 and WebAuthn standards using hardware security keys to cryptographically bind every authentication to its registered domain, a control that defeats adversary-in-the-middle (AiTM) attacks at the protocol level.

Enforce conditional access policies that evaluate device posture, geolocation, and session risk continuously rather than once at login. Layer behavioral detection and post-authentication monitoring across the identity stack, because attackers have proven that no single MFA method, no matter how strong, is invulnerable to every bypass technique in circulation today.

1. Deploy FIDO2 and WebAuthn: Cryptographic Binding That Defeats AiTM

FIDO2 and WebAuthn represent the only authentication standards that CISA classifies as fully phishing-resistant, and for a specific technical reason: they cryptographically bind credentials to the origin domain where they were registered. When an employee registers a FIDO2 hardware security key, such as a YubiKey, Google Titan, or any FIDO2-certified authenticator, the browser generates a public-private key pair tied to that exact domain. During every subsequent authentication, the browser verifies the requesting domain against the registered origin before releasing the credential.

This origin-bound architecture is what makes AiTM proxy attacks, the technique behind tools like EvilGinx, Modlishka, and Muraena, structurally incapable of stealing FIDO2-protected sessions. In a typical AiTM attack, the threat actor positions a transparent reverse proxy between the user and the legitimate service, captures the username, password, and even the time-based one-time passcode (TOTP), then replays the session token.

The proxy succeeds because TOTP codes and push notifications carry no domain context. A FIDO2 assertion, by contrast, is cryptographically scoped to the specific domain the browser negotiates during the WebAuthn handshake. If an attacker proxies the session through a lookalike domain, the browser refuses to release the credential, and the authentication fails before the attacker ever touches a session token.

CISA's phishing-resistant MFA guidance identifies FIDO2/WebAuthn as the gold standard precisely because the credential never leaves the hardware-bound authenticator and the cryptographic challenge-response is scoped to a single verified domain.

Despite this decisive security advantage, adoption remains stubbornly low. Cisco Duo's 2025 State of Identity Security report found that only 19% of companies have deployed FIDO2 tokens, and deployments are typically restricted to privileged users. The barriers are operational rather than technical: 57% of organizations cite token management complexity, 53% point to training requirements, and 47% flag hardware cost as the primary obstacle.

Meanwhile, Okta's 2025 Secure Sign-in Trends Report shows phishing-resistant authenticator adoption growing 63% year-over-year, from 8.6% to 14.0% of users, indicating that momentum is building but remains far from the coverage needed to meaningfully reduce organizational attack surface.

The path forward starts with a tiered deployment model. Prioritize FIDO2 hardware security keys for all privileged accounts: domain administrators, finance approvers, executive assistants with calendar and inbox access, then expand to any role that handles sensitive data or wire transfer authority.

For the broader workforce, platform-native passkeys (Apple, Google, Microsoft) that sync across a user's device ecosystem via the FIDO2 standard offer a usability bridge while maintaining cryptographic phishing resistance. The 87% of security leaders who told Cisco Duo that phishing-resistant MFA is critical to their strategy now need to close the gap between conviction and deployment.

2. Enforce Conditional Access and Risk-Based Authentication Policies

Even the strongest authentication factor becomes weak when granted from a compromised device, an anomalous location, or a session that persists long after the user's risk profile has changed. Conditional access policies close this gap by evaluating context at the moment of authentication and continuously throughout the session.

Device compliance checks form the first policy layer. Before accepting any MFA claim, the identity provider should verify that the endpoint meets minimum security requirements: operating system patch level, disk encryption status, presence of an active endpoint detection and response (EDR) agent, and jailbreak or root detection on mobile devices.

A FIDO2 assertion from a fully patched, managed device carries a fundamentally different risk profile than the same assertion from an unmanaged personal laptop. Conditional access engines in Microsoft Entra ID, Okta, and Ping Identity can enforce this check transparently, blocking authentication from non-compliant devices or shunting them into a restricted session with no access to sensitive resources.

Geolocation restrictions and impossible travel detection add a second decision point. When an authentication request originates from a country where the organization has no operations, or when the same user authenticates from New York and then from Lagos 45 minutes later, the conditional access engine should block the attempt or trigger step-up authentication, requiring an additional factor such as a FIDO2 hardware key when the primary factor was a lower-assurance method.

Impossible travel alerts are among the highest-fidelity indicators of session token theft and AiTM relay attacks, where the attacker's infrastructure is physically located in a different region than the legitimate user.

Token lifetime controls are the third, and most often overlooked, control. Session tokens granted after successful MFA should have deliberately short lifetimes, measured in hours rather than days for high-risk applications. Continuous access evaluation (CAE) protocols, supported by Microsoft Entra and now expanding across the identity ecosystem, can revoke an active session token in near real-time when the user's risk level changes: a device falls out of compliance, the account appears in a credential leak database, or the user's behavior triggers an anomaly score.

Without tight token lifetime controls, a single session token stolen through an MFA bypass technique remains valid long enough for the attacker to perform lateral movement, establish persistence, and exfiltrate data.

3. Layer Behavioral Detection Into a Defense-in-Depth Model

Authentication controls alone cannot stop every attack. When attackers breached Okta's customer support system in October 2023 and stole HAR files containing session tokens, they demonstrated that even organizations running mature identity infrastructure remain exposed if they lack post-authentication monitoring. Those session tokens, valid and already authenticated, required no MFA challenge to use. Behavioral detection fills the gap by analyzing what happens after the login succeeds.

Post-authentication behavior monitoring surfaces anomalies that static authentication checks miss. Geographic inconsistency is the most straightforward signal: a user who authenticated from Chicago at 9 a.m. and then initiates a file download from a Moscow IP address at 9:12 a.m. is almost certainly compromised.

Device fingerprinting changes, a sudden shift in browser version, operating system, screen resolution, or installed fonts between two consecutive sessions, indicate session token theft and replay. More subtle signals include atypical application access patterns, unusual data volumes downloaded, and first-time access to administrative consoles at 3 a.m. local time.

These signals become actionable when integrated into a SIEM or SOAR platform. Security teams should configure correlation rules that trigger automated responses: revoke the session token, force the user to re-authenticate with a phishing-resistant method, quarantine the device, and generate a high-priority incident for the security operations center.

The goal is to shrink the window between compromise and containment from weeks to minutes. Mandiant's M-Trends 2026 report found global median dwell time has climbed to 14 days, up from 11 days in 2024, meaning attackers are operating inside environments longer than ever before detection occurs.

Defense-in-depth against MFA bypass requires that no single control stands alone. Phishing-resistant FIDO2 authentication stops AiTM at the protocol layer but does not protect against session token theft after authentication. Conditional access policies restrict the blast radius of a stolen token but cannot detect a fully policy-compliant session hijacked through endpoint malware.

Behavioral monitoring catches post-authentication anomalies but relies on a mature detection engineering capability that many organizations are still building. Adaptive Security's security awareness training addresses the one layer that technical controls cannot reach: the employee who must decide whether that urgent Teams message from the "CFO" is real or a deepfake, whether to approve a push notification they did not trigger, and whether to report a login prompt that appeared at an unusual hour.

When phishing resistant MFA, conditional access, behavioral detection, and a trained workforce operate as a single defensive stack, attackers face several barriers instead of one lock they can pick.

The Human Element in MFA Bypass Defense

MFA is a technical gate rather than a behavioral one, and nearly every bypass technique exploits human decision-making rather than cryptographic weakness.

The gap is behavioral: push bombing exploits frustration, help desk social engineering exploits trust, and consent phishing exploits inattention. None of these can be detected by a technical control without trained human judgment layered on top.

Why Technical Controls Need Behavioral Reinforcement

Every MFA bypass technique maps to a specific, predictable human vulnerability that no configuration setting can close. MFA fatigue, also called push bombing, succeeds because attackers understand that an employee interrupted by repeated push notifications at 2 a.m. will eventually tap "approve" to make the noise stop.

Help desk social engineering succeeds because support staff are trained to be helpful instead of suspicious. The Unit 42 2025 Global Incident Response Report documented multiple cases where attackers bypassed MFA entirely by convincing help desk agents to reset credentials over the phone. In one instance, the attacker progressed from initial access to domain administrator in under 40 minutes.

Consent phishing, where attackers register a malicious OAuth application and trick users into granting it access, exploits the reality that most employees click "accept" on authorization screens without reading them.

AiTM proxies succeed because the login page looks identical to the real one, and users have no reason to suspect a legitimate-looking Microsoft 365 sign-in screen is actually relaying their session token to an attacker. Training closes the gap that technology leaves open by teaching employees when to distrust, even when everything on the screen looks right.

Simulating MFA Bypass in Security Awareness Programs

Reading about MFA bypass in a training module is not the same as experiencing it. Employees need to encounter these attacks in a controlled environment before facing them in the wild. Effective phishing simulation programs now replicate AiTM-style landing pages that mirror corporate login screens, teaching employees to scrutinize the browser address bar for domain anomalies before entering credentials.

Simulated OAuth consent screens, modeled after the permission grants employees see when connecting third-party apps to Microsoft 365 or Google Workspace, train users to pause and verify the application name, publisher, and requested permissions before clicking "accept."

Push-bombing simulation scenarios, delivered through phishing simulations that replicate the experience of receiving unsolicited authentication requests, build the muscle memory of denial: the instinct to decline and report rather than approve and move on.

Each simulation type isolates a different behavioral failure point and gives employees a safe space to build the recognition skills that no policy document can instill.

Measuring Human Risk Beyond MFA Enrollment

MFA enrollment percentages are a compliance metric rather than a security metric. A dashboard showing 98% MFA adoption tells a security leader nothing about whether those same employees would approve a push-bombing notification, grant access to a malicious OAuth app, or enter credentials into an AiTM proxy under time pressure.

Behavioral risk scoring fills this visibility gap by aggregating data across phishing simulation click rates, training completion patterns, real-world incident reporting, and OSINT exposure into a single, dynamic score per employee. A finance team member who has failed two spear-phishing simulations and has extensive public LinkedIn profile data scrapable by attackers carries objectively higher risk than a developer with clean simulation history and minimal online exposure, even if both show "MFA enrolled."

This shift from binary compliance tracking to continuous behavioral measurement gives CISOs the data layer they need to identify high-risk departments, allocate training resources where they reduce actual exposure, and demonstrate security program ROI in terms boards understand: reduced probability of compromise instead of checkbox completion.

Compliance Mandates, ROI, and Future-Proofing MFA Investments

Regulators have concluded that push-based and SMS-based multi-factor authentication no longer meet the minimum bar for protecting sensitive systems. NIST SP 800-63-4 requires that any deployment at Authenticator Assurance Level 2 (AAL2) offer a phishing-resistant authentication option, while AAL3 mandates it outright for high-value systems.

The business case for upgrading is equally clear: IBM's 2025 Cost of a Data Breach Report pegged the average breach at $4.44 million, and with stolen credentials remaining one of the most common initial access vectors, per the Verizon 2026 DBIR. Organizations running phishable MFA are carrying measurable financial exposure that compliance frameworks are no longer willing to tolerate.

Compliance Frameworks Mandating Phishing-Resistant MFA

The regulatory landscape has shifted decisively. PCI DSS 4.0 Requirement 8.4.2, which became mandatory on March 31, 2025, extends MFA to all accounts accessing the cardholder data environment rather than administrators alone, while Requirement 8.5 mandates protection against replay attacks and prohibits user bypass of MFA controls. Though PCI DSS stops short of explicitly requiring phishing resistance, its emphasis on secure MFA implementation and replay protection makes phishable methods increasingly difficult to justify during an assessment.

NIST SP 800-63-4 goes further: AAL2 requires at least one authenticator to be replay-resistant, and the verifier must offer phishing-resistant authentication. For federal systems, FedRAMP aligns closely with these NIST authenticator assurance levels, placing phishable MFA out of compliance for government deployments.

In healthcare, the HIPAA Security Rule's access control requirements, while not prescribing specific MFA types, are interpreted by auditors against the prevailing standard of care, which now includes phishing resistance where patient data or critical systems are accessed remotely.

For EU financial entities, the Digital Operational Resilience Act (DORA) mandates strong authentication for workforce access to critical systems, with regulators expecting financial institutions to demonstrate that authentication mechanisms resist contemporary attack techniques including adversary-in-the-middle phishing.

Quantifying the ROI of MFA Upgrades

At the average breach cost, a single credential-based incident, whether through push bombing, SIM swapping, or adversary-in-the-middle token theft, costs more than years of phishing-resistant MFA deployment across an entire enterprise. With phishing and stolen credentials driving the majority of breaches, organizations running SMS or push-based MFA are effectively maintaining a door that attackers have already learned to open.

Upgrading to FIDO2 security keys or device-bound passkeys eliminates the phishable token entirely, closing the attack path that push bombing and reverse proxy toolkits exploit.

CISOs building budget cases should model the cost of the upgrade against the probability-weighted breach cost for their sector, using the IBM report's industry-specific figures for precision.

Red Team Testing and Future-Proofing

Simulating MFA bypass in red team exercises reveals detection gaps that compliance checklists miss. An effective exercise replicates real attack paths: adversary-in-the-middle proxies that capture session tokens, push notification fatigue against on-call engineers, and SIM swap attempts against executives still registered with SMS fallback. The goal is not merely to test whether MFA stops the attack.

It is to measure how quickly the security operations center detects the attempt and whether incident response playbooks trigger before the attacker establishes persistence. Organizations should run these scenarios quarterly, complementing technical MFA testing with phishing simulations that measure whether employees recognize and report the credential harvesting attempts that phishable authenticators cannot block.

Longer-term, post-quantum cryptography should factor into MFA architecture planning now. NIST finalized its first three PQC standards in August 2024, and while quantum attacks on authentication tokens are not an immediate threat, the "harvest now, decrypt later" risk means encrypted authentication data intercepted today could be decrypted once cryptographically relevant quantum computers arrive.

Multi year infrastructure decisions made today will determine exposure a decade from now. Security leaders should shortlist vendors that can show a documented, dated migration path to quantum resistant algorithms.

Frequently Asked Questions About MFA Bypass

What percentage of organizations with MFA still experience successful MFA bypass attacks?

Among organizations that experienced a breach and were investigated by Kroll, 90% had multi-factor authentication deployed at the time of unauthorized access, according to Kroll's 2023 analysis of incident response engagements.

These findings do not mean 90% of all MFA-protected organizations are breached. They reveal that widely deployed MFA methods, particularly push notifications and SMS-based one-time passcodes, are routinely circumvented by attackers using fatigue attacks, adversary-in-the-middle phishing, and session hijacking. MFA without phishing-resistant implementation and layered defenses is no longer a reliable indicator of account security.

Can FIDO2 security keys completely prevent MFA bypass attacks?

No. FIDO2 security keys use origin-bound cryptographic credentials that prevent an attacker from authenticating to a domain the key was not registered for, which defeats adversary-in-the-middle phishing and push notification attacks.

However, they cannot prevent SIM swapping attacks that target the phone number rather than the authentication token, help desk social engineering where attackers convince support staff to reset MFA entirely, consent phishing where users grant OAuth permissions to malicious applications, or session hijacking that occurs after authentication is complete.

Security researchers at Silverfort demonstrated in 2024 that MITM attacks can bypass FIDO2 under specific implementation conditions. FIDO2 is the strongest widely available MFA method, but defense in depth, including conditional access policies, session monitoring, and security awareness training, remains essential.

How long does a typical MFA bypass attack take from initial phishing contact to account compromise?

Adversary-in-the-middle phishing attacks can compromise an account within minutes of a victim clicking a malicious link and completing authentication, because the attacker captures the session cookie in real time through a reverse proxy. Microsoft's threat intelligence team documented AiTM attacks where stolen session cookies were used for follow-on business email compromise within hours of the initial phishing click.

MFA fatigue attacks typically require more time: attackers may send push notifications continuously for over an hour before a target approves one out of frustration. SIM swap attacks can execute in minutes once an attacker socially engineers the mobile carrier. The common thread: by the time the victim notices anything unusual, the account has already been compromised.

What should an employee do if they accidentally approved an MFA push notification they did not initiate?

The employee should immediately report the incident to the organization's IT or security team, since speed of notification is the single most important factor in limiting the damage from an account takeover. The account password should be changed right away from a device known to be uncompromised. The account's security settings should be reviewed for active sessions or recent sign-in activity, and any unrecognized sessions should be revoked.

Organizations using Microsoft 365, Google Workspace, or Okta provide a security dashboard where active sessions can be viewed and terminated. Embarrassment should not delay reporting. Security teams view fast self-reporting as evidence of a mature security culture, and early detection and notification dramatically reduce the blast radius and remediation cost of an account compromise.

Are SMS-based one-time passcodes still considered secure for multi-factor authentication in 2025?

No. In December 2024, the FBI and CISA issued joint public guidance explicitly recommending against the use of SMS-based multi-factor authentication due to its susceptibility to SIM swapping and network-level interception. The NIST SP 800-63-4 requires phishing-resistant methods for higher-assurance use cases.

SMS one-time passcodes remain vulnerable to three attack vectors actively exploited in enterprise breaches: SIM swapping through social engineering of mobile carriers, SS7 protocol interception that redirects text messages, and real-time OTP relay where phishing proxies capture and replay codes within their validity window.

Organizations still relying on SMS-based MFA should prioritize migration to phishing-resistant alternatives and pair those upgrades with security awareness training that teaches employees to recognize the social engineering tactics that bypass even stronger authentication methods.

Training Teams to Recognize MFA Bypass Before It Succeeds

MFA bypass attacks exploit predictable human behaviors: the reflexive tap on an approve button during push-bombing, the trust in a help desk caller who sounds legitimate, the habitual click through an OAuth consent screen.

AI-powered phishing simulations that replicate real MFA bypass scenarios, including adversary-in-the-middle landing pages, push-bombing patterns, and fake OAuth consent screens, give employees the pattern-recognition skills to identify and resist these attacks before credentials are surrendered. See how Adaptive's phishing simulations build the behavioral resilience that technical MFA controls alone cannot provide.