AiTM Phishing

AiTM phishing is a phishing attack in which a proxy sits between the user and the real login service, relaying the session in real time. The victim signs in and completes MFA successfully. The attacker captures the session cookie the identity provider issues and replays it to enter the account as that user.

Adversary-in-the-middle phishing has a reputation for beating multi-factor authentication. That reputation is misleading, and the misunderstanding is expensive.

This page covers four things the explainers leave out: what is actually stolen, why the detections you built from the standard framework mapping stayed quiet, what the circulating scale numbers really measure, and which control closes the gap, including where it does not reach. Every claim carries the identifier of its source, so you can check it yourself.

Explain It Like I'm 10

Think of a concert with a strict door check. You show your ID, the guard checks it properly, and they wrap a paper wristband around your wrist. The wristband is what gets you back in later, and nobody checks your ID again once you have it.

Now imagine someone standing between you and the guard, passing your ID back and forth. The check still happens, and it still passes. But the wristband ends up on their wrist, not yours.

AiTM, MITM, and why the name matters

The letters stand for adversary-in-the-middle, a neutral replacement for "man-in-the-middle". Both names describe an attacker positioned between two parties who believe they are talking directly. The similarity ends there, and the difference matters more than a naming preference.

A classic MITM attack is about network position. The attacker has to get onto the path: poisoning name resolution on a local segment, spoofing ARP replies, running a rogue access point. AiTM phishing needs none of that. The victim walks into the relay voluntarily by clicking a link, and the relay is a web server on the public internet that the attacker rents like any other.

That difference is not trivia. It is the reason, later on this page, that a large part of the standard detection guidance for this attack cannot observe it.

The advice that does not survive the data

It also breaks the most common piece of advice given about AiTM phishing, which is to check the address bar for a misspelled domain. The Canadian Centre for Cyber Security studied over 100 AiTM campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025, and found that LOTS-based AiTM phishing, meaning phishing that lives off trusted sites, made up over half of the campaigns it could categorise. In those campaigns the link to the phishing site sits inside a file hosted on SharePoint, Dropbox or a similar provider. There is no misspelling to notice, because the domain the user is asked to trust is one they already trust.

How AiTM phishing actually works

The mechanism is straightforward and most explainers cover it adequately. The attacker stands up a site that relays traffic to the genuine login service, the user authenticates against the real service through that relay, and in the Cyber Centre's description the action "returns a validated token and session cookie to the AitM site".

Three details get much less coverage, and all three change what a defender should expect.

The session is deliberately made to last. MITRE's catalogue entry for the best-known open-source framework in this class, evilginx2, records that it "injects custom POST arguments to silently enable 'Remember Me' options during authentication". The practical effect is a longer-lived cookie and a wider replay window than the user's own choices would have produced.

A reverse proxy is not the only shape. This is the mental model almost every explainer teaches, and Microsoft's own incident reporting contradicts it. Describing a campaign it attributed to Storm-1167, Microsoft wrote that "unlike campaigns we have previously reported, this attack did not use the reverse proxy method", using an indirect proxy method instead. If your detection logic assumes a relayed copy of the real page, that assumption has already failed once in a documented campaign.

What the session gets used for is usually email. In the Cyber Centre's corpus, business email compromise accounted for 91% of the analysed campaigns. This is not generic account takeover; it is overwhelmingly a route into a mailbox.

Your MFA is not broken

The framing in circulation gets this backwards.

The MFA challenge in an AiTM attack is not defeated, evaded or downgraded. It is completed correctly, by the legitimate user, against the legitimate service. What the attacker takes is what the identity provider issues after the challenge succeeds.

Microsoft put it in exactly those terms when it first documented the technique at scale in July 2022: "this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user's behalf, regardless of the sign-in method the latter uses."

If you rolled out MFA and were later compromised this way, the rollout was not the mistake. The gap is in what happens to the credential the rollout produces.

What the numbers actually say

Three figures circulate about this attack. Two are reported in the wrong unit, and the third points in a direction the coverage rarely mentions.

The 35,000-user campaign. In May 2026 Microsoft published an analysis of a campaign running from 14 to 16 April 2026, described as "targeting more than 35,000 users across over 13,000 organizations in 26 countries", with 92% of targets in the United States. Aggregator coverage renders this as 35,000 users "hit", and in at least one headline as 35,000 logins "hijacked". Those are different claims. Microsoft published a targeting count. It published no compromise count for that campaign at all, so the number of accounts actually taken is not in the public record.

The founding 10,000-organization figure. The same unit problem is four years old. Microsoft's July 2022 report says the operation "attempted to target more than 10,000 organizations since September 2021". Attempted to target. It is a reach figure, and it is frequently quoted as though it counted victims.

