When MFA Isn't Enough: AiTM Phishing & the Microsoft 365 Cookie Theft Problem
Audience: IT Pros & End Users
Platform: Microsoft 365
Threat Class: Adversary-in-the-Middle (AiTM) Phishing
Series: MFA & Conditional Access
Part: 1 of 7
Telling your users to enable Multi-Factor Authentication (MFA) has been Level 1 IT advice for years — and rightly so. It's one of the most effective defences we have. So imagine the sinking feeling when you discover that an attacker has walked straight past it.
That's exactly what's happening with Adversary-in-the-Middle (AiTM) phishing — a technique that doesn't crack MFA, doesn't brute-force passwords, and doesn't need malware on the victim's device. Instead, it tricks the victim into handing over everything the attacker needs in a single, polished, completely convincing interaction.
⚠️ Why This Matters for UK SMBs
AiTM kits like Evilginx, Modlishka, and Muraena are freely available and well-documented. You don't need to be a nation-state actor to pull this off. Financially motivated criminals are actively deploying these tools against UK businesses using Microsoft 365 — particularly targeting finance, legal, and professional services firms.
A Quick Refresher: How MFA Actually Works
Before we can understand how AiTM defeats MFA, let's quickly recap how MFA protects you in the first place. When you sign into Microsoft 365 normally:
You enter your username and password.
Microsoft's server challenges you for a second factor (Authenticator app push, SMS code, etc.).
You approve the push or enter the code.
Microsoft issues you a session cookie — essentially a digital "you've been verified" sticker that your browser stores.
Every subsequent request to Microsoft 365 uses that cookie. You don't re-authenticate on every click.
💡 Key Concept — The Session Cookie
The session cookie is the crown jewel. Once Microsoft has issued it after a successful MFA challenge, it's proof of a complete authentication. If an attacker steals this cookie, they don't need your password or your MFA code ever again. They can import it into their browser and pick up your session as if they were you.
How AiTM Phishing Actually Works
Traditional phishing steals credentials. AiTM phishing is far more sophisticated — it acts as a real-time relay between the victim and the legitimate Microsoft sign-in page. The attacker sits in the middle, letting the real authentication happen while silently siphoning everything off.
The Traffic Flow
Victim's Browser →→ AiTM Proxy (Evilginx) →→ Microsoft login.microsoft.com
↑↓
[Steals cookie in transit]
↓
Attacker's Browser → Full M365 Access ✓
The victim successfully signs in and sees nothing unusual. The attacker has a fully authenticated session. MFA was correctly completed — by the victim — but the resulting proof of authentication was stolen in transit.
Step-by-Step: The Kill Chain
Step 1 — Phishing Email Lands in the Inbox
The victim receives a convincing email — often a fake "shared document" notification, invoice, voicemail alert, or IT security warning. The link leads to a lookalike domain (e.g. login.microsoft-secure-portal.com) hosted on the attacker's AiTM proxy, complete with a valid TLS certificate. The padlock is there — it just doesn't mean what most people think it does.
Step 2 — Victim Sees a Perfect Microsoft Login Page
The proxy fetches the real Microsoft sign-in page and serves it to the victim in real time. Every pixel looks authentic because it is the authentic page — just relayed through the attacker's server. The victim enters their credentials, which the proxy captures and forwards silently to the real Microsoft servers.
Step 3 — Microsoft Issues a Real MFA Challenge
Because the credentials were real, Microsoft responds with an actual MFA challenge. The proxy relays this back to the victim's browser. The victim sees their normal Authenticator push notification or SMS code request. Nothing looks wrong.
Step 4 — Victim Approves MFA, Completing Authentication
The victim approves the push or enters their code. This is forwarded to Microsoft through the proxy. Microsoft is satisfied — a real user, real password, real second factor. It issues a session cookie.
Step 5 — Proxy Intercepts and Clones the Session Cookie
As the session cookie passes through the proxy on its way to the victim's browser, the attacker's kit makes a copy. The victim gets their cookie and signs in normally, completely unaware.
Step 6 — Cookie Replay: Full Account Access Without Authentication
The attacker imports the stolen cookie into their own browser. Microsoft sees a valid, recently-issued session cookie and grants full access — email, OneDrive, Teams, SharePoint, the whole tenant. No password needed. No MFA needed. From here, attackers typically pivot to Business Email Compromise (BEC), data exfiltration, or lateral movement.
What Attackers Are Actually Using
Several polished, well-maintained tools exist — and some are freely available.
Evilginx
Evilginx is the most widely observed AiTM framework in the wild. Originally created as a penetration testing tool, it functions as a man-in-the-middle reverse proxy with built-in "phishlets" — configuration files that define how to intercept and relay authentication sessions for specific targets like Microsoft 365 and Google Workspace. It handles TLS termination, cookie extraction, and credential logging automatically.
# Simplified Evilginx phishlet structure for M365
name: microsoft
proxy_hosts:
- phish_sub: login
orig_sub: login
domain: microsoft.com
session: true
auth_tokens:
- domain: .microsoft.com
keys: [ESTSAUTHPERSISTENT, ESTSAUTH]
# ↑ These are the M365 session cookies it hunts for
Modlishka & Muraena
Alternative open-source AiTM frameworks with similar capabilities. Muraena has been observed combined with NecroBrowser to automate post-compromise actions on stolen sessions at scale.
Phishing-as-a-Service (PhaaS) Kits
Perhaps most concerning: you can now buy AiTM-capable phishing kits as a subscription service on underground forums. Caffeine, W3LL Panel, and similar PhaaS platforms offer point-and-click campaign management, pre-built Microsoft 365 lures, and automatic cookie harvesting — with no technical knowledge required.
⚡ The W3LL Panel
Discovered by Group-IB in 2023, the W3LL Panel PhaaS kit was responsible for compromising at least 8,000+ Microsoft 365 accounts across 56,000+ corporate emails, generating an estimated $500,000 in criminal revenue. It specifically included an AiTM module targeting Microsoft 365 with pre-built lures designed to bypass spam filters.
Real-World Incidents
These aren't theoretical. AiTM campaigns have caused serious, measurable harm to real organisations — including UK businesses.
Microsoft Threat Intelligence — Large-Scale AiTM Campaign (July 2022)
Microsoft's Security Research team published details of a campaign that targeted over 10,000 organisations using AiTM phishing pages specifically designed to harvest Microsoft 365 session cookies. After gaining access, attackers used compromised accounts within minutes to initiate Business Email Compromise (BEC) fraud — targeting financial contacts at partner companies with fake invoice payment requests.
The speed was the defining characteristic: attackers set up auto-forwarding rules and accessed payment thread emails within 2–5 minutes of cookie theft, then immediately deleted the sign-in alert emails so the victim wouldn't notice.
Impact: 10,000+ organisations, BEC fraud at scale, forwarding rules set on compromised accounts.
Scattered Spider — MGM & Caesars (September 2023)
While US-based, the Scattered Spider threat group's techniques are a masterclass in social engineering combined with AiTM. They combined phishing, SIM swapping, and AiTM to bypass MFA at scale against major enterprises. The MGM incident alone caused estimated losses of over $100 million.
Critically, the UK's National Cyber Security Centre (NCSC) issued specific guidance following these incidents warning that the group's tactics were being adapted and replicated by criminal actors targeting European businesses, including UK financial services firms.
Impact: $100M+ losses, NCSC warnings issued for UK organisations.
UK Professional Services Firm — BEC via AiTM (2023, Anonymised)
A UK-based legal firm with around 150 staff had Microsoft 365 MFA enforced across all accounts. A finance manager received a convincing "DocuSign" email — delivering an Evilginx-backed AiTM page. They signed in, approved the Authenticator push, and thought nothing of it.
Within 4 minutes, the attacker accessed the mailbox, located a live client payment email thread, and modified the bank account details in a reply. The client transferred £87,000 to the attacker's mule account before the fraud was discovered. Only £12,000 was recovered through the banking fraud recall process. The firm faced significant reputational damage and a potential ICO investigation for the data breach element.
Impact: £87,000 lost, 4 minutes from compromise to fraud, ICO notification required.
Nobelium / APT29 — Microsoft 365 Targeting (Ongoing, 2021–Present)
Nobelium — the Russian state-linked group behind the SolarWinds attack — has incorporated AiTM techniques as a standard part of their Microsoft 365 intrusion playbook. They've been documented targeting government supply chains, including contractors and suppliers who interact with UK government departments. Their campaigns are notable for patience: after stealing cookies, they often conduct weeks of passive monitoring before taking any action, making detection extremely difficult.
Impact: Nation-state threat, UK government supply chain targeting, long-term undetected persistence.
Why "Standard" MFA Doesn't Stop This
It's important to be precise here: MFA isn't broken. It still stops the vast majority of credential-based attacks — password spray, credential stuffing, brute force. But AiTM exploits a specific gap: the difference between authenticating the user and trusting the session.
These MFA methods are vulnerable to AiTM because they only verify identity at login time, not on an ongoing basis:
| MFA Method | AiTM Vulnerable? | Why |
|---|---|---|
| Authenticator App Push | ✗ Yes | Cookie issued after approval, stolen in transit |
| SMS One-Time Code | ✗ Yes | Code relayed in real time; also vulnerable to SIM swap |
| TOTP Apps (Google Authenticator, Authy) | ✗ Yes | 6-digit code relayed live; cookie stolen after |
| Voice Call Verification | ✗ Yes | Least secure; also prone to social engineering |
🎯 The Fundamental Issue
All of the above methods verify who you are at the moment of login. They do nothing to verify where the resulting session will be used from. AiTM exploits this gap by letting authentication happen legitimately, then using the resulting proof in an entirely different context.
What Actually Stops AiTM: Phishing-Resistant MFA & Conditional Access
Here's the good news: Microsoft has built the tools to address this problem into Entra ID. The bad news: most SMBs aren't using them because configuration takes effort and often requires higher-tier licensing. Here's what actually works.
Tier 1: Phishing-Resistant MFA
These methods are fundamentally immune to AiTM because they cryptographically bind authentication to the legitimate domain. They cannot be relayed.
✅ FIDO2 Security Keys (e.g. YubiKey)
A physical USB/NFC key that uses public key cryptography. When authenticating, it signs a challenge that includes the domain name. An AiTM proxy on a different domain cannot forge this — the cryptographic signature will fail. This is currently the gold standard for phishing resistance.
✅ Windows Hello for Business
Biometric or PIN-based authentication tied to a specific, enrolled, Entra ID-joined device. The private key never leaves the device's TPM chip. Phishing a Windows Hello session is cryptographically infeasible.
✅ Microsoft Authenticator with Number Matching + Context
Alone, push notifications are AiTM-vulnerable. But with number matching enabled (the user must type the number shown on the sign-in page into the app) and additional context (the app shows the sign-in location and application name), MFA fatigue attacks are significantly harder. Note: this doesn't fully prevent AiTM, but adds meaningful friction and is free to enable today.
Tier 2: Conditional Access Policies
Even if you can't immediately roll out phishing-resistant MFA to everyone, Conditional Access policies in Entra ID give you powerful controls to reduce the blast radius of a successful AiTM attack.
1. Require Compliant Device Effectiveness against AiTM: Very High | Licence: Microsoft 365 Business Premium / Entra ID P1 + Intune
Requires device to be Intune-enrolled and compliant before granting M365 access. An attacker's browser with a stolen cookie will fail this check immediately — the cookie replay attack is stopped cold. This is your single highest-value AiTM mitigation if you have Business Premium licensing.
2. Sign-in Frequency / Token Lifetime Controls Effectiveness: Moderate | Licence: Entra ID P1
Forces re-authentication after a short period. Stolen cookies expire quickly, limiting the attacker's window of access. Doesn't prevent initial compromise, but reduces the damage window significantly.
3. Named Locations — Block Non-UK Traffic Effectiveness: Moderate | Licence: Entra ID P1
Define trusted IP ranges and block sign-ins from unusual geographies. Many attackers use residential proxies in the UK to bypass this, but it stops opportunistic overseas actors.
4. Require Phishing-Resistant MFA Strength Effectiveness: Highest | Licence: Entra ID P1
Enforce that only FIDO2 or Windows Hello is accepted as MFA — standard push notifications are rejected for sensitive applications. This completely defeats AiTM as the authentication method cannot be relayed.
5. Entra ID Protection — Risk-Based Conditional Access Effectiveness: High | Licence: Entra ID P2 / Microsoft 365 Business Premium
Microsoft's ML-driven risk engine evaluates each sign-in. Anomalous properties — new country, impossible travel, anonymising proxy — trigger step-up authentication or an automatic block. A stolen cookie used from an unusual IP is flagged as high-risk and blocked automatically.
Recommended Configuration: Compliant Device Policy
If you can only implement one Conditional Access policy today to address AiTM, make it a compliant device requirement.
Entra ID Admin Center → Protection → Conditional Access → New Policy
Policy Name: "Require Compliant Device - M365 Apps"
Assignments:
Users: All Users (EXCLUDE your Break Glass account!)
Resources: Office 365
Conditions: None (apply to all platforms)
Access Controls → Grant:
☑ Require device to be marked as compliant
Session:
Sign-in frequency: 1 hour (for sensitive roles)
Persistent browser session: Never persistent
Enable Policy: Report-only first → then On
⚠️ Before You Enable
Always create a Break Glass account — a cloud-only, excluded admin account with a very strong password stored securely offline — before enabling any Conditional Access policy. A misconfigured policy can lock everyone out of your tenant, including you.
How to Detect AiTM Attacks in Your Environment
Prevention is essential, but you need to be able to spot when an attack has succeeded.
Entra ID Sign-In Logs
Navigate to Entra ID → Monitoring → Sign-in logs and look for:
Two sign-ins in quick succession from different IP addresses or countries for the same user
Sign-in flagged as using a token from an anonymising proxy or VPN
Impossible travel — user signed in from London, then from Eastern Europe 10 minutes later
Sign-in Risk Level: High — Microsoft's detection may have already flagged it
Microsoft Unified Audit Log
In Microsoft Purview → Audit (or Microsoft 365 Defender), search for:
⚠️ New inbox rules created — especially rules that forward, delete, or hide emails. A classic post-AiTM move.
⚠️ MailItemsAccessed events from an unusual IP or user agent — access without a corresponding sign-in event
⚠️ New delegated mailbox permissions or external email forwarding rules added
⚠️ OAuth app consents — attacker granting a malicious app persistent access
💡 If You Suspect a Compromise
Don't just reset the password — that won't revoke stolen session cookies. You must use Revoke-AzureADUserAllRefreshToken (PowerShell) or the "Revoke sessions" button in Entra ID to invalidate all active sessions. Then reset the password, investigate the audit log, and check for persistence mechanisms like inbox rules and OAuth app grants.
What to Tell Your Users (In Plain English)
Technical controls are essential, but your users are still the first line of detection — and the primary target. Here's a pragmatic, non-fear-mongering message to share with them:
"The padlock doesn't mean the website is genuine." A padlock just means the connection is encrypted — not that the site is legitimate. Microsoft will only ever ask you to sign in at login.microsoftonline.com or login.microsoft.com. Check the full domain carefully.
"If you're asked to approve an MFA push you didn't initiate — decline it immediately and call IT." You should only ever be approving Authenticator requests that you triggered yourself.
"Urgency is a red flag." Phishing lures almost always create false urgency. "Your account will be suspended." "Action required immediately." Pause, question it, and call IT if unsure.
IT Team Action Checklist
Work through these in priority order:
[ ] Enable Authenticator Number Matching — Entra ID → Authentication Methods → Microsoft Authenticator. Enable number matching and additional context for all users. Free. Do this today.
[ ] Deploy Conditional Access — Compliant Device Required — Start in report-only mode for two weeks, then enable. Highest-value AiTM mitigation with Business Premium licensing.
[ ] Enable Entra ID Protection — Configure sign-in risk policies to block High risk sign-ins automatically (requires P2 or Business Premium).
[ ] Pilot FIDO2 Security Keys — Start with finance, IT admins, and directors. YubiKey 5 series, approximately £45–55 per key. These are your highest-value targets.
[ ] Enable Unified Audit Logging — Ensure it's on across your tenant. Set log retention to at least 90 days.
[ ] Configure Safe Links (Defender for Office 365) — Rewrites URLs in emails and can identify AiTM phishing domains at click time.
[ ] Run Phishing Simulations — Use Microsoft Attack Simulator (included in Business Premium) to test user responses to realistic AiTM-style lures.
[ ] Create and document a Break Glass account — Before any Conditional Access deployment. Store credentials offline in a secure location.
[ ] Review OAuth app consents — Entra ID → Enterprise Applications. Remove any unknown or unused third-party app consents that could be attacker persistence.
[ ] Block legacy authentication protocols — SMTP AUTH, POP, IMAP bypass MFA entirely. Use a Conditional Access policy to block legacy auth if you haven't already.
The Bottom Line
AiTM phishing represents a genuine evolution in the threat landscape — one that directly neutralises a control that most organisations have come to rely on.
MFA is not enough on its own. Push notifications, SMS codes, and TOTP apps are all bypassable by AiTM. This doesn't mean you should remove MFA — it means you need to go further.
Compliant device enforcement is your highest-value Conditional Access control. An attacker with a stolen cookie connecting from their own machine will fail a device compliance check cold. This breaks the AiTM attack chain decisively.
Phishing-resistant MFA is the end state to work towards. FIDO2 keys for your highest-risk users — finance, IT admins, directors — should be a near-term priority. Windows Hello for Business gives you the same protection at scale for managed devices.
Detection matters as much as prevention. Audit logging, Entra ID Protection, and knowing what post-compromise indicators to look for are what give you a fighting chance of catching a breach quickly — before £87,000 leaves your client's bank account.
The adversaries targeting UK SMBs are using commercial-grade tooling and well-rehearsed playbooks. The good news is that Microsoft has built equally capable defences into the M365 stack — they just need to be switched on and configured correctly.
The organisations that take AiTM seriously today are the ones that won't be calling Action Fraud tomorrow.
Published by CyberSync UK — Cyber Security Education for End Users, IT Professionals, and the C-Suite. Have questions about your Microsoft 365 security posture? Get in touch at cybersync.uk
Tags: microsoft365 cybersecurity phishing MFA AiTM EntraID ConditionalAccess infosec UKcyber ITsecurity
