Every MFA Tool in Your Stack Is Being Bypassed Right Now. Here's Exactly How.

How MFA Is Being Defeated: The Five Active Techniques

These are not theoretical attack vectors. All five are being used in active campaigns against mid-market enterprises and large organizations right now. MGM Resorts, Caesars, Okta's own customer support environment, ADT, and dozens of less-publicized breaches share a common thread: MFA was deployed, and attackers bypassed it.

Technique 1: Adversary-in-the-Middle (AiTM) Phishing

AiTM is the dominant credential theft technique for sophisticated financially motivated actors in 2026. The attack works by placing an attacker-controlled proxy between the victim and a legitimate authentication service such as Microsoft 365 or Okta. The victim receives a phishing link. That link leads to a page that proxies the legitimate Microsoft login page in real time. The victim enters their username and password — the attacker captures those credentials and forwards them to the real Microsoft service. Microsoft sends an MFA prompt. The victim approves the prompt. Microsoft generates an authenticated session token. The attacker intercepts that token before it reaches the victim's browser. The victim sees nothing unusual. The attacker now has a valid, authenticated session token. Tools like Evilginx2, Modlishka, and commercial phishing kits have made AiTM attacks accessible to threat actors with minimal technical sophistication. This is not a nation-state technique — it is a commodity tool.

Technique 2: MFA Fatigue (Push Bombing)

The push notification model of MFA is vulnerable to a simple exhaustion attack. The attacker obtains the user's credentials through any method, then initiates authentication repeatedly, triggering a stream of push notification requests to the victim's phone. Most users, confronted with a stream of unexpected MFA notifications, will eventually approve one to stop the notifications, assume it was a system error, or contact the help desk. MGM Resorts' 2023 breach, which cost approximately $100 million, began with a 10-minute LinkedIn search and a phone call to the company's help desk. The help desk reset MFA for the attacker. No AiTM required.

Technique 3: SIM Swapping

Organizations still using SMS-based MFA remain vulnerable to SIM swapping, where an attacker convinces a mobile carrier to transfer the target's phone number to an attacker-controlled SIM card. SIM swapping has become a managed criminal service, with carrier insiders performing swaps for payment. CISA and the FBI have both issued advisories specifically discouraging SMS-based MFA for organizations with elevated risk profiles.

Technique 4: OAuth Consent Phishing

OAuth consent phishing does not need to steal credentials or bypass MFA at all. The attacker creates a malicious application in Microsoft Entra ID or Google Workspace that requests legitimate-looking permissions. The victim clicks Approve. The application receives an OAuth token with whatever permissions the victim's account can grant. If the victim is a Global Administrator, the application may receive delegated access to the entire Microsoft 365 tenant. MFA was completed correctly throughout. The OAuth grant itself does not require MFA.

Technique 5: Pass-the-Cookie

Once an attacker has local code execution on an endpoint, they can extract authenticated session cookies from browser process memory. These cookies represent the authenticated sessions for every site the user is logged into, including corporate applications behind MFA. The attacker can import those cookies into a browser on attacker-controlled infrastructure and access those applications as the authenticated user, without going through MFA at all. The Microsoft Edge cleartext password vulnerability disclosed this week amplifies this risk significantly.

What Actually Stops These Attacks: Phishing-Resistant MFA

The authentication industry has a solution for AiTM and most session-based bypass techniques: phishing-resistant MFA, available through FIDO2/WebAuthn hardware security keys and device-bound passkeys. The technical reason phishing-resistant MFA defeats AiTM is the origin binding property of the FIDO2 protocol. During FIDO2 authentication, the cryptographic signature is computed over the origin of the authentication request — the actual domain name of the site requesting authentication. A FIDO2 authenticator signing a request from login.microsoft.com will produce a signature that is cryptographically invalid if an attacker tries to use it for their proxy. The authentication fails. The attacker captures nothing.

This property is not present in TOTP codes (Google Authenticator, Authy, Microsoft Authenticator in code mode) or push notifications. A TOTP code generated for an AiTM phishing site is a valid code that works on the real site. The gap between phishing-resistant MFA (FIDO2, passkeys) and phishing-vulnerable MFA (TOTP, push notifications, SMS) is the difference between an authentication mechanism that defeats AiTM and one that does not.

The Conditional Access Gap

Microsoft Entra ID's Conditional Access policies can be configured to require compliant devices, specific network locations, or continuous access evaluation — all of which limit the attack surface for session token theft. The problem is that most mid-market Microsoft 365 tenants are not running Conditional Access at a maturity level that provides these protections. Conditional Access is included in Entra ID P1 licensing — which is included in Microsoft 365 Business Premium. Most organizations have the license. Most organizations have not implemented the policies. In our assessments, the most common finding is Conditional Access policies that exist but have exceptions that negate their effectiveness — service accounts excluded, legacy authentication protocols permitted, device compliance requirements applied only to named users rather than all users.

What to Do Right Now

The path from current MFA deployment to genuinely phishing-resistant authentication is a sequence of decisions requiring organizational change management alongside technical implementation. The first priority is eliminating SMS MFA for all accounts with administrative privileges. For privileged accounts — Global Administrators, Security Administrators, anyone with access to financial systems or sensitive data — SMS MFA is not an acceptable authentication mechanism in 2026.

The second priority is Conditional Access policy audit. If your organization has Entra ID P1 licensing and is not running a complete Conditional Access framework with device compliance requirements, you are not getting value from your Microsoft licensing investment. The policies should block legacy authentication protocols entirely, require compliant devices for all users accessing corporate data, and implement continuous access evaluation for high-privilege accounts.

The third priority is session lifetime review. Default Microsoft 365 session lifetimes run up to 90 days for persistent sessions. This is a 90-day window for a stolen session token to remain valid. For high-privilege accounts and accounts with access to sensitive data, session lifetimes should be significantly shorter and continuous access evaluation should be enabled.

The fourth priority is to stop framing MFA deployment as an endpoint. Organizations that completed MFA rollout in 2021 and moved on have a four-year-old security posture in a landscape that has changed entirely.