MFA isn't enough anymore: adversary-in-the-middle attacks explained.

For years, the answer to almost every SMB cybersecurity question was “turn on MFA.” It was — and mostly still is — the single highest-value control a small business can adopt. But the calculus changed. The most common way we see M365 tenants get broken into in 2026 is not credential theft alone. It's adversary-in-the-middle (AiTM) phishing, and it walks straight through SMS codes, one-time passwords, and even push-approval MFA.

Here's how the attack actually works, why the MFA you've had on for years may not be doing what you think it's doing, and the specific fix that stops it.

How AiTM actually works

A traditional phishing attack tricks the user into typing a password into a fake site. Add MFA and the fake site is useless — the attacker has the password but can't get the code.

AiTM changes the picture. Instead of a fake login page that looks like Microsoft, the attacker's site is a real-time proxy to the actual Microsoft login page. When the user clicks the phishing link:

1. The user lands on the attacker's server, which invisibly relays every request forward to login.microsoftonline.com.
2. The user sees the real Microsoft login page — because it is the real page, being piped through the attacker.
3. The user enters her password. The attacker forwards it. Microsoft accepts it.
4. Microsoft challenges for MFA. The user gets the real push on her phone. She approves it.
5. Microsoft sends back an authenticated session cookie. The attacker's proxy captures that cookie.

The user gets logged in and never notices anything wrong. The attacker now has a copy of the session cookie — the thing that proves to Microsoft that MFA already happened. They plug it into their own browser, and they're inside the mailbox, no MFA prompt required.

This is not theoretical. Microsoft's own threat research on AiTM phishing documented the pattern in production several years ago. The kits (Evilginx, EvilProxy, Mamba 2FA, Tycoon) are cheap, easy to run, and now built into commodity phishing-as-a-service platforms.

Why your current MFA probably doesn't stop it

Not all MFA is equal. Look at the common flavors:

• SMS text codes. The attacker's proxy just forwards the code, exactly like the password. AiTM doesn't care whether the second factor is a code, a push, or a smoke signal — if it goes through the browser session, it goes through the proxy. Also vulnerable to SIM-swap. NIST has been recommending against SMS for anything sensitive since the last major update to SP 800-63B.
• App-based one-time passwords (TOTP). Same problem — the code goes through the browser session and gets proxied. TOTP stops replay attacks; it does not stop live proxying.
• Standard push notification (“approve or deny”). Same problem. Also vulnerable to “MFA fatigue” where the attacker just spams push prompts at 3 AM until someone taps yes.
• Number-matching push (user types the number shown on the login screen into the app). Better against MFA fatigue, still vulnerable to AiTM — the attacker's proxy shows the user the exact number the real login is requesting.

Everything above shares the same weakness: it happens through the browser session. The attacker just has to sit between the browser and the login page.

What actually stops AiTM: phishing-resistant MFA

The class of MFA that defeats AiTM is called phishing-resistant, and it works by binding the authentication to the real domain the user is on. If the browser is on a proxy that isn't login.microsoftonline.com, the authentication simply doesn't work — the cryptographic handshake refuses to complete.

Two practical options for SMBs in 2026:

1. FIDO2 hardware security keys

Small USB or NFC devices (YubiKey, Feitian, Google Titan, and others). When you sign in, you tap the key. The key does a cryptographic exchange with the site that is bound to the site's real domain. On a phishing proxy, the domain doesn't match, and the key refuses.

Hardware keys are the strongest option. For anyone with financial, admin, or clinical authority, they should be the default. See CISA's guidance in Implementing Phishing-Resistant MFA.

2. Passkeys (built into the phone / laptop)

Passkeys are FIDO2 credentials stored in the operating system's secure enclave (Apple Passkeys, Windows Hello, Google Password Manager) instead of a separate hardware key. Same phishing resistance, no extra hardware to buy or lose. Both Microsoft and Google now support passkeys for corporate identities, and adoption has moved from “bleeding edge” to “the recommended default” over the last 18 months.

Passkeys are the practical way to roll phishing-resistant MFA to a whole workforce without shipping every employee a physical key.

What if we can't switch everyone tomorrow?

Fair — most SMBs won't ship 40 hardware keys in a week. Fortunately, there are layered controls that meaningfully reduce AiTM risk while you migrate:

• Enforce Conditional Access with device compliance. Require sign-ins from managed, compliant devices only. An attacker with a stolen cookie doesn't have your Intune-enrolled laptop, so Conditional Access blocks the token replay. This is one of the highest-ROI hardening steps in Microsoft 365 you can make this week. See Microsoft's Conditional Access overview.
• Set short token lifetimes and require reauthentication for risky actions. A stolen cookie is only useful until it expires. Reasonable session lifetimes (a few hours, not weeks) sharply reduce the window of exposure.
• Turn on token binding / Continuous Access Evaluation. Microsoft can revoke sessions in near-real time when risk signals fire (impossible travel, sudden IP change). This shortens the useful life of a stolen cookie further.
• Monitor for anomalous sign-ins. The stolen-cookie login almost always comes from a different IP, ASN, and device fingerprint than the user. A SOC watching Entra ID sign-in logs will catch this. Nobody watching = nobody catches it.
• Kill legacy authentication. Basic Auth and older protocols bypass MFA entirely. Disable them tenant-wide if you haven't yet.
• Prioritize the high-value accounts first. If you only have 10 hardware keys, put them on your finance team, your admins, and your executives. Get to the rest with passkeys over the next quarter.

The North Carolina angle

Every Charlotte-area BEC case we've investigated in 2026 that involved a takeover of a Microsoft 365 mailbox started with an AiTM phish where MFA was on but not phishing-resistant. The victim usually reports the same thing afterward: “But I approved the push. I thought that meant it was safe.” The push was real; the login page it authenticated was not. If your practice, firm, or business is in NC, this is the specific gap to close before the next tax season and wire cycle.

What WHT recommends

A 30-day path from “MFA is on” to “phishing-resistant across the accounts that matter”:

1. Week 1: Inventory MFA methods. In Entra ID (or your IdP), pull a report of which users are on SMS, TOTP, push, or phishing-resistant methods. Almost always eye-opening.
2. Week 2: Roll passkeys to the workforce. Enable passkey registration for all users. Communicate simply: “Set this up before Friday. Takes 90 seconds.” Passkeys don't require new hardware for most modern devices.
3. Week 3: Ship hardware keys to critical roles. Executives, finance, admins, clinical leads. Two keys per person (primary + backup). Enroll and enforce.
4. Week 4: Turn on Conditional Access and disable weaker methods. Require compliant devices, kill SMS as a permitted second factor for admins, disable legacy authentication, set reasonable token lifetimes. Point your SOC (or MDR provider) at Entra ID sign-in logs with alerts on impossible-travel and token-anomaly signals.

None of the four weeks costs a fortune. What costs a fortune is what happens the week after an AiTM phish succeeds against SMS-based MFA on the CFO's account.