Why Organizations Need Phishing-Resistant MFA

08:41. A user opens what looks like the normal Microsoft 365 sign-in page from a link in a "shared document" email. The URL is almost correct, the branding is perfect, and TLS is valid.

They enter credentials, then approve a push notification. Login appears successful. Nothing looks suspicious.

Behind the scenes, an adversary-in-the-middle proxy has relayed every step to the legitimate identity provider in real time and captured a valid session cookie. The user keeps working. The attacker now has an authenticated session.

Phishing is very much alive as an attack vector, and it is one of the most common initial access methods. MFA is a critical defense, but not all MFA is created equal.

In this article, we will break down how a modern adversary-in-the-middle (AiTM) phishing campaign works, why classic push-based MFA can still be bypassed, and which phishing-resistant controls reduce this risk in practice.

Authentication Factors

The act of authenticating oneself is to prove that you are who you claim to be. In a strictly digital world, this is a non-trivial problem: how can a system verify that the person trying to access it is the legitimate user?

To solve this, we rely on different types of evidence, known as authentication factors. These are categorized into three broad types:

• Something you know (for example, a password or PIN).
• Something you have (for example, a phone, smart card, or security key).
• Something you are (for example, fingerprint or facial biometrics).

Historically, most users authenticated with a single factor: a password.

Unfortunately, simple passwords are vulnerable to a wide range of attacks, and are officially considered a weak control by industry standards. Attackers can easily guess, steal, or brute-force passwords, and once they have one, they can impersonate the user without any further barrier. Cue the next security level:

MFA: Multi-Factor Authentication

Multi-factor authentication (MFA) means combining at least two independent factors during sign-in. Instead of relying only on a password, the user proves identity with additional evidence, which significantly raises the bar for attackers.

That baseline is important, but not sufficient on its own. The exact MFA design determines whether attackers can still manipulate the process.

The Typical Push-Based MFA Flow

You are probably familiar with this MFA flow

This flow combines something the user knows (password) with something they have (phone). It is widely used and supported, and it is a significant improvement over password-only authentication.

However, there is a critical weakness that attackers can exploit: The authenticator app needs to go through the user to approve the request, and it does not have a built-in way to verify the legitimacy of the sign-in attempt.

There are two main attack patterns that exploit this weakness:

1. Social engineering: The attacker tricks the user into approving a fraudulent MFA request, often by creating a sense of urgency or legitimacy.
2. Proxy phishing (Adversary-in-the-Middle): The attacker sets up a fake login page that proxies traffic to the real identity provider. The user completes the MFA challenge in good faith, but the attacker captures valid session artifacts to reuse against legitimate services.

The second pattern is particularly insidious because it does not rely on tricking the user into approving a suspicious request. Instead, the user is completing a real MFA challenge, but through an attacker-controlled relay.

Proxy Phishing (Adversary-in-the-Middle) Attack Flow

In an AiTM setup, the phishing site does not just imitate the login UI. It actively proxies traffic between victim and identity provider. The attacker operates as a live relay in the TLS-protected application flow.

Inspired from: Microsoft Security Blog - From cookie theft to BEC

The URL is the only visible difference between the phishing site and the actual one. This different URL is what also allows an attacker to establish a TLS connection with a valid certificate, which makes the attack even more convincing for users. For instance, look at these two URLs:

• https://login.microsoftonline.com ✅
• https://login.microsotfonline.com ☢️

The domain looks very similar, the page is identical, and the TLS certificate is valid. The user has no reason to suspect anything is wrong.

Proxy Phishing is not a Niche Threat

In January 2026, Microsoft documented a multi-stage AiTM phishing and BEC campaign that abused SharePoint-themed lures to steal sessions and move from initial compromise to business fraud.

The reported pattern was not "spray-and-pray" noise. It combined convincing social engineering, live credential/session interception, and post-login abuse of cloud mail and collaboration workflows.

