Trackr.Live The landing site for Trackr Services
§ AC

Token Protection Binds the PRT, Not the Browser Session AiTM Actually Steals

By AutoCypher ·

Walk into any post-incident review for an account takeover in Entra and someone will say the word “Token Protection” within the first ten minutes, usually in the tone of a fix that should have already been on. It’s the control the zero-trust slideware points at when the topic turns to adversary-in-the-middle phishing and stolen session cookies. The pitch is clean: cryptographically bind the sign-in token to the device, and a replayed token from the attacker’s box is dead on arrival. The pitch is also, as of mid-2026, mostly aimed at a door the attacker isn’t using.

Here’s the gap in one sentence. Token Protection enforces device-bound sign-in session tokens — PRT-backed flows among them — for native applications, and the AiTM kits land their hooks in the browser, which the feature explicitly does not cover. Read the platform support table on Microsoft’s own doc (concept-token-protection, last revised 2026-03-24) and the note is right there under it: “Token Protection currently supports native applications only. Browser-based applications are not supported.” Windows is Generally Available. iOS, iPadOS, and macOS are still Preview. Supported resources are Exchange Online, SharePoint Online, and Teams, plus Azure Virtual Desktop and Windows 365 on Windows. That’s the whole footprint.

So when the phishing page proxies a Microsoft login through Evilginx-style tooling and walks off with the authenticated session cookie, the resource the victim was reaching — Outlook on the web, the SharePoint document that the lure pointed at, Teams in a browser tab — is the part Token Protection isn’t watching. The control is real and worth deploying. It just doesn’t cover the vector that’s actually generating your tickets.

What the binding actually does, and where it stops

When a supported device registers with Entra, the PRT is issued and bound to that device’s key material, held in a hardware-backed key store where one exists — the TPM on Windows, the Secure Enclave on the Apple platforms still in preview. With Token Protection enforced as a session control in Conditional Access, Entra checks that the sign-in session token presented for a protected resource is one of those device-bound tokens rather than a portable bearer token someone copied off a machine. Steal the bound token, move it to another host, and it doesn’t validate. For the Outlook desktop client, OneDrive sync, Teams desktop on a managed Windows 10+ box, this closes the replay path it was built for.

The browser is a different animal. The ordinary browser app session — the kind Token Protection doesn’t cover — runs on a bearer cookie, and bearer means exactly what it says: hold the cookie, you’re in. There are exceptions worth naming so the claim isn’t sloppier than it should be: in specific brokered SSO-extension scenarios Entra can bind browser cookies to device/session key material, and DBSC or proof-of-possession can bind the session another way. Absent one of those, the cookie is a bearer token. That’s the design AiTM exploits. The proxy sits between user and IdP, the user completes MFA against the real Microsoft endpoint because the page is a faithful relay, and the session cookie that comes back is harvested mid-flight. MFA fired. It didn’t matter. Microsoft’s own writeups have been blunt about this for years; their January 21, 2026 post on a multistage AiTM and BEC campaign abusing SharePoint (microsoft.com/en-us/security/blog/2026/01/21/multistage-aitm-phishing-bec-campaign-abusing-sharepoint/) is just the latest in a long line.

Two browser-layer answers are maturing — Device Bound Session Credentials, which shipped GA on Windows in Chrome 146 in April 2026, and DPoP at the application layer. Both genuinely raise the cost of cookie replay, but only where every party participates: DBSC helps where the relying party and the browser both speak it, and Google still frames the federated-identity and cross-origin pieces as future work, so don’t read it as already covering most Entra/M365 browser sessions; DPoP only delivers end-to-end when the authorization server and the resource server both implement it. Neither is broadly enforced across an enterprise estate yet. For the tenant you’re defending this quarter, the honest position is that the browser session is still a bearer token and the control aisle doesn’t have a turnkey fix for it. Which puts the weight back on detection.

The detection, and the field that carries it

