AiTM Phishing: Why Your MFA Is No Longer Enough

The MFA Paradox: More Secure, Yet Still Vulnerable

For years, the security community has championed Multi-Factor Authentication (MFA) as the single most effective control to prevent unauthorized account access. The data supports this: enabling MFA blocks the vast majority of identity-based attacks. This has led many organizations to a state of complacency, believing their MFA implementation—whether through SMS codes, authenticator apps, or push notifications—is a silver bullet.

This belief is now dangerously outdated. A sophisticated and increasingly democratized attack vector known as Adversary-in-the-Middle (AiTM) phishing effectively bypasses these common forms of MFA. Attackers are no longer just after your password; they are after the session token granted after a successful MFA login, giving them a golden key to your corporate resources.

Understanding Adversary-in-the-Middle (AiTM) Phishing

Traditional phishing aims to steal static credentials like a username and password. AiTM phishing is fundamentally different. It doesn't try to break MFA; it tricks the user into completing the MFA process on the attacker's behalf. This is accomplished using a transparent reverse proxy that sits between the user and the legitimate identity provider (IdP) like Microsoft Entra ID or Okta.

How an AiTM Attack Works

The attack chain is slick, seamless, and difficult for an end-user to detect.

1. The Lure: The user receives a targeted phishing email, often with a convincing pretext (e.g., "Action Required: Review Shared Document," "Unusual Sign-in Activity Alert"). The link in the email points not to the real Microsoft 365 login page, but to an attacker-controlled domain.

2. The Reverse Proxy: This attacker domain hosts a reverse-proxy toolkit like Evilginx or EvilProxy. When the user clicks the link, the proxy fetches the content from the real login page (e.g., login.microsoftonline.com) and displays it to the user. The browser's address bar will show the phishing domain, but the page content—logo, text, and layout—looks identical to the real thing.

3. Credential and MFA Interception: The user, seeing a familiar login screen, enters their username and password. The reverse proxy captures these credentials and passes them to the legitimate Microsoft login service. Microsoft, seeing a valid password, then prompts for the second factor.

4. The MFA Handshake: The reverse proxy transparently passes the MFA challenge to the user.

   • If it's an OTP, the user enters the code from their authenticator app into the phishing site.
   • If it's a push notification, the user receives the push on their phone and approves it.

5. The Session Token Heist: The user has now successfully authenticated to Microsoft through the attacker's proxy. In response, Microsoft sends a session token back to the user's browser, which is meant to keep them logged in. The reverse proxy intercepts this token before it ever reaches the user. This is the ultimate prize.

6. Session Replay: The attacker takes the stolen session token and "replays" it in their own browser session. They can now access the user's Microsoft 365 account—Outlook, SharePoint, Teams, OneDrive—with the user's full permissions. They have completely bypassed the need to authenticate because the token proves they already have.

The Rise of Phishing-as-a-Service (PhaaS)

What was once the domain of sophisticated, state-sponsored actors is now available to a much wider range of cybercriminals through Phishing-as-a-Service (PhaaS) platforms. Toolkits like EvilProxy, Tycoon, and the open-source Evilginx have dramatically lowered the barrier to entry for launching AiTM campaigns.

These services are often sold on a subscription basis and provide attackers with:

• Pre-configured reverse-proxy infrastructure.
• A portfolio of convincing phishing templates for major services like Microsoft 365 and Google Workspace.
• Support for bypassing various MFA methods.
• Dashboards for managing campaigns and harvesting credentials and session tokens.

This industrialization of AiTM means these attacks are not rare or theoretical. As Microsoft noted in a detailed breakdown, a large-scale AiTM campaign targeted over 10,000 organizations in 2022. The accessibility of these tools means that any organization, regardless of size, is now a potential target. Source: Microsoft Security Blog, "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to compromise business email".

Why Traditional MFA Is Defeated

The core weakness of most MFA methods is that they are "phishable." They prove possession of a factor, but they don't verify the origin of the authentication request. The authentication is decoupled from the endpoint where the login is occurring.

