Last week we packed up the laptops, grabbed some sandwiches and headed over to one of our structural engineering clients for a lunch & learn. The topic? A type of attack that’s catching out even careful, security-aware businesses right now: the Adversary-in-the-Middle (AiTM) attack. Here’s the same session, written up for everyone else.
“But we’ve got MFA…”
That was the first reaction in the room — and it’s a fair one. Multi-factor authentication (MFA) is one of the best things you can turn on, and you absolutely should. But AiTM attacks are designed specifically to walk straight past it, and that’s exactly why they’re worth understanding.
What is an Adversary-in-the-Middle attack?
In a normal phishing attack, the crook builds a fake login page, you type your password into it, and they steal it. MFA usually saves you, because the attacker still doesn’t have your one-time code.
AiTM is cleverer. Instead of a static fake page, the attacker sets up a relay — a server that sits invisibly between you and the real Microsoft 365 login. When you click the link:
- You see what looks like the genuine login page (because the relay is quietly passing the real one through to you).
- You enter your password and approve your MFA prompt — and the relay forwards both to the real site, so you’re logged in as normal and notice nothing.
- In the background, the attacker steals the session token Microsoft hands back — the digital “wristband” that says “this person is already logged in.”
With that token, they can step into your account without needing your password or MFA again. From there it’s usually straight to your inbox — reading messages, setting up sneaky forwarding rules, and lying in wait to hijack an invoice or a payment. For a business that emails quotes and project payments around, that’s a serious problem.
A recent one we saw
This isn’t theoretical — we walked the room through a live example we’d dealt with not long before. It didn’t come from a stranger or an obvious dodgy address. It came from one of the client’s own suppliers — a real person they spoke to regularly, working on a real project together.
The email was simply a shared file, referencing the very project they were collaborating on. Everything about it fitted: the right name, the right context, the right tone. The only thing that mattered was the link inside it — that was the trap. Click through, “sign in” to view the document, and you’d have handed over your session to the attacker.
What made it so dangerous is exactly what made it convincing: the supplier’s own mailbox had almost certainly already been compromised, so the message came from a genuine, trusted account. That’s the pattern with AiTM — one breach quietly becomes the next, hopping from business to business along the supply chain. It’s a powerful reminder that “I know the sender” isn’t the same as “this is safe.”
How we shut it down
Here’s the part that matters: it didn’t end in a breach — and that’s entirely down to having layers in place. Because the sign-in arrived with the right password and a satisfied MFA prompt, the Conditional Access policies in our security blueprint saw what looked like a valid login and let it through. That’s exactly the blind spot AiTM is built to exploit, and on its own it would have been game over.
The save came from the next layer down. The instant the attacker tried to use the stolen session, our 24/7 SOC, powered by Huntress, spotted the very same account suddenly logging in from the United States — flagged the impossible login and locked the account on the spot, before a single email could be read or a forwarding rule slipped in. Threat contained, client unaffected.
That’s the whole case for defence in depth: no single control is perfect, so you stack them. When one layer is bypassed, the next one is there to catch it.
How to spot one
The whole point of AiTM is that it looks normal — but there are still tells. We coached the team to pause on:
- The link, not the look. A login page can look perfect; the web address can’t lie. Always check the URL is genuinely login.microsoftonline.com and not a lookalike or a string of odd characters.
- Unexpected login or MFA prompts. Being asked to sign in again out of the blue — especially from a link in an email — is a red flag.
- The usual phishing cues. Urgency, a “shared document” you weren’t expecting, a voicemail or fax notification, or a sender address that’s subtly wrong.
- Anything that feels off. We’d always rather have someone forward us a suspicious email than click and hope.
How to defend your business
Awareness is the first layer — but the real protection is technical, so that one wrong click doesn’t become a breach. The defences we recommend, and put in place for clients, include:
- Phishing-resistant MFA. Passkeys, Microsoft Authenticator with number-matching, or hardware security keys are tied to the real website and can’t be relayed — this is the single biggest step against AiTM.
- Conditional Access policies. Restricting sign-ins to known, compliant devices and trusted locations means a stolen token from an unknown laptop in another country simply doesn’t work.
- Token protection and shorter sessions. Binding sessions to a device and re-checking risk continuously shrinks the window a stolen token is useful for.
- Email and link protection. Filtering that detonates and checks links helps stop the message landing in the first place.
- Monitoring and alerting. Watching for impossible travel, new forwarding rules and risky sign-ins means we catch a hijacked account fast — and shut it down.
Why we run lunch & learns
Tools do the heavy lifting, but your team is the layer that meets these attacks first. An hour over lunch — real examples, no jargon, plenty of questions — does more for everyday security than any policy document. Our structural engineering client left able to describe an AiTM attack to a colleague, which is exactly the point.
If you’d like the same for your team, we’d love to bring the sandwiches.