The signal that survives AiTM is the session identifier showing up from two places that can’t both be the user. In Entra sign-in telemetry — SigninLogs in Sentinel, EntraIdSignInEvents in Defender advanced hunting (the table that replaced the legacy AADSignInEventsBeta on 2025-12-09) — the SessionId issued during authentication is the same value the attacker’s replayed cookie carries. So you correlate on SessionId, look for the same value appearing from a different IPAddress and, more usefully, a different AutonomousSystemNumber inside a tight window, and where you have token-level granularity reach for UniqueTokenIdentifier to pin the specific token. Don’t stop at sign-in rows either — join the session out to the workload audit logs (Exchange, SharePoint), because the replay’s payoff shows up there, not in the login.

ASN is the field that does the work, not raw IP. A user’s IP changes all day for boring reasons; an ASN jump from a residential or corporate range to a hosting provider (Hetzner, DigitalOcean, OVH, the usual VPS suspects) in the same session within a few minutes is the shape you want. Get the field location right before you write the query: in SigninLogs, AutonomousSystemNumber is a native column (alongside IPAddress, SessionId, UserAgent, UniqueTokenIdentifier, and TokenProtectionStatusDetails). In Defender’s EntraIdSignInEvents it is not a documented column — you have IPAddress and the location fields, so you enrich ASN from the IP with a lookup or watchlist before you can pivot on it. A short, runnable starting point against the Sentinel table:

SigninLogs
| where TimeGenerated > ago(1h)
| where isnotempty(SessionId) and ResultType == 0
| summarize ASNs = make_set(AutonomousSystemNumber), IPs = make_set(IPAddress),
            UAs = make_set(UserAgent), logins = count(),
            firstSeen = min(TimeGenerated), lastSeen = max(TimeGenerated)
    by SessionId, UserPrincipalName
| where array_length(ASNs) > 1
| extend window_min = datetime_diff('minute', lastSeen, firstSeen)
| where window_min <= 30
// join an allowlist watchlist of known-good egress (corp, SWG, mobile carriers)
// here and keep only sessions whose second ASN is hosting/anonymization
| project UserPrincipalName, SessionId, ASNs, IPs, UAs, logins, window_min, firstSeen, lastSeen
| order by window_min asc

Pair the ASN jump with UserAgent changes mid-session — treat that as corroboration rather than a trigger, since a competent Evilginx-style proxy relays the victim’s UA faithfully and a matching string clears nothing — and with a post-compromise tell that commonly follows these: a sign-in immediately followed by an audit event registering new MFA security info, because a frequent first move after landing is to enroll their own authenticator for persistence. That audit pivot (Authentication Methods activity, “User registered security info”) is frequently a cleaner alert than the session-jump itself.

Don’t hand-build the join from scratch first, but know what the prebuilt content actually does. The Azure-Sentinel repo ships PossibleAiTMPhishingAttemptAgainstAAD, and it’s a useful starting point — but it is not the SessionId-across-ASN replay detector described above. It correlates high-risk successful Entra sign-ins with web-proxy/session telemetry (Zscaler, CommonSecurityLog) to flag users who reached the risky sign-in IP through a proxy first. Different shape, complementary signal. Microsoft also maintains a token theft playbook; start from those, then tune.

Entra ID Protection has two built-in risk detections worth wiring into this. “Anomalous Token” flags atypical token characteristics — unusual lifetime, a token played from an unfamiliar location — and Microsoft documents it as real-time or offline, not offline-only as the older write-ups have it. “Attacker in the Middle” is an offline user-risk detection that fires when an authentication session is linked to a malicious reverse proxy, which is about as on-the-nose for this article’s subject as a built-in gets. Treat both as risk inputs feeding your Conditional Access and your hunt, not as complete coverage — the offline ones land after the fact, not in time to block the session.

One operational dependency sits underneath all of it: the SessionId correlation only works while both sign-ins are still in hot, queryable storage. Check your Sentinel or Log Analytics retention against the window you actually hunt over before you trust the rule — a session jump you can’t query anymore is a detection you don’t have.

The first week of tuning is an egress-topology problem

Stand the SessionId-across-ASN rule up in a 20,000-seat tenant and the first day is loud. Expect dozens of hits, and expect nearly all of them to be legitimate. The false positives have a small number of sources and they’re all about how your users reach the internet.

