The Hidden Gaps in Entra ID Linkable Token Identifier
On 21st July 2025, Microsoft announced the general availability of linkable token identifiers in Entra ID, which introduces a new identifier SessionId across various logs to enhance incident response and anomaly detection. This feature is now available in:
Microsoft Entra sign-in logs
Microsoft Exchange Online audit logs
Microsoft Graph activity logs
Microsoft Teams audit logs
Microsoft SharePoint Online audit logs
The idea is pretty simple: SessionId allows defenders to track user sessions more effectively, even if the user's IP address changes. This is especially useful in man-in-the-middle (AiTM) phishing scenarios, where an attacker initiates a new session, resulting a distinct SessionId. The distinct SessionId enables analysts to filter and isolate attacker activity in the logs easily.
Unfortunately, this approach only works well in specific scenarios like AiTM. In scenarios such as Device Code Phishing or Token Stealing, SessionId provides limited, if any, value. Let's see why.
Where SessionId Falls Short
Device Code Phishing
In device code phishing, attackers exploit the device code authentication flow to capture authentication tokens. When the user completes the device code sign-in on their device, the attacker receives the token and uses it to access the victim's account and perform actions.
To simulate this scenario, I used Azure CLI to initiate a device code authentication on a separate device and completed the sign-in on the victim's device(I also performed a benign device code authentication). As shown below, the Azure CLI authentication receives the same SessionId as the victim's session. Additionally, the DeviceId, available in the DeviceDetail column, matches the victim's device. Therefore, SessionId alone does not help in identifying or investigating malicious activity in device code phishing scenarios.
Token Stealing
Attackers who steal refresh tokens, Primary Refresh Tokens (PRTs), or cookies can silently authenticate and access cloud services. I've used ROADToken to simulate the token stealing attack. ROADToken provides a PRT Cookie that can be used in roadtx, roadrecon and other tools to obtain tokens and perform operations on the resources as the compromised user. As you see below, extracting a PRT cookie from the victim device and using it on a different device results in the same SessionId and DeviceId as the original session. Therefore, SessionId alone does not help in identifying or investigating malicious activity in token stealing scenarios either.
Using SessionId for Detection Engineering
Despite these limitations, SessionId can still provide value for anomaly detection when used carefully. For example:
User Agent Mismatches: A session maintaining the same SessionId and application but suddenly presenting a different user agent from a newly observed IP address could indicate token reuse or session hijacking.
Access Patterns: Clustering activities under a SessionId can help build temporal baselines and detect outliers or behavioral anomalies.
Conclusion
Microsoft's introduction of linkable token identifiers is a step forward, especially for streamlining investigations in AiTM scenarios. However, defenders must be aware of its blind spots. Over-relying on SessionId can obscure malicious activity that hides within legitimate sessions. For detections, it's important to correlate SessionId with additional signals such as application, IP address, and User Agent.
