Eighteen seconds between two continents.
How a Microsoft 365 Conditional Access geo block silently fails when the attacker brings their own session cookie, and the policy change that closes the gap.
A user’s Microsoft 365 account signed in from a city on the U.S. east coast. Eighteen seconds later, the same account signed in from a city in South America. The customer’s tenant had a Conditional Access policy with an explicit geo block on every country outside North America. The geo block did not fire.
This is the story of why.
What we expected to find
When we first surfaced the sign-in pair in the customer’s audit log, our assumption was that the CA policy had been silently disabled. A misconfigured policy that “applies to all users” but accidentally has the All Users group excluded is a finding we see weekly. The fix is usually as simple as removing the exclusion.
We checked. The policy was enabled. Excluded users: zero. Excluded groups: zero. Target apps: all cloud apps. Grant control: block.
The policy was perfect.
What actually happened
Microsoft Conditional Access evaluates policies against sign-in claims — the set of facts about the current sign-in attempt. One of those claims is the location of the sign-in, derived from the IP address. Another is whether the user already has an active session that previously satisfied MFA and CA grants.
When the attacker phished the user via an adversary-in-the-middle (AiTM) kit, the user typed their password into the fake login page, completed MFA on the fake login page, and the kit relayed both to the real Microsoft sign-in endpoint in real time. The MFA challenge was solved by the real user. The kit captured the resulting session cookie.
The session cookie is what Microsoft hands you after a successful interactive sign-in. It says, in effect: “This user is signed in. The MFA was satisfied at [timestamp]. The Conditional Access policies evaluated at sign-in were satisfied. Honor this until it expires.”
When the attacker replayed that cookie from their South American IP, Microsoft’s sign-in pipeline did not treat it as a NEW sign-in subject to CA evaluation. It treated it as a SESSION RESUMPTION using a valid cookie that had already passed CA.
The geo block was scoped to NEW sign-ins. The cookie was not a new sign-in. The block did not fire.
How to spot it
In your audit log, look at the signInEventTypes field on each entry. A normal interactive sign-in has ["interactiveUser"]. A session-cookie resumption has ["nonInteractiveUser"]. AiTM-stolen sessions will appear as nonInteractiveUser events from unexpected geographies, often within seconds or minutes of a clean interactiveUser sign-in from the legitimate user’s location.
The pair you want to find:
event 1: interactiveUser · 14:01:33 · 73.45.x.x · Boston, MA
event 2: nonInteractiveUser · 14:01:51 · 200.18.x.x · São Paulo, BR
(+18 seconds, +7,000 km)
If you have Entra ID Premium P1, query directly:
GET /auditLogs/signIns?$filter=
userPrincipalName eq 'victim@domain.com'
and signInEventTypes/any(t: t eq 'nonInteractiveUser')
&$top=200
If you’re on the Free tier, the same data is reachable (with some lag) through the Office 365 Management Activity API — the events have a LogonType field that distinguishes the cookie-resume case.
What to require instead
The fix is to require Conditional Access to re-evaluate on session resumption, not just on new sign-ins.
Three controls that close this loop:
-
Sign-in Frequency session control. Set to 1-4 hours for admins, 8-12 hours for regular users. Forces Microsoft to re-evaluate the user’s CA stance at that interval, regardless of whether they have a valid cookie. The stolen cookie expires at the SIF boundary.
-
Persistent Browser Session = Never. Browser sessions that persist across closes are convenient for users — and useful to attackers. Set to Never on every CA policy you can.
-
Token Protection (preview / Entra P1). Binds the session token to the device that received it. A token stolen via AiTM and replayed from a different device fails the binding check and gets denied even if it’s otherwise valid.
The first two are immediately available and cost nothing to enable. The third is a stronger control but is still preview-stage in many tenants.
What you can check in your own tenant today
-
Pull your last 365 days of sign-ins. Group by user. Find any pair where two events on the same account are >1000 km apart and <2 hours apart. Sub-15-minute pairs are textbook AiTM.
-
Check each enabled Conditional Access policy. If it doesn’t have a Session Controls block with Sign-in Frequency set, that policy can be bypassed by a stolen cookie.
-
If you have Defender for Office 365 Plan 1, cross-reference the AiTM-suspect sign-ins against URL-click events to find which phishing email the user clicked.
Why the 18-second number matters
We surface this case publicly because the number is unforgettable. Customers understand “impossible travel” the way they understand “two cars in two different cities at the same time” — it can’t be the same person. The control they THOUGHT was protecting them was scoped to a different kind of event than the one that actually happened.
“Required MFA” is not the same as “enforced MFA on every session.” The cookie that satisfied MFA an hour ago in one city is the cookie that’s signing in for the attacker right now in another.
Anonymized per our marketing policy. The 18-second figure is the actual interval from a real engagement; the cities, the user, the organization, and the timestamps have been generalized.
Run the free Envyously Risk Score → — surfaces impossible-travel pairs over the last 7 days plus a per-policy review of which of your CA policies lack session controls.