• SMS and Email OTP: An attacker's proxy simply asks the user for the code sent to their device. The user obligingly types it into the phishing site, handing it directly to the attacker.
• Authenticator App OTP (Time-based): This is no different from SMS. The user sees a prompt for the 6-digit code and enters it into the text box on the fraudulent site. The proxy captures it and uses it to complete the login.
• Push Notifications: When the attacker's proxy submits the user's credentials, the IdP sends a push to the user's registered device. The user sees "Approve sign-in?" and taps "Approve," validating the attacker's session, not their own. Even with number matching, where the user must type a number displayed on the screen into their app, a user can still be duped into completing the step on the fraudulent site, authenticating the attacker's session.

The fundamental flaw is that none of these methods create a cryptographic binding between the authentication ceremony and the browser session.

Building a Phishing-Resistant Defense Strategy

Defeating AiTM phishing requires moving beyond phishable MFA and adopting methods that are, by design, resistant to proxying and replay attacks. These methods tie the authentication challenge cryptographically to the specific service and device requesting it.

The Gold Standard: FIDO2 and Passkeys

Fast Identity Online (FIDO) is an open authentication standard built to solve this problem. FIDO2 is its latest iteration, enabling passwordless authentication using passkeys. A passkey is a cryptographic key pair where the private key is stored securely on a device (like a laptop's TPM, a mobile phone's secure enclave, or a hardware security key like a YubiKey) and the public key is registered with the online service (the IdP).

Here's why FIDO2 stops AiTM cold:

• Origin Binding: When a user registers a passkey with a service (e.g., login.microsoftonline.com), the passkey is cryptographically bound to that specific web domain (the "origin").
• Challenge-Response: During login, the service sends a unique challenge. The passkey on the device signs this challenge with its private key, proving both possession of the key and the user's presence (via a biometric or PIN).
• The Phishing Block: An AiTM proxy site resides on a different domain (e.g., login-microsoft-secure.com). When this phishing site tries to proxy a challenge from the real service, the user's browser or operating system sees that the origin of the request does not match the origin stored with the passkey. It refuses to sign the challenge. The attack fails instantly and automatically, with no user decision required.

Certificate-Based Authentication (CBA)

For enterprises heavily invested in Public Key Infrastructure (PKI), Certificate-Based Authentication represents another powerful, phishing-resistant method. With CBA, a unique client certificate is issued to a user's managed device and often stored in a hardware-backed keystore like a TPM.

When the user accesses a service, the IdP challenges the browser to present this certificate. Because the private key associated with the certificate cannot be exported from the device, an attacker's reverse proxy cannot steal and replay it. The authentication is bound to the device itself. Source: CISA, "Implementing Phishing-Resistant MFA".

Layering Defenses with Conditional Access and Token Protection

While migrating to FIDO2 or CBA is the ultimate goal, it's a journey. In the interim, you must use other controls to raise the bar for attackers.

• Conditional Access Policies: In Microsoft Entra ID, strong Conditional Access policies can disrupt session token replay. By requiring sign-ins to originate from compliant or hybrid-joined devices, you can invalidate a stolen token if the attacker tries to use it from their own unmanaged machine. Policies restricting access to trusted IP ranges also add a significant barrier.

• Token Protection: A newer feature in Microsoft Entra ID, Token Protection (also known as token binding), is a game-changer. It cryptographically binds the session token to the device it was issued to. If an attacker steals a token from a user's machine and tries to replay it from their own, Entra ID will detect the mismatch and reject the session. This effectively makes a stolen token useless outside its original context.

What Schutz IT Recommends

Protecting your enterprise from modern identity attacks requires a strategic shift away from phishable MFA. The threat of AiTM is not theoretical; it is actively compromising organizations that believed their MFA was sufficient.

We advise a multi-pronged approach:

• Assess and Identify Risk: Immediately audit your Microsoft Entra ID tenant to identify all users and applications still using phishable MFA methods (SMS, OTP, basic push).
• Strengthen an d Harden: Aggressively implement and enforce Conditional Access policies that require trusted devices for access to sensitive applications. This provides a critical mitigating layer while you plan your strategic transition.
• Pilot Phishing-Resistance: Begin a pilot program with a targeted user group for a phishing-resistant method like FIDO2 passkeys (via security keys or platform authenticators) or Certificate-Based Authentication.
• Develop a Roadmap: Create a strategic, multi-year plan to move your entire organization toward phishing-resistant authentication as the default. This is no longer an optional upgrade; it is an essential evolution of your security posture.

Talk to Schutz IT about phishing-resistant identity →