The tools used by attackers are also not niche ones. Several open-source frameworks have lowered the barrier to running reverse-proxy phishing operations. Take for instance the following popular tools, which are publicly available on GitHub:

• Evilginx2: https://github.com/kgretzky/evilginx2
• Modlishka: https://github.com/drk1wi/Modlishka
• Muraena: https://github.com/muraenateam/muraena

The practical takeaway is that proxy phishing is a real and active threat, and it is not limited to highly targeted attacks. It can be used in both targeted and opportunistic campaigns, and the tools to execute it are widely accessible.

What is Phishing-Resistant MFA and how does it help?

Phishing-resistant MFA is designed so the authenticator is strongly bound to the legitimate client and service origin. In other words, the authenticator is not just asking the user "Do you approve this login?", it is also verifying "Is this login coming from the real app and going to the real service?"

In the previous proxy phishing example, the authenticator would cryptographically validate that the user is signing in from the legitimate client and to the legitimate service before generating a valid response. As the proxy phishing site uses a different URL (i.e. domain) to the legitimate service, the cryptographic check fails and the authentication does not proceed.

Additionally, phishing-resistant MFA strongly mitigates social engineering attacks. Even if an attacker tricks a user into approving a fraudulent login prompt or steals credentials and initiates a fresh authentication request, the attack fails. This is because phishing-resistant MFA requires the user’s authenticator to directly interact with the legitimate client device that is attempting to log in. Since the attacker is operating from a different device, the authenticator rejects the request.

Recommended Phishing-Resistant MFA Options

Phishing-resistant MFA requires three core properties:

1. Cryptographic origin (domain) binding: The authenticator cryptographically binds the authentication response to the exact legitimate domain of the service.
2. Client binding via proximity: The authenticator must be directly bound to, and communicate with, the specific client device that is attempting to authenticate. This is achieved through a direct channel (USB, NFC, BLE, or a secure platform channel). The proximity requirement cryptographically ties the credential to that particular client, preventing remote relay or proxy attacks where an attacker forwards challenges between a phishing site and the victim’s device.
3. Protected secret material: Authentication secrets (private keys) must be hardware-backed and non-exportable, remaining resistant to extraction or replay even if the device or browser is compromised.

In practice, the strongest and most deployable options today are:

1. Hardware security keys (e.g., FIDO2 keys such as YubiKey or Feitian BioPass). These standalone devices store private keys in tamper-resistant hardware and connect directly to the client. This delivers strong origin binding, client binding through physical proximity, and hardware-protected secrets, making them highly effective against phishing, session relay (e.g., AiTM), and credential theft.
2. Built-in device authenticators with hardware-backed credentials e.g., Windows Hello with TPM, Apple Passkeys in Secure Enclave, or Android strong biometric keys). These leverage the device’s secure hardware element to store keys, perform origin-bound signing, and enforce direct client binding. The authenticator and client operate within the same trusted hardware boundary, providing excellent phishing resistance without a separate token.

Wrap-Up

Phishing-resistant MFA is not a "nice-to-have" control. For enterprise environments, especially for highly privileged accounts (for example, global administrators, identity administrators, and emergency access accounts), it should be treated as a mandatory baseline.

This position is aligned with widely recognized security guidance:

• NIST SP 800-63B (Digital Identity Guidelines, Authentication and Lifecycle Management) emphasizes phishing-resistant authentication at higher assurance levels.
• CISA guidance on phishing-resistant MFA recommends prioritizing phishing-resistant methods, especially for administrators and other high-risk users.

The practical conclusion is unambiguous: if your environment has any meaningful risk aversion, phishing-resistant MFA should be implemented as soon as possible for every privileged account. Any identity that can change policies, access sensitive data, or impact business-critical systems should not remain protected by legacy MFA methods. A practical rollout starts with privileged and admin identities first, then expands rapidly across all high-impact user groups.