The speed figures need the same care. The 2022 report's "as little time as five minutes" between session theft and follow-on fraud is a fastest-observed case, not a typical one; in the 2023 Storm-1167 campaign the attacker replayed the cookie "after a few hours".

The trend that runs the other way

The third number is the interesting one.

Across its corpus, the Cyber Centre reports that full-session compromises fell from almost 20% at the end of Q3 2023 to less than 10% of all compromises by early 2025. Controls are working, and the share of compromises that end as a fully authenticated attacker session has roughly halved.

Two caveats belong in the same breath. That dataset is Canada-weighted, at 77% Canada and 18% United States, so it is not a global measurement. And it is a share of compromises, not a success rate against attempts: it says what fraction of the incidents that occurred were full-session takeovers, not what fraction of phishing emails worked. Converting one into the other would be a mistake.

The mapping problem, and why your detections were quiet

If you mapped an AiTM incident to T1557 Adversary-in-the-Middle, you did the reasonable thing. MITRE maps evilginx2 to that technique itself, among the fourteen techniques listed on its software entry. The mapping is not wrong.

It is incomplete, and the gap has a detection consequence that is easy to check.

T1557 decomposes into four sub-techniques: Name Resolution Poisoning and SMB Relay, ARP Cache Poisoning, DHCP Spoofing, and Evil Twin. Every one of them requires local network position. Its detection strategy DET0296 follows from that. The analytics beneath it, AN0823 through AN0826, look for DNS and ARP poisoning, unauthorised edits to `/etc/hosts` and `/etc/resolv.conf`, suspicious ARP broadcasts, certificate trust changes and route injection. Its listed mitigations are network segmentation, network intrusion prevention and traffic filtering.

None of that observes a web server on the public internet that a user chose to visit.

The other two techniques have the same problem

T1539 Steal Web Session Cookie is the right conceptual home, and its description explicitly names frameworks that "gather session cookies through a malicious proxy". But its detection strategy, DET0509, is titled for file, memory and network artifacts, and four of its five analytics describe endpoint theft: reading Chrome's `Cookies` SQLite database, accessing browser memory through `/proc/[pid]/mem` or ptrace, `task_for_pid` calls on macOS, macros reading browser file paths. In an AiTM attack none of that happens. The cookie is never read off the victim's disk, because the identity provider issues it through the proxy. Only the fifth analytic, AN1406, fits, and it describes the replay rather than the theft.

T1111 Multi-Factor Authentication Interception is further away still. Its analytics, AN0687 through AN0689, describe keyloggers, `/dev/input` access and smart card proxying.

The technique that actually fits

The technique whose analytics do fit is T1550.004 Web Session Cookie. Its detection strategy DET0074 carries three analytics that describe this attack precisely: AN0201, anomalous access to cloud applications using session tokens without MFA validation; AN0202, session cookie reuse on unmanaged browsers or devices deviating from user baseline; and AN0203, web session tokens reused in native Office apps without an associated token refresh.

Its tactic is Lateral Movement. The detection that fits a phishing attack is filed where most teams would never think to hunt for one.

The same page records the company this puts you in. MITRE lists Star Blizzard, the Russian espionage group also tracked as SEABORGIUM, Callisto and COLDRIVER, as having "used EvilGinx to steal session cookies and bypass MFA" against academic, defence, government and NGO targets in NATO countries.

Why your email security passed the link

The second uncomfortable question after an AiTM incident deserves a documented answer rather than a shrug: the link went through a scanner, and the scanner said it was fine.

MITRE's entry for evilginx2 lists the behaviours that produce that outcome. Each one tells a defender what a clean scanner verdict is actually worth.

• Requests are filtered by user agent. The framework "rejects requests if User-Agent doesn't match allowlist REGEX filter" (T1480). A scanner that does not look like the intended victim may simply not be shown the phishing content.
• The lure is time-gated. It "hides phishing lures for set time to avoid sandbox scanning" (T1497.003). A link that is inert when detonated can be live when the user clicks it.
• The link itself resists static matching. Parameters are randomly generated and Base64 encoded "to defeat static detection" (T1132).
• The certificate is valid. The framework obtains a genuine TLS certificate from a free certificate authority via ACME (T1553.004). The padlock is real, and it always was: it certifies the connection, never the intent.

The trusted-hosting finding points the same way. A clean verdict from a scanner is a statement about what the scanner was shown, not a statement about the link. Where the lure is a file on a service your organisation already trusts, domain reputation is working for the attacker as well.

What to actually do, and where it stops

