Entra session device shift
One session presenting more than one device identity.
What it detects
One session presenting more than one device identity.
A session belongs to a device. The token Entra issues is bound to the browser or client that authenticated, and every subsequent request in that session reports the same deviceId. Two different device ids inside one session id means the same token was presented from two different machines — which is what token theft looks like from the log side, because the thief inherits the session but brings their own hardware.
This is the "different device IDs using the same token" case, and it is the strongest single indicator in the session-hijack family: unlike an address change (mobile networks, VPNs) or a user-agent change (client updates), a device id does not legitimately change mid-session.
MITRE ATT&CK mapping
False positives and triage
The benign shape to rule out first is a BLANK device id, not a different one. Unmanaged and unenrolled clients report an empty deviceDetail, and if a session mixes an enrolled device with a blank record this rule counts two distinct values while the truth is "one device plus one unknown". Open the evidence and confirm both ids are non-empty GUIDs before treating this as theft; the parser writes an explicit unknown compliance marker precisely so that case is readable.
Beyond that, seamless SSO across a phone and a laptop can share a session identifier in some tenant configurations. The discriminator is time and distance: two devices minutes apart in one country is a person, two devices minutes apart in two countries is not. Cross-reference the addresses before escalating, and allowlist known dual-device users once confirmed.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 65%. Source: rules/cloud/entra_session_device_shift.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_session_device_shift
version: 1.0.0
status: experimental
severity: high
confidence: 0.65
platforms: [application]
mitre_techniques: [T1539, T1550.001]
description: |
One session presenting more than one device identity.
A session belongs to a device. The token Entra issues is bound to the browser or
client that authenticated, and every subsequent request in that session reports
the same `deviceId`. Two different device ids inside one session id means the
same token was presented from two different machines — which is what token theft
looks like from the log side, because the thief inherits the session but brings
their own hardware.
This is the "different device IDs using the same token" case, and it is the
strongest single indicator in the session-hijack family: unlike an address change
(mobile networks, VPNs) or a user-agent change (client updates), a device id does
not legitimately change mid-session.
match:
event_category: authentication
threshold:
# Two is the finding, not a threshold to tune: one session, one device.
count: 2
# An hour tracks access-token lifetime — the span in which a stolen token is
# usable before something has to refresh it.
window_seconds: 3600
distinct: ext:deviceId
group_by: [session_id, user_name]
correlation_keys: [user_name, session_id, source_ip]
false_positive_guidance: |
The benign shape to rule out first is a BLANK device id, not a different one.
Unmanaged and unenrolled clients report an empty `deviceDetail`, and if a session
mixes an enrolled device with a blank record this rule counts two distinct values
while the truth is "one device plus one unknown". Open the evidence and confirm
both ids are non-empty GUIDs before treating this as theft; the parser writes an
explicit `unknown` compliance marker precisely so that case is readable.
Beyond that, seamless SSO across a phone and a laptop can share a session
identifier in some tenant configurations. The discriminator is time and distance:
two devices minutes apart in one country is a person, two devices minutes apart
in two countries is not. Cross-reference the addresses before escalating, and
allowlist known dual-device users 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.