The MFA Illusion

Identity is the new firewall

Attackers no longer need your password. They don't even need to break your MFA. They just need to sit between you and a login screen.

        TL/DR

• Your end users are likely providing their credentials and access on a regular basis and may be unaware it is even happening
• Unless you have some form of identity threat protection, you are flying blind
• Make a plan to get off passwords and especially towards phish-resistant MFA - NOW
• Automate remediation actions in your identity provider for real-time protection
• Enable Continuous Access Evaluation or other measures to reduce token replay risks

For over 25 years multi-factor authentication was the silver bullet. "Enable MFA” was what we all preached and the first time I saw an RSA fob I was sure this would solve everything.  OK, that was a long time ago, and I had much less gray hair. This was also back in the day where almost all cybersecurity was focused on “the firewall” as our security saviour, then IPS and so on, and so on.

So to prevent identity threats, perhaps the dumbest idea of all came into all of our requirements, well just change the password every 90 days AND use MFA, and then you are certainly good.  Also make your password really strong, and don’t allow anyone to re-use them AND use MFA - OK, now you are really good.

Today, attackers don't need to steal your password at all. They just need to intercept the session after you successfully authenticate - credentials, MFA code, and all. This technique, known as Adversary-in-the-Middle (AiTM) has grown into a primary vector responsible for some of the largest corporate breaches of recent years. And the uncomfortable truth is that most organizations are still running MFA that offers zero protection against it.

Identity is our new “firewall” in most cases and may be the only thing standing between your organization’s data and an attacker.

Understanding the Adversary-in-the-Middle Attack

A traditional phishing attack aims to steal credentials. The attacker sends a fake login page, the victim types their password, and the attacker captures it. MFA broke this model and even with the password, the attacker lacked the second factor that expired before it could be reused.

AiTM attacks do not try to steal credentials, but instead proxy the entire authentication process in real time.

AITM ATTACK FLOW — REAL-TIME SESSION HIJACKING VICTIM(Employee) → ATTACKER'SPROXY SERVER → LEGITIMATESERVICE (M365) The attacker does not break MFA — they let the victim complete it, then steal the resulting authenticated session cookie.

The victim receives a phishing email pointing to a convincing lookalike domain or an organization you have been in contact with already, and hey they are just sharing a file with you, so what could be the harm.  Click, go ahead, you know you want to.

They click and see a pixel-perfect Microsoft login page, and enter their credentials. The proxy server forwards these to Microsoft in the background. Microsoft responds with an MFA challenge. The proxy displays this to the victim. The victim completes the MFA and the proxy relays that response to Microsoft. Microsoft, satisfied, issues an authenticated session cookie. The proxy captures that cookie. The attacker now holds a valid, authenticated session and can access the victim's account without ever knowing their password or their MFA secret.

THREAT LANDSCAPE Why AiTM Has Become the Attack of Choice Several converging factors have made AiTM the dominant enterprise credential threat: →  Commoditized toolkits lower the barrier — no deep technical skill required →  Traditional MFA adoption has made pure credential theft less valuable, pushing attackers upstream →  Session cookies have long lifetimes; one stolen cookie can provide persistent access for days or weeks →  Cloud services (Microsoft 365, Google Workspace, Okta, Salesforce) are high-value targets with unified access to vast data →  Conditional access policies often don't re-evaluate mid-session, allowing lateral movement once inside →  Business Email Compromise (BEC) fraud — redirecting wire transfers — can be executed directly from stolen sessions

Why Conventional MFA Fails

Conventional MFA methods remain highly effective against bulk credential attacks, password spraying, and unsophisticated phishing. The problem is that they were never designed to resist a real-time proxy interception. The codes they generate (TOTP codes, SMS OTPs, push notifications) are possession factors that prove nothing about the connection through which they travel.

When a user approves a push notification, they are confirming: "I intend to authenticate." They are not confirming: "I am authenticating directly to Microsoft, via a connection I trust, to a server whose identity has been cryptographically verified." That distinction is everything.

What Makes Authentication Truly Phish-Resistant

The term "phish-resistant MFA" has a precise technical meaning, and it centers on a single concept: origin binding. A phish-resistant authentication method cryptographically ties the authentication response to the specific origin (the domain and server) that the user's browser is communicating with. If that origin is not the legitimate service, the authentication simply fails. A proxy server sitting in the middle will never receive a valid authentication token, because the browser will refuse to generate one for an unrecognized origin.

This is the fundamental innovation of the FIDO2 standard and its consumer-facing implementation, passkeys. When a user registers a FIDO2 credential with login.microsoft.com, that credential is mathematically bound to that exact origin. An AiTM proxy operating at microsoftonline-secure.net will receive nothing usable, the browser will not generate a valid authentication response for the wrong domain.

How to move forward

Transitioning to phish-resistant MFA is not an easy change, but moving users away from passwords will be a security change they will definitely welcome, unless you end-users really enjoy changing their passwords.

Phase 1: Prioritize

Not every user and every system presents equal risk. Begin by identifying your highest-value targets: privileged administrators, finance personnel with payment authority, executives, and any account with confidential data access. These accounts should receive phish-resistant MFA and more restricted Conditional Access Policies.

Enable automated remediation, because it is not possible to manually manage identity threats at the speed end-users are providing their passwords in AiTM attacks. MS Defender for Identity and Crowdstrike’s ITP are great examples and are really quite good at detecting anomalous login activity.

Phase 2: Deploy FIDO2 / Passkeys

Microsoft Entra ID, Google Workspace, Okta, and Ping Identity all support FIDO2 authentication. MS EntraID with MS Authenticator is an especially good example for any MS shop. Hardware security keys (YubiKey, Google Titan) remain the gold standard for those who need it all and don’t mind hardware deployment. Platform passkeys built into Windows Hello, macOS, iOS, and Android provide FIDO2-grade security for the general workforce without requiring physical hardware distribution.

Undeniably, passkeys are difficult in most consumer aspects, and their ability to work on another device or within an app (even if they are shared in a password manager) makes them difficult when not used in a corporate environment.  However, the days of passwords and non phish resistant MFA solutions are gone in the corporate world and if you are not actively monitoring identity threats in your environment, you are missing how many users are falling victim to AiTM threats every week.

Phase 3: Eliminate Weaker Fallbacks

Phish-resistant MFA delivers no protection if users can fall back to a simple password or SMS OTP. Conditional access policies must be configured to enforce phish-resistant methods for protected resources, no exceptions, no fallback to legacy MFA.

Phase 4: Layer Complementary Controls

Phish-resistant MFA addresses authentication but does not stop all authentication threats. Short session token lifetimes forcing frequent re-authentication; continuous access evaluation that revokes sessions on anomalous signals; and most importantly, ensuring only managed devices can authenticate to your organizational domain where possible.