The Cyber Centre states the fix in one sentence: both phishing-resistant MFA and registered-device conditional access policies "break the authentication flow when there is an AitM phishing kit in the middle of the connection". CISA's guidance ranks FIDO/WebAuthn and PKI-based methods at the top of its strength hierarchy for the same reason. The relay cannot complete an authentication that is cryptographically bound to the real origin.

Here is where that recommendation stops, because a control offered without its edges is not much use to whoever owns the policy.

The four places it stops

The fallback is the hole. The Cyber Centre's own next instruction is to "remove any non-phishing-resistant backup methods on these accounts". Deploying a security key while leaving SMS enabled leaves the weaker path available.

And that path has a documented route to it. Proofpoint researcher Yaniv Miron disclosed a downgrade technique in August 2025 in which an attacker spoofs a user agent that Entra ID's FIDO implementation does not recognise, producing an error that invites the user to pick a different method, and landing them on the authenticator app, an SMS code or an OTP. Proofpoint reported observing no cases of the technique in the wild at the time of disclosure, and Microsoft's position is that it is not a product vulnerability but a phishing attack, answered by enforcing phishing-resistant methods through Conditional Access authentication strength.

One correction runs the other way. The most widely cited "passkeys were defeated" story, the PoisonSeed campaign of July 2025, was subsequently assessed as not a FIDO bypass at all: the password factor passed, the later challenges failed, and the proximity check in the cross-device flow held.

Token binding does not yet cover the browser. Microsoft's Token Protection is a Conditional Access session control that accepts only device-bound sign-in session tokens, so a stolen token "can't be used from another device". It is the most direct answer to replay that exists. Its coverage is the catch. Native application support is generally available on Windows and in preview on macOS and iOS. Browser-based support is preview only, and limited to selected web apps that access Azure Resource Manager. AiTM phishing is a browser attack. Microsoft's own guidance is to deploy the policy in report-only mode first and analyse both interactive and non-interactive sign-in logs before enforcing.

Revocation has a hard limit. Microsoft Entra ID "can't directly revoke a session token issued by an application"; the application has to revoke access under its own policies. Continuous Access Evaluation narrows this for services that support it, revoking tokens in near real time on events like account disablement and password changes, but it needs support at both the client and the resource.

What this page does not know

No global prevalence figure for AiTM phishing exists in citable form. The Cyber Centre corpus is the best public measurement available, and it is Canada-weighted. Neither headline campaign has a published compromise count, only a targeting count.

MITRE publishes detection analytics, not their catch rates or false-positive profiles. AN0201 through AN0203 describe the right signals; how noisy they are is something only your environment can tell you.

One disclosure. Most of page one for this topic is written by security vendors, several in categories that sponsor this site. None is cited here, because every load-bearing claim has a government, standards or first-party source. The exception is the downgrade research above, which is vendor-originated, attributed in the sentence, and used as evidence against this page's own recommendation.

One more time, because it is the point most worth keeping: an AiTM compromise is not evidence that your MFA was a bad decision. It is evidence that the session it produces needs protecting too.

Frequently asked questions

Does AiTM phishing mean MFA is useless? No. The MFA challenge succeeds; it is not evaded. What gets stolen is the session issued after it succeeds. Microsoft's own wording is that this "is not a vulnerability in MFA". The upgrade path is to phishing-resistant methods, not away from MFA.

Why did my sandbox say the link was safe? Because it may not have been shown the same content the user was. Documented behaviours in this tooling include filtering requests by user agent and hiding the lure for a set period to outlast sandbox analysis. A clean verdict describes the scanner's experience, not the link.

Do passkeys stop AiTM phishing? They break the relay, because the authentication is bound to the real origin and a proxy cannot satisfy it. Two caveats: leaving a weaker fallback method enabled preserves a path around them, and a downgrade technique that forces exactly that fallback has been disclosed, though not observed in the wild at disclosure.

What should I hunt first? Session reuse: an authenticated session appearing from an unmanaged device or browser that does not match the user's baseline, and cloud application access using a session token with no corresponding MFA validation.

Where to start

Three checks, in order, none of which requires a purchase.

Read the analytics that fit. Open T1550.004 and read AN0201, AN0202 and AN0203. If your detection content was built from T1557, this is the gap.

Test whether you could see it. Take a recent legitimate sign-in and ask whether your logs would have surfaced that same session reappearing from an unmanaged device an hour later. If the answer is no, that is the work.

Check the control's reach before planning around it. Find out whether Token Protection covers the applications your users actually live in, or whether the browser sessions that matter fall into the preview gap.

The attacker never needed your password to stay useful, and never needed to beat your second factor. They needed the thing your identity provider handed out once both of those went right. That is the object to protect, and it is the one most detection programmes are not yet watching.