adversary-in-the-middle phishing proxy stole session cookie and impossible travel alert did not trigger

TL;DR

Assume the session itself is stolen and defend the session: enable token protection and Continuous Access Evaluation where your clients support them, shorten session lifetimes for sensitive apps, require compliant devices for admin and finance roles, and hunt for the proxy sign-in pattern, a successful MFA followed by a new IP or ASN using the session, rather than waiting for impossible travel, which often stays silent when the proxy is geographically close to the victim.

adversary-in-the-middle phishing proxy stole session cookie and impossible travel alert did not trigger

Use this when

• A user entered credentials and MFA on a proxied login page and the attacker replayed the session.
• Impossible travel or risk alerts did not fire for the replayed session.
• Sign-in logs show the victim session continuing from an unfamiliar IP or hosting provider.

Not for this skill when

• The attacker used only a stolen password and was stopped by MFA. That is a different, better outcome to reinforce.
• A user device is lost or stolen with live sessions. That is a device incident with its own revocation steps.

Steps

1. From the victim sign-in, trace the session: the authentication IP, the following resource access IPs, and the ASN or hosting provider behind any change. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the session timeline shows where control passed to the proxy
2. Revoke the victim sessions and refresh tokens, reset credentials, and check for mailbox rules, new MFA methods, and app consents added during the session. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the account shows revoked sessions and no attacker persistence remains
3. Enable token protection for supported apps and roles, starting with administrators and finance, and monitor sign-in failures it causes in report mode data. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: token protection is listed as enabled for the pilot group
4. Tighten session controls for sensitive apps: sign-in frequency and compliant device requirements in Conditional Access. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the updated policies show the new session settings in the portal
5. Write a detection query for the proxy pattern, successful sign-in followed by resource access from a hosting ASN, and schedule it as a recurring hunt. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the hunt query runs and is saved with the incident notes

Why it happens

AiTM proxies sit between the user and the real identity provider, passing through credentials and MFA and keeping the resulting session cookie. Because the sign-in genuinely succeeded, controls that grade the sign-in moment see a compliant event. Impossible travel compares locations, and a proxy hosted near the victim or in the same cloud region defeats that comparison. Defence has to bind the token to the device and evaluate the session continuously, not admire the login.

Variants and edge cases

adversary in the middle phishing proxy stole session cookie impossible travel no alert

The full incident wording with the silent control.

aitm phishing session cookie replay detection token protection

The control focused variant naming token protection.

phishing proxy bypassed mfa session hijack entra fix

The MFA bypass phrasing users search after the shock.

Compatibility: Microsoft Entra ID token protection, Continuous Access Evaluation, Conditional Access session controls, Defender hunting.

Edge cases to check:

• Reverse proxy kits target the biggest brands first; prioritise the apps your executives and finance team use daily.
• User education still helps: AiTM pages arrive from links, so reporting culture shortens the session lifetime attackers get.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RgblC3kSmHaq6cElMpHjtQ