Entra token exchange session shift
One session that starts as a person in a browser and, moments later, continues as a machine redeeming a refresh token.
What it detects
One session that starts as a person in a browser and, moments later, continues as a machine redeeming a refresh token.
A genuine session keeps its character. A user signs in interactively and their subsequent traffic is either more interactive activity or background refreshes from the SAME client, spread over hours. What this rule looks for is the handover: an interactive sign-in, then within minutes the identical session identifier presenting a refresh token NON-interactively — the shape left behind when a token is lifted from a browser or an agent and replayed from somewhere else, because the thief inherits the session but not the browser.
Grouped by session id so the two halves are provably the same session rather than two things that happened to the same account.
MITRE ATT&CK mapping
False positives and triage
Some legitimate flows do shift character inside one session: a user signing in and immediately launching a desktop client that redeems a token of its own, and broker-assisted flows on managed devices, both produce this pair. The discriminators are the ADDRESS and the CLIENT. Compare the source address of the two steps — a genuine handover happens on the same host, while theft moves the token somewhere else, and a different address across a five-minute window is the single strongest signal here. Then compare the user agents: a browser followed by a known first-party client is ordinary, a browser followed by a script client or a blank agent is not. Sessions on enrolled, compliant devices with matching addresses can be allowlisted once confirmed.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/entra_token_exchange_session_shift.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_token_exchange_session_shift
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1550.001, T1539]
description: |
One session that starts as a person in a browser and, moments later, continues
as a machine redeeming a refresh token.
A genuine session keeps its character. A user signs in interactively and their
subsequent traffic is either more interactive activity or background refreshes
from the SAME client, spread over hours. What this rule looks for is the
handover: an interactive sign-in, then within minutes the identical session
identifier presenting a refresh token NON-interactively — the shape left behind
when a token is lifted from a browser or an agent and replayed from somewhere
else, because the thief inherits the session but not the browser.
Grouped by session id so the two halves are provably the same session rather
than two things that happened to the same account.
sequence:
# Five minutes: token theft tooling redeems immediately, while a device's own
# background refresh arrives on the token's lifetime, an hour or more later.
within_seconds: 300
group_by: [session_id]
order: strict
steps:
- id: interactive_signin
match:
event_category: authentication
event_outcome: success
ext:isInteractive: "true"
- id: non_interactive_token_redemption
match:
event_category: authentication
ext:isInteractive: "false"
ext:incomingTokenType_any: [refreshToken, primaryRefreshToken]
correlation_keys: [user_name, source_ip, session_id]
false_positive_guidance: |
Some legitimate flows do shift character inside one session: a user signing in
and immediately launching a desktop client that redeems a token of its own, and
broker-assisted flows on managed devices, both produce this pair. The
discriminators are the ADDRESS and the CLIENT. Compare the source address of the
two steps — a genuine handover happens on the same host, while theft moves the
token somewhere else, and a different address across a five-minute window is the
single strongest signal here. Then compare the user agents: a browser followed by
a known first-party client is ordinary, a browser followed by a script client or
a blank agent is not. Sessions on enrolled, compliant devices with matching
addresses can be allowlisted once confirmed.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.