Blog

"You've Been Hacked" text
Security

MFA Approved the Login. Someone Else Got In.

You open an email, click the link, sign in, tap “approve” on the MFA prompt, and get on with your morning. Everything worked the way it was supposed to. What you don’t see is that someone else stepped into your account at the same moment — using the exact login you just completed.

That catches a lot of business owners off guard, especially the ones who did the responsible thing and turned on multi-factor authentication (MFA) across their cloud accounts. MFA is still worth having. It’s still one of the first things we set up for any client. But this particular attack — Adversary-in-the-Middle, or AiTM — isn’t trying to beat your MFA. It waits for your MFA to succeed, then takes the session you just opened.

Here’s why that distinction matters, and what actually closes the gap.

 

Phishing stopped chasing passwords

For years, phishing had one goal: trick you into typing your username and password so the attacker could use them later. MFA made that a lot less useful — even with your password, an attacker still had to get past a second factor.

So they changed targets. Instead of your password, they now go after the thing that gets created after you log in: your active session. That shift is the whole story behind AiTM.

How an AiTM attack actually works

The fake login page that behaves like the real one

An AiTM phishing page isn’t a static copy of a login screen. It’s a live relay — a reverse proxy — sitting directly between you and the real service, whether that’s Microsoft 365, Google Workspace, or your bank.

Every character you type, every redirect, every response from the real server passes through the attacker’s system on its way to you and back. To you, nothing looks off. The branding is right. The redirects work. The MFA prompt shows up and functions normally — because it is the real prompt, just being passed through.

The only tell is usually the web address. And on a phone screen, or when you’re moving fast between tasks, a slightly-wrong URL is easy to miss.

Why MFA doesn’t stop it

This is the part that surprises people. MFA protects one moment: the act of logging in. It confirms you are who you say you are at that instant. Once you clear it, the service hands your browser a session cookie — a small token that tells the application “this person already proved who they are, let them through.” From that point on, the system stops asking for your password or your second factor. It just trusts the token.

Whoever holds that token holds the access. An AiTM attack sits in the middle, lets you complete MFA, and grabs the token the moment it’s issued.

In plain terms: old phishing stole the key to your door. AiTM lets you unlock the door yourself — then slips in behind you before it closes.

 

What the attacker does with the token

That session cookie works like a bearer credential — like cash. Whoever’s holding it can spend it, no questions asked. The attacker copies your stolen token into their own browser and picks up your session right where you left it. No password, no MFA prompt, no “new login” alert — because from the system’s point of view, nobody new logged in. This is called session replay, or session hijacking.

How common is this, really?

Common enough that the major identity providers are sounding the alarm.

Microsoft’s 2024 Digital Defense Report documented a 146% jump in AiTM attacks over the prior year, alongside an estimated 39,000 token-theft detections per day. A large part of that growth comes from “phishing-as-a-service” kits — Evilginx being the best known — that package the entire reverse-proxy setup into something a low-skilled attacker can rent and point at Microsoft 365 or Google Workspace with very little effort. The barrier to running one of these has dropped a lot.

The Canadian Centre for Cyber Security tracked more than 100 of these campaigns aimed at Microsoft Entra ID accounts between 2023 and early 2025, and used them to make a specific point: phishing-resistant MFA consistently stopped the session theft in cases where standard MFA — push notifications and one-time codes — did not.

What happens after they’re in — and why you don’t notice

The dangerous part of an AiTM compromise is how quiet it is. The attacker is inside a legitimate, verified session, so there’s nothing dramatic in your logs. No failed logins. No “unusual sign-in” alert. No locked account. Standard sign-in monitoring sees a normal, successful login — because that’s exactly what it was.

Research from Proofpoint, backed up by Microsoft’s own incident investigations, shows a consistent playbook once an attacker is inside. They tend to:

  • Create hidden inbox rules that quietly forward or file away certain emails, so you don’t see their activity
  • Register their own MFA method on your account, giving them a way back in even after you change your password
  • Read through email threads looking for invoices, wire instructions, and finance conversations
  • Use your now-trusted account to phish your coworkers, your finance team, or your vendors

This is why AiTM attacks so often surface late — usually after a fraudulent payment, a data exposure, or a wider compromise is already underway. By then, the “login” that started it is buried in weeks-old, perfectly normal-looking logs.

How to actually reduce your exposure

MFA stays. None of this is an argument against it — it’s still the baseline, and it’s still the first thing to get right. But because AiTM targets what happens after login, the controls that move the needle are the ones that extend past the login screen. Here’s where we’d focus, roughly in order of impact.

1. Move to phishing-resistant MFA

FIDO2 hardware keys and passkeys tie your login to both your physical device and the real website address. A proxy in the middle can’t relay them — the login simply fails when the URL isn’t the genuine one. This is the single biggest structural fix, and it’s exactly the gap the Canadian Centre’s research pointed to.

2. Tighten Conditional Access

Policies that require a registered or compliant device mean a stolen token loaded onto an attacker’s unknown machine gets stopped before it ever reaches your apps. Layer in location and risk signals so the system isn’t treating every valid-looking token as permanently trusted.

3. Watch what happens after login, not just the login

Since the sign-in itself looks clean, detection has to live in the activity that follows: new MFA methods being registered, inbox rules created at odd hours, access from unfamiliar places, unusual bursts of data access. Authentication logs alone won’t catch this. It’s the kind of monitoring a managed provider should be doing on your behalf, continuously — not something you’ll spot by glancing at a dashboard once a month.

4. Give your team a 10-minute heads-up

Your people don’t need to become security experts. They need one idea: a working MFA prompt on an unfamiliar-looking page is still a reason to stop and check the address bar. A short walkthrough of what these fake Microsoft 365 logins look like does more than most formal training.

The login screen was never the finish line

MFA is a starting point, not the destination. The businesses that actually shrink their AiTM risk are the ones who understand that identity is built from layers — the login, the session, the token, and the trust the system places in all three — and who put a control around each one, instead of guarding the front door and assuming the rest is fine.

If you’re not sure where your gaps are, that’s worth finding out on a calm Tuesday — not in the middle of an incident.

Want a second set of eyes on your identity setup? Reach out or book a short consultation, and we’ll walk through where the real exposure is in your Microsoft 365 or Google Workspace environment.

FAQ

What is an Adversary-in-the-Middle (AiTM) attack?

It’s a phishing method where the attacker sits between you and the real login service using a proxy, so they can capture your session token in real time — after you’ve already passed MFA.

Can AiTM attacks get around MFA?

Yes, but not by breaking it. They wait for your MFA to succeed, then steal the authenticated session, so no further verification is needed. The MFA worked exactly as designed; the attack just targets what comes after it.

What’s the most effective way to reduce the risk?

Phishing-resistant MFA — FIDO2 keys or passkeys — is the strongest single step, because a proxy can’t relay it. Pair that with device-based Conditional Access, monitoring for unusual post-login activity, and a quick team briefing on checking URLs.

Sources

Microsoft Digital Defense Report 2024 — 146% year-over-year rise in AiTM attacks; ~39,000 daily token-theft detections.

Canadian Centre for Cyber Security, ITSM.30.031 — analysis of 100+ AiTM campaigns against Microsoft Entra ID, 2023–early 2025.

Proofpoint research and Microsoft Threat Intelligence incident reporting — post-compromise behaviors following session hijacking.