Mobile is the big one. A user on a laptop tethered to a phone, or a phone client itself, flips between the cellular carrier’s ASN and the office or home Wi-Fi ASN constantly — same session, two ASNs, minutes apart. Looks identical to replay. VPN split-tunneling does the same thing when some traffic egresses corporate and some egresses local. And any pool of NAT’d or load-balanced egress will scramble the IP half of the signal while leaving the ASN stable.

The thing that genuinely changes the answer is whether you run a secure web gateway. Behind Zscaler ZIA or Netskope, your users egress from the SWG’s ASN, so the legitimate baseline collapses to one or two ASNs and a real attacker on a VPS stands out cleanly — the SWG is doing your normalization for free. Without one, in a flat setup where everyone NATs out their local ISP, the carrier-and-Wi-Fi roaming noise is relentless and you’ll be carving exceptions for weeks. Same rule, opposite experience, decided entirely by network architecture.

First round of tuning, concretely: build an allowlist of your known-good ASNs (corporate egress, the SWG, the major domestic mobile carriers your workforce actually uses) and require the second ASN in the pair to be an unknown hosting or anonymization provider before the rule fires. That one change is usually the difference between dozens of alerts a day and low single digits. You will lose a sliver of real detections to it — an attacker on a residential proxy network in your allowlisted carrier space slips through, which is the tradeoff you’re consciously making. Decide it on purpose, write it in the rule comment, and revisit when ORB and residential-proxy abuse changes the math.

VDI is the other carve. Citrix or AVD farms collapse many users behind one egress, so the ASN pivot stops telling users apart and you lean harder on the device and UA dimensions there.

CAE is the revocation path, not a kill switch, and it’s slower than the deck claims

Detection that can’t revoke is just narration. Continuous Access Evaluation is the piece that lets the IdP tell a relying party to stop honoring a token before it expires — a revocation accelerator, not a guaranteed instant cutoff — which matters more than usual because CAE sessions run long: Microsoft documents token lifetimes up to 28 hours. A replayed cookie without CAE in the path can live the better part of a day.

The caveat is the response time. Microsoft’s own language is that critical-event revocation is “near real time” but that latency of up to 15 minutes may be observed because of event propagation. Instant enforcement applies to IP-location policy changes, and only when you’ve turned on strict location enforcement, and only for resources that support CAE. So the mental model of “revoke and they’re out” is really “revoke and they’re probably out within fifteen minutes, on the resources that participate.” For a fast-moving BEC actor, fifteen minutes is enough to set inbox rules and fire the first fraudulent payment request. CAE’s coverage for B2B guests is shaky too — revocation depends on the guest’s home tenant propagating the event across to the resource tenant — which in a tenant heavy on B2B collaboration is a hole worth naming out loud.

Where this lands in the control set

The mapping below is to NIST SP 800-53 Rev 5, since that’s the language an ATO package speaks:

Control Why it applies
IA-2 / IA-5 Token Protection contributes to authenticator/session-token binding for supported native-client flows; browser app cookies stay outside that control unless another binding mechanism is in force
AC-12 Session termination on risk — this is the CAE revocation path and its latency ceiling
SC-23 Session authenticity; the SessionId-replay detection is the compensating check when binding isn’t in force
SI-4 The Sentinel analytics plus the Anomalous Token and Attacker-in-the-Middle risk detections
AU-6 Reviewing the post-compromise audit pivot (new MFA enrollment after sign-in)
CA-7 Continuous monitoring posture that ties it together

If you’re writing this up for an ATO package, the defensible statement is not “Token Protection mitigates AiTM.” It’s that Token Protection binds native-app sessions on supported platforms (an IA-2 gain that’s real but partial), the browser session-theft vector is covered by detection under SI-4 and SC-23, and the revocation control under AC-12 carries a documented latency you’ve accounted for. An assessor who knows the feature footprint will catch the overclaim, and they’ll be right to.

Deploy Token Protection. Report-only first, Windows-joined pilot group, watch the interactive and non-interactive sign-in logs before you enforce, exactly as the deployment guide says. Just don’t file it under “AiTM, solved.” The cookie the phish actually walks off with is still a bearer token, and the SessionId hopping ASNs in your SIEM is the thing standing between that cookie and a wire transfer.

Sources