How to Detect Session Token Hijacking in Microsoft Entra ID
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Session token hijacking is the primary reason MFA-protected accounts are still getting compromised at scale in 2026. The attack does not break MFA. It waits until MFA is complete, steals the token that proves authentication succeeded, and replays that token from the attacker's device.
The token is the proof of authentication. Steal the proof, and you do not need to repeat the authentication. Detecting this requires looking at sign-in behavior after the token is issued: not at the authentication event itself.
How the Attack Works
The most common token theft vector is adversary-in-the-middle (AiTM) phishing. The attacker stands up a reverse proxy (Evilginx, Modlishka, or custom tooling) that sits between the victim and the real Microsoft login page. The victim enters their credentials and completes MFA on the proxy, the proxy forwards everything to Microsoft, Microsoft issues a session cookie, and the proxy captures that cookie before delivering the page to the victim.
The attacker now has a valid session token issued to the victim's identity, with MFA already satisfied. They can import that cookie into a browser and access Outlook, SharePoint, Teams, and any other service the victim is authorized for: without knowing the password or having the victim's phone.
A second, less common path is malware-based cookie theft. Infostealers like RedLine, Raccoon, and Lumma Stealer harvest browser cookie stores and transmit them to the attacker. The attacker sorts through harvested cookies for Entra ID tokens and replays any that are still valid.
In both cases, the initial Entra ID authentication event looks clean: correct credentials, MFA passed, successful sign-in from what appears to be the user's location (the proxy forwards from a server near the victim). Detection requires looking at what happens with the session after that point.
What to Look For in Entra ID Logs
Microsoft Entra ID sign-in activity appears across three log tables in Microsoft Sentinel:
SignInLogs: interactive sign-ins (user enters credentials in a browser)AADNonInteractiveUserSignInLogs: non-interactive sign-ins (app using a refresh token, background token refreshes)AADServicePrincipalSignInLogs: service principal authentication
Token replay attacks appear almost entirely in AADNonInteractiveUserSignInLogs. The initial theft occurs during an interactive session; subsequent access using the stolen token appears as non-interactive sign-ins from the attacker's infrastructure.
Key anomaly patterns:
Impossible travel: The interactive session originates from the user's expected location. Non-interactive sessions using the same refresh token appear within minutes from a geographically distant IP address. A token physically cannot be used from New York and London within 8 minutes unless it was stolen.
ASN mismatch on refresh token: The interactive sign-in originates from the user's ISP (Comcast, Verizon, corporate IP block). The subsequent non-interactive sessions using the same refresh token originate from a hosting provider or VPN ASN (DigitalOcean, Vultr, Mullvad, NordVPN). Legitimate users do not refresh their Outlook token from a cloud hosting provider.
Unfamiliar device in non-interactive log: The deviceDetail.deviceId is empty or null in non-interactive sessions, while the original interactive session shows a managed, Intune-registered device. Legitimate refresh token use from a managed device carries the device ID forward.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Three KQL Queries for Microsoft Sentinel
These queries run against Entra ID log tables in Microsoft Sentinel. Replace the time window and thresholds as needed for your environment.
Query 1: Impossible travel on refresh token sessions
let timeWindow = 1h;
let maxDistanceKm = 500;
let interactiveSessions = SignInLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType == 0
| project UserId, UserPrincipalName, IPAddress, Location, TimeGenerated
| summarize InteractiveIP = any(IPAddress), InteractiveTime = min(TimeGenerated) by UserId, UserPrincipalName;
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType == 0
| project UserId, UserPrincipalName, IPAddress, TimeGenerated
| join kind=inner interactiveSessions on UserId
| where IPAddress != InteractiveIP
| extend TimeDiffMin = datetime_diff('minute', TimeGenerated, InteractiveTime)
| where TimeDiffMin < 60
| project UserPrincipalName, InteractiveIP, NonInteractiveIP = IPAddress, TimeDiffMin
Query 2: Hosting provider ASN on non-interactive sessions for known corporate users
let corporateASNs = dynamic(["AS7922", "AS701", "AS20057"]); // Replace with your ISP ASNs
let hostingASNKeywords = dynamic(["DIGITALOCEAN", "VULTR", "AMAZON", "LINODE", "OVH", "MULLVAD", "NORDVPN"]);
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where isnotempty(IPAddress)
| extend ASNInfo = tostring(parse_json(tostring(DeviceDetail)).operatingSystem)
| where NetworkLocationDetails has_any(hostingASNKeywords)
| project UserPrincipalName, IPAddress, NetworkLocationDetails, AppDisplayName, TimeGenerated
Query 3: Non-interactive sign-in with no registered device where user normally uses managed device
let managedUsers = SignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where isnotempty(DeviceDetail)
| where DeviceDetail has "deviceId"
| summarize by UserPrincipalName;
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where UserPrincipalName in (managedUsers)
| where isempty(DeviceDetail) or DeviceDetail == "{}"
| project UserPrincipalName, IPAddress, AppDisplayName, TimeGenerated
Five-Step Triage Flow When an Alert Fires
When any of the above queries produce results, follow this triage sequence:
Step 1: Confirm the anomaly is not travel or VPN use. Contact the user. Ask whether they traveled in the past 24 hours or connected through a personal VPN. Document the response. If yes, mark benign and tune the exclusion. If no, treat as compromised.
Step 2: Revoke all active refresh tokens.
In the Entra ID admin portal: Users → select user → Revoke sessions. In PowerShell: Revoke-MgUserSignInSession -UserId <UPN>. This invalidates all existing refresh tokens within 1 hour, forcing reauthentication from all devices.
Step 3: Disable sign-in. Block the user account while investigation proceeds: Users → select user → Block sign-in. This stops further access while you assess the scope.
Step 4: Review non-interactive log for the past 72 hours. Pull all non-interactive sign-in events for the affected user and identify which applications the attacker accessed. Common targets: Exchange Online (email access and rule creation), SharePoint (document exfiltration), Teams (communication interception).
Step 5: Check for attacker persistence mechanisms. Look for new OAuth app consent grants, new Outlook inbox rules, new forwarding rules, and new registered devices in the account. These are how attackers maintain access after token revocation.
The bottom line
Session token hijacking is the current leading MFA bypass technique because it does not attack the authentication step at all. The detection window is the post-authentication behavior: where is the refresh token being used, from what network, on what device? The three KQL queries above cover the highest-signal anomalies. Run them as scheduled analytics rules in Sentinel with a 1-hour window and alert on any result. When an alert fires, the five-step triage determines within 20 minutes whether you have a true positive and contains the breach before the attacker establishes persistence.
Frequently asked questions
How does session token hijacking bypass MFA?
Session token hijacking steals the authentication cookie issued after MFA succeeds. The stolen token already contains proof that MFA was completed, so replaying it on a different device bypasses the MFA challenge entirely. The attacker never needs the user's password or second factor.
How do I detect token theft in Microsoft Entra ID?
Query AADNonInteractiveUserSignInLogs in Microsoft Sentinel for three patterns: impossible travel (same refresh token used from two geographically distant IPs within minutes), hosting provider ASN in non-interactive sessions for users who normally sign in from corporate or residential IPs, and missing device ID in non-interactive sessions for users who always authenticate from managed devices.
What should I do first if I suspect a session token is stolen?
Immediately revoke all refresh tokens using Revoke-MgUserSignInSession in PowerShell or the Entra ID admin portal, then disable the user's sign-in. This invalidates the stolen token within one hour and prevents further access while you investigate.
What is the difference between session token hijacking and credential theft?
Credential theft captures a user's username and password: the attacker then authenticates normally, triggering MFA if enforced. Session token hijacking captures an already-authenticated session token (a refresh token or access token) from memory, a browser, or a network intercept: the attacker presents the token directly to the identity provider, bypassing the authentication step including MFA entirely. This is why token hijacking is a critical MFA bypass technique and why Conditional Access policies must evaluate token binding, device compliance, and continuous access evaluation, not just initial authentication.
Which threat actors use session token hijacking?
Token theft is a core technique for financially motivated groups targeting cloud environments. Scattered Spider (UNC3944) extensively uses browser session cookie theft via infostealer malware and adversary-in-the-middle phishing toolkits like Evilginx2 and Modlishka. APT29 (Cozy Bear) has used token theft against M365 and Azure environments in multiple campaigns. The common delivery mechanism is infostealer malware (Raccoon Stealer, RedLine, Vidar) that extracts session tokens from browser profile directories and uploads them to C2 infrastructure.
How do I use Continuous Access Evaluation (CAE) to reduce token theft risk?
Continuous Access Evaluation (CAE) in Entra ID shortens the lifetime of access tokens and pushes near-real-time policy enforcement to capable applications. When a user's account is disabled or a sign-in session is revoked, CAE-capable applications enforce the change within minutes rather than waiting for the token to expire (typically 60-90 minutes). Enable CAE under Entra ID Conditional Access settings. Applications must support CAE to benefit: Microsoft 365 apps (Exchange, Teams, SharePoint) support it natively. Third-party apps require CAE claim challenges support in their authentication library.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.