MITM: How Attackers Walk Right Through Your MFA (and What Actually Stops Them)
TL;DR:
A MITM (Man-in-the-Middle) attack is real-time fraud. An attacker sits between you and the website you're trying to use, copies what passes through, and logs in as you.
Think of it like a scammer who's set up a fake drive-through window right before the real one. You hand your card and your order to the fake window. They copy it, pass it through to the real window. You get your burger, the restaurant charges your card, everyone seems happy. The scammer now has your card too.
On a good day, your login goes straight to Microsoft, your MFA prompt only fires when YOU sign in, and your browser knows when it's on the real site. On a bad day, you click a link in an email, land on a page that looks right, type your password, and tap "Approve" when your phone buzzes. Your password was right. Your MFA worked. The attacker was just standing at the window the whole time.
Beyond the Basics:
Here's what actually happens during a MITM attack. Fair warning up front: Microsoft and CISA now call this "AiTM" (Adversary-in-the-Middle). Same concept, more specific terminology — the "man" in the middle is a server, not a person, and it's not eavesdropping on the network, it's impersonating a login page.
The attacker runs a transparent proxy — a server that sits between the user and the real website (typically login.microsoftonline.com). Tools like evilginx make this close to turnkey. When the victim clicks a phishing link, they land on the attacker's proxy, which dynamically fetches and displays the real Microsoft login page.
Everything the user types gets copied in real time. Four steps, all automatic:
- User enters credentials on the proxy. The proxy forwards them to Microsoft, which treats it as a normal login attempt.
- Microsoft sends an MFA challenge. Push notification, TOTP, SMS — doesn't matter which. The credentials checked out, so Microsoft happily issues one.
- User approves the MFA. The proxy captures both the MFA response AND the session cookie Microsoft issues in return. That session cookie is the actual prize — it represents a fully authenticated session.
- Attacker replays the cookie. From their own machine, they paste it into their browser. Microsoft sees a valid session. No re-authentication. They're in.
This is why calling it "MFA bypass" is a little misleading. The MFA worked correctly. Microsoft correctly verified the user. The attacker just stood at the wire and copied the resulting session cookie — which is indistinguishable from a legitimate one.
Three controls stop this cold:
- Managed-device enforcement. Conditional Access in Entra ID can require that every authenticated session be presented from a device the tenant has enrolled — via Intune (Windows, iOS, Android), Apple Business Manager (macOS, iOS), or Android Enterprise. The attacker's machine is not enrolled. Even with a valid session cookie, the request gets blocked at the door.
- Phishing-resistant MFA. FIDO2 security keys, Windows Hello for Business, and passkeys are bound to the site's origin. The credential refuses to respond to the attacker's proxy domain — the cryptographic handshake fails before anything is sent. (See the FIDO2 techsplainer for the mechanics.)
- Conditional Access risk signals. Entra ID evaluates location, device state, user risk, and session risk continuously. An impossible-travel signal — user in Utah, session cookie replayed from Moldova 30 seconds later — can trigger a step-up re-authentication or block the session outright.
Any one of these would have stopped the attack. Having all three is defense in depth. Running traditional MFA alone, by itself, is not enough anymore.