AiTM Phishing: SafeLinks + Entra Correlation, Session-Cookie Replay, and Why FIDO2 Wins

AiTM phishing defeats multifactor authentication without ever cracking a password. Instead of stealing credentials to use later, an adversary-in-the-middle attack relays the victim through a reverse proxy in real time and captures the live session cookie the identity provider issues after a successful sign-in, MFA included. The attacker replays that cookie and is already inside, MFA satisfied. This is why password resets and OTP prompts do not stop these attacks, and why detection has to shift from "did someone steal a credential" to "is a valid session showing up where it shouldn't." For the broader playbook this fits into, see investigating identity-based attacks.

How AiTM works

Classic credential phishing harvests a username and password on a fake page, then the attacker tries to use them later, where MFA usually stops them cold. AiTM removes that gap. A reverse-proxy phishing kit (Evilginx is the canonical example) sits between the victim and the real login service. The victim clicks a link, lands on a proxy domain that looks like the legitimate portal, and every request is relayed transparently to the real identity provider.

Step by step:

• The victim enters their username and password. The proxy forwards them to the real IdP and relays the response back. The login looks completely normal.
• The IdP issues an MFA challenge. The victim approves the push, types the OTP, or completes the prompt. The proxy relays the challenge and the response. The attacker does not need to defeat MFA; the victim completes it for them.
• The IdP, satisfied, issues a session cookie (and downstream, refresh and access tokens). The proxy sits in the middle of that exchange, so it captures the cookie in transit.
• The attacker imports the stolen cookie into their own browser. The IdP sees a valid, already-authenticated session and grants access. No password prompt, no MFA challenge.

The critical point: the artifact stolen is the session, not the credential. That is why this is session-cookie theft and token theft, not password theft. Rotating the password does nothing to a session that is already minted. AiTM frequently transitions straight into business email compromise as the follow-on objective, where the attacker uses that live session to read mail, plant forwarding rules, and reach for payment fraud.

This maps to MITRE ATT&CK T1557 (Adversary-in-the-Middle) for the relay and T1539 (Steal Web Session Cookie) for the captured artifact.

Detection signals

No single signal proves AiTM. Each one below is suggestive on its own and routinely fires on benign activity. The detection logic is correlation: AiTM is the hypothesis that explains several of these signals clustering around the same identity in the same short window. Label your evidence as you go.

SafeLinks click telemetry correlated with Entra sign-ins. This is the highest-value signal and the one most teams miss. When a user clicks a phishing link wrapped by Microsoft Defender SafeLinks, the click is logged with the destination URL. Correlate the time and domain of that click with the user's subsequent Entra sign-in. If the user clicked an unfamiliar domain and an interactive sign-in followed within seconds to minutes, that domain is your candidate proxy. Pivot on it: any other users who clicked the same domain are likely in the same campaign.

• Observed: SafeLinks logged a click on login-microsoft-secure[.]com at 14:02; an interactive Entra sign-in for the same user succeeded at 14:03.
• Correlated: three other users clicked the same domain within the hour.
• Assessed: this is an active AiTM campaign against the org. Confidence: high.

A valid session with no fresh interactive authentication. When a stolen cookie is replayed, you see authenticated activity (token use, mailbox access, application calls) that does not trace back to a recent interactive sign-in from that device. A session that "exists" without a corresponding fresh auth event is the cookie-replay fingerprint.

Anomalous token / session-cookie replay. Entra risk detections such as anomalous token, token issuer anomaly, and unfamiliar sign-in properties surface tokens used in ways inconsistent with how they were issued. Treat these as Correlated evidence, not proof; tune for them rather than alerting on each one in isolation.

Impossible travel and new ASN. The captured session is replayed from the attacker's infrastructure, frequently a different country, hosting provider, or autonomous system than the victim. Impossible travel between the legitimate sign-in and the replayed session, or a sudden shift to a hosting/VPS ASN, is a classic supporting signal. Weak alone; strong alongside a SafeLinks click and a no-interactive-auth session.

Signal	Evidence tier	What it tells you	MITRE
SafeLinks click → Entra sign-in on proxy domain	Observed → Correlated	The proxy domain and the campaign	T1557
Valid session, no fresh interactive auth	Observed	Cookie was replayed, not re-authenticated	T1539
Anomalous token / token issuer anomaly	Correlated	Token used inconsistently with issuance	T1539
Impossible travel / new hosting ASN	Correlated	Replay from attacker infrastructure	T1539

The discipline that matters: one signal is a lead, not a verdict. Map each to ATT&CK, label it Observed, Correlated, or Assessed, and state your confidence before you act.

Why FIDO2 / passkeys win

Every MFA factor that AiTM bypasses shares one weakness: it is a shared secret the user can be tricked into handing over. An OTP is a number the user types; a push approval is a tap the user makes. Both can be relayed through a proxy because nothing about them is bound to where the user is authenticating. The proxy domain happily collects them.

FIDO2 and passkeys break this because they are origin-bound. When a passkey is registered, it is cryptographically tied to the exact origin (domain) of the legitimate service. At sign-in, the authenticator checks the origin presenting the challenge and signs a response only for the origin it was registered to. A proxy domain like login-microsoft-secure[.]com is not the real origin, so the authenticator refuses to produce a valid assertion. There is no secret to relay, and nothing the user can be socially engineered into forwarding.

• OTP / TOTP: user reads a code and types it. Relayable. AiTM bypasses it.
• Push / number matching: user approves on their phone. Relayable. AiTM bypasses it.
• FIDO2 / passkey: authenticator signs only for the registered origin. The proxy fails the origin check. AiTM cannot relay it.

This is the difference between MFA that proves a human approved and MFA that proves the human approved on the real site. AiTM is precisely an attack on the gap between those two, which is why phishing-resistant, origin-bound credentials are the only factor that closes it rather than raising the bar.

Remediation

Treat a confirmed AiTM hit as an active session compromise, not a password problem. The eviction order matters, because anything you do before killing the live session leaves the attacker working in real time.

1. Revoke sessions and refresh tokens first. Invalidate the user's active sessions and refresh tokens immediately. A password reset alone is the single most common mistake here: the stolen cookie and any minted refresh tokens keep working regardless of the new password. Kill the session, then the credential.
2. Reset the password and re-register MFA. Only after sessions are revoked. Audit the user's registered MFA methods and remove anything the attacker may have added; attacker-registered MFA is a standard persistence move.
3. Check for BEC follow-on. AiTM's usual objective is the mailbox. Hunt for newly created inbox and forwarding rules, OAuth app consent grants, and anomalous mail access over a rolling window. Work the full BEC investigation guide: eviction is incomplete until forwarding rules, OAuth grants, and registered MFA are all cleaned, not just the password.
4. Scope the campaign. Pivot on the proxy domain from your SafeLinks data and find every other user who clicked it. Block the domain, and treat each click as a potential additional compromise to investigate.
5. Roll users to phishing-resistant MFA. The durable fix is FIDO2 / passkeys, enforced through Conditional Access for high-value roles first. This removes the attack class rather than chasing each incident.

Takeaway

AiTM works because it steals the live session, so detection lives in correlation, not in any one alert, and the only durable defense is origin-bound, phishing-resistant MFA. The hard part is not knowing these signals exist; it is reconciling SafeLinks telemetry, Entra risk detections, and sign-in anomalies fast enough to call it before the attacker pivots into the mailbox, while remembering that "reset the password" is the wrong first move. That correlation-and-judgment work, weighing signals across tools, labeling evidence, and deciding when to revoke, is exactly the human intelligence Cade is built to capture and apply inside the control tower your team already runs.