Adversary-in-the-Middle (AiTM)
Why MFA does not stop this attack
You have MFA switched on, and someone else signs in to your Microsoft 365 anyway. No cracked password, no failed sign-in attempts, no password reset. In an adversary-in-the-middle attack the attacker does not steal your password. He steals the session you are handed after you approve MFA yourself. From that moment on, Microsoft cannot tell him apart from you.
1 in 5
organisations was breached through a fake sign-in page each quarter
44%
of visits to an AiTM page come from outside the corporate network
6 min
is the time within which Attic consistently takes an incident from pickup to verdict
Tiles 1 and 2: Attic AiTM Threat Report 2024-2025, our own detection data from July 2024 to June 2025, covering 1,592 visits and 492 actual clicks. Tile 3: our own measurement on incidents in the beta group, reference date July 2026, with auto-approve.
What is an adversary-in-the-middle attack?
An adversary-in-the-middle attack is phishing where the fake sign-in page is not a copy but a pass-through. The attacker puts a reverse proxy between you and Microsoft. What you see genuinely comes from Microsoft, it just travels through his server on the way.
That means more than your password is intercepted. The whole sign-in goes through: the MFA code or the push you approve, and then the session token Microsoft issues. That token is the proof of access. Whoever holds it is inside, without signing in again.
For Microsoft 365 this weighs heavily, because a single session covers email, SharePoint, OneDrive and Teams at once. Off-the-shelf toolkits such as Evilginx and Modlishka put this kind of proxy within reach of attackers who write no code of their own.
How an AiTM attack unfolds, step by step
The attacker runs a reverse proxy that passes traffic between you and Microsoft. It looks like the real sign-in page, because it is the real page. It simply travels through him.
- 1
A phishing email with a link
A convincing message with a link to what looks like a Microsoft sign-in page
- 2
Credentials entered
Email address and password are typed in. The proxy passes them straight on to Microsoft
- 3
MFA approved
Microsoft asks for MFA. The push is approved or the code entered. That goes through the proxy too
- 4
Session token intercepted
Microsoft issues a valid session token. The attacker catches it
- 5
Signing in without signing in
With that token the attacker signs in. No password needed, no MFA needed
The difference between AiTM and man-in-the-middle (MitM)
The terms get mixed up, but the difference matters in practice. In a classic man-in-the-middle attack the attacker intercepts network traffic, often on an open wifi network, and reads or alters data in transit. HTTPS has largely closed that door.
An adversary-in-the-middle attack sits a layer above it. The attacker stands up a website of his own that acts as a reverse proxy. HTTPS works fine, the certificate is valid, and the padlock in the address bar is there. The target is not the data in transit but the session token issued after MFA succeeds.
Man-in-the-middle
- • Eavesdrops on network traffic
- • Requires network access, such as wifi
- • Largely blocked by HTTPS
- • Targets data in transit
Adversary-in-the-middle
- • Runs its own reverse proxy on a lookalike domain
- • Works through a phishing link, from anywhere
- • HTTPS makes no difference
- • Targets the session token issued after MFA
Why MFA does not stop this attack
Most organisations lean on MFA as their main line of defence against phishing. Against AiTM that line is still there, but it does nothing. The attacker simply waits until you approve, then takes the session.
-
SMS codes, authenticator apps and push notifications do not help here
All three are relayed to Microsoft by the proxy. The attacker does not need to break them, only to forward them
-
One session is access to everything
Reading and sending email for invoice fraud, searching SharePoint and OneDrive, and spreading the attack through the contact list
-
The sign-in itself looks valid
The attacker arrives with a token Microsoft issued. No failed attempts, no password reset
-
It happens away from the office
44 percent of visits to an AiTM page come from outside the corporate network, at home, while travelling, or at a client. Network controls are not watching there
What Microsoft 365 sees of it
Microsoft does see it. The question is where it lands. Replay of a stolen session token arrives in Entra ID Protection as the risk detection Anomalous Token, at risk level Low or Medium. Microsoft's own documentation notes that the detection is prone to noise.
“Anomalous token was historically tuned to incur more noise than other detections. Recent improvements to the detection have reduced the noise; however, there's still a higher than normal chance that some of the sessions flagged by this detection are false positives at low and medium risk levels.”
So the signal is not a red screen that wakes anyone up. It is a line on a list, classified low, among dozens of others. For an IT team with thirty other things to do, that is precisely the signal that gets left.
The same goes for what usually follows the token theft. A forwarding or redirect rule in the mailbox, the classic first move towards invoice fraud, comes in through the alert policy “Creation of forwarding/redirect rule” at severity Informational. And it does not even fire when the rule is created from Outlook on the desktop.
What you can do yourself
No single control shuts AiTM down on its own. These three remove the most, in this order.
Phishing-resistant MFA
Move to FIDO2 keys or passkeys. They are bound to the real domain and simply do not work through a proxy. Start with the administrator accounts, where the gain is largest and the user count smallest.
Conditional Access on device compliance
A stolen token is worthless if it only works from a device you know. Less comfortable for BYOD, but effective. If it will not work across the whole organisation, apply it to part of it.
Someone who looks at the signals
Controls 1 and 2 do not cover everything, and they are never rolled out everywhere at once. What remains is follow-up: someone who picks up the Anomalous Token signal on the day it arrives.
In our own detection data, 21 percent of the AiTM URLs Microsoft had already scanned were visited by a human afterwards anyway. Scanning is not the same as stopping.
What Attic does
Attic MDR is that third control, delivered as a service. We pick up the signals Microsoft classifies low, and we close them out.
Attic MDR runs on your existing Microsoft 365 environment. No extra security tools, no separate agents, no licence upgrade. IVON, the agentic layer of Attic, performs triage on every signal that comes in and investigates what sits underneath: which sign-in, from which IP address, with which token, and what happened in the mailbox afterwards.
IVON advises, Attic acts. On a confirmed token theft, Attic can revoke the session, block the account and remove the forwarding rule, acting on IVON's advice. You receive the incident with its timeline, by email, webhook or push notification in the Attic app. We do not call you.
All 165 Defender XDR alerts that arrived across thirteen connected beta environments in July 2026 were taken up by IVON.
Seven out of ten of those 165 came in at the two lowest levels, Informational or Low.
The AiTM Threat Report
Attic Lab analysed 1,592 visits and 492 actual clicks on AiTM pages between July 2024 and June 2025, based on its own detection data. The report covers when people click, from which kind of connection, on which domain extensions, and how many of those pages turn up at several organisations at once.
Frequently asked questions about AiTM
Related threats
See what is being left in your environment
Attic MDR runs free for fourteen days on your own Microsoft 365 environment. Live within five minutes, cancellable monthly. You see what comes in, how it was handled, and what you would have missed without follow-up.