Session Hijacking: Detection and Investigation

Adversaries have known for a while now, usernames and passwords often don’t get them what they want. It’s user sessions; authenticated, post-MFA sessions that get them the keys to modern enterprises. However, as adversary preferences and trends change, we need to ensure that defenses keep up.

The hard part about session hijacking is that the attacker never fails a login. They arrive with a session the identity provider already issued, so the authentication record looks clean: no failed password, no MFA prompt, often no new device registration. Controls built around the authentication event, including conditional access, MFA policy, and password policy, evaluate a moment a replayed session never passes through. The one alert that does fire is usually an impossible-travel or risky-sign-in flag. It lands in the same queue as every traveling employee and gets the same thirty seconds.

Prophet Security's Q3 2026 threat report puts numbers on how well that works. Across every alert investigated in customer environments between May 1 and July 31, 2026, session hijacking was the most common way attackers broke into accounts, and identity was the objective in roughly half of all confirmed malicious activity. The strongest predictor of whether a takeover succeeded was what the attacker presented at sign-in.

• A correct password from unfamiliar infrastructure ran into conditional access and was blocked. 
• A replayed session was never evaluated, and it worked.

Every figure and case below comes from that quarter unless another source is named.

That leaves detection dependent on the session's own behavior rather than on the login: the device presenting the token, how the MFA requirement was satisfied, which authentication method carried each event, and what changed in the account afterward. This guide covers what gets stolen, the four signals that resolve one of these alerts, where each signal lives in Entra and Okta telemetry, and how to revoke stolen sessions and tokens during containment. It applies the general process in Prophet Security’s alert triage guide to session hijacking.

{{ebook-cta}}

What session hijacking is, and what gets stolen

Session hijacking is the theft and replay of the authenticated session material an identity provider issues after login, such as:

• A browser session cookie,
• A refresh token, or 
• A Primary Refresh Token (PRT) cookie used for single sign-on (on Windows), so that an attacker operates as an already-authenticated user without a password or an MFA prompt.

The three artifacts behave differently once stolen, and each one requires a different revocation step:

• A session cookie tells a browser it is already inside. Whoever holds it is that browser for as long as the cookie lives. Session revocation removes it, and continuous access evaluation is what catches it mid-session.
• A refresh token lets the holder mint new access tokens for as long as it lives. It does return to the identity provider at redemption, which is the one built-in chance to re-evaluate and revoke it.
• A Primary Refresh Token (PRT) ties a Windows device to the directory. Microsoft binds the PRT to the device with a client secret stored on platform-specific hardware such as a Trusted Platform Module, so the PRT itself is rarely what gets taken. What gets stolen is the PRT cookie it signs, which the browser presents for single sign-on. Activity riding it looks like a domain-joined machine doing normal work.

A password reset does nothing to any of the three, because none of them is a credential.

MITRE catalogs the theft as T1539, Steal Web Session Cookie, and the replay as T1550.004, Web Session Cookie, whose description notes that the technique bypasses some multi-factor authentication protocols because the session is already authenticated. Prophet's threat report observed both theft patterns in the quarter: cookies decrypted out of the browser store on the endpoint, and PRT material replayed from hardware that was never the bound device.

Four signals that separate a hijacked session from a traveling employee

A few detections target stolen sessions directly, including an alert in Microsoft Defender XDR named “Stolen session cookie was used.” Adversary-in-the-middle detection is usually one of the higher-confidence indicators, and Defender groups related alerts, such as impossible travel and unfamiliar sign-in properties, into the same incident. These detections do a decent job, but they produce more false positives than most teams would like, so even an alert that names the theft still needs confirming. What resolves the alert is four signals, each answerable from telemetry most teams already collect. One on its own is noise. Two or three converging on the same account is a replayed session, with the caveat in the last paragraph of this section.

• The account's own history, on three axes at once. Does this account have authentication history from this country, on this device, with this user agent? In the investigation Prophet reconstructed for its report, the answer was no on all three. For example, a login from Houston on the account's normal browser was followed ninety-five seconds later by a successful login from Sydney. The Sydney device had no management record, and its address resolved to a commercial VPN exit associated with two residential proxy services. The Houston address was associated with four more. Both ends of the impossible travel were anonymized infrastructure, which is a different situation from a user on a VPN. Lives in the sign-in log's device, location, and user-agent fields, compared against the account's own baseline rather than a global threshold.
• How the MFA requirement was satisfied. This is the sharpest of the four and the one most often skipped. The alert said the login succeeded. The authentication record said the MFA requirement was satisfied by a claim carried in the token, with no MFA interaction during the sign-in. Nothing was phished and nothing was approved. Read that combination as evidence that authentication was never performed for the session: MFA satisfied by a token claim, arriving from a device, browser, or location inconsistent with the device the token was issued to. Lives in the authentication-detail fields of the sign-in record, never in the alert body.
• The authentication method carried by every event in the sequence. Every event in the reconstructed case rode Primary Refresh Token authentication with no fresh credential entry anywhere in the sequence. That answer named the artifact and therefore named the fix, because revoking the password would not have touched it. The user agent also changed mid-sequence, from Chrome on Windows to Safari on iPhone, between two logins ninety-five seconds apart. Sessions from both addresses then interleaved inside a four-minute window, which is two actors operating concurrently rather than one person moving.
• What changed in the account afterward. New inbox rules, especially rules that delete, archive, or mark incoming mail as read; a newly registered MFA method; new OAuth consents; unusual download volume. These are how an attacker converts one stolen session into durable access, and all of them survive a password reset. Inbox rule manipulation appeared at nearly as many organizations as impossible travel last quarter.

One caveat changes how the first signal should be weighted. Device compliance is the fastest path most analysts have to closing a suspicious-login alert, and it fails here. In a red-team engagement documented earlier this year, the operator reached a PRT after a ClickFix lure dropped a DLL that hooked into excel.exe. The stolen token carried the original machine's compliance claims with it, so the device read as enrolled, managed, and healthy. The attacker was simply not on it. Compliance answers whether the original device was managed, not whether the entity presenting the token now is the one that authenticated. That engagement also shows the volume problem: across the entire kill chain, the only alert the stack produced was a single uncommon-location sign-in to Office 365.

How sessions get stolen: AiTM phishing and infostealers

Two delivery mechanisms account for most stolen sessions in current reporting, and they leave evidence in different places. Adversary-in-the-middle (AiTM) phishing places a reverse proxy between the user and the real identity provider. The user signs in to what looks like Microsoft 365 or Okta, the proxy relays the credential and the MFA response to the legitimate service in real time, and the session cookie is captured on the way back. Strong email and communications controls are the first chance to stop an AiTM attack, because the phishing link has to reach the user before the proxy can relay anything.

Microsoft's January 2026 write-up of a multi-stage AiTM and business email compromise campaign against energy-sector organizations documented more than 600 phishing emails. Post-compromise, the attacker created an inbox rule that deleted every incoming message and marked it read, and registered an MFA method of their own. The same arc appears in any phishing investigation that reaches the sign-in stage. In one investigation a login arrived from a hosting provider in one country and the MFA approval came back from an IP in another, sixteen seconds later, then again at 118 seconds on a second attempt. One person rarely approves from a second country sixteen seconds after logging in from the first; a real-time proxy relaying the response does. How rare that is depends on how users connect. Where the security team runs a corporate VPN and keeps an asset inventory of the devices that should be signing in, the country mismatch stands out. Where users can sign in from anywhere, through any VPN they please, the same mismatch turns up in legitimate traffic, and it is hard to alert on with confidence.

Infostealers take the cookie from the endpoint instead of from the network. One script in the quarter's data decrypted the browser's encrypted cookie store, extracted Microsoft authentication session cookies, and used them to make authenticated API requests. Delivery was the browser rather than email. Fake update prompts on compromised legitimate sites, fake verification and CAPTCHA gates, malicious advertising, and trojanized installers all appeared, including fake installers for popular AI tools. Named payloads included Lumma Stealer, Vidar, RedLine, HijackLoader, and AsyncRAT. Google shipped App-Bound Encryption for Chrome cookies on Windows in Chrome 127 in July 2024, tying decryption to Chrome's own identity through a privileged service. Bypasses followed. CyberArk's C4 Bomb research demonstrated a padding-oracle attack against DPAPI that recovers the cookies from a low-privileged process, without the administrative rights the control assumes an attacker would need.

Stolen cookies also get resold. Genesis Market, which law enforcement disrupted in April 2023, offered data stolen from more than 1.5 million computers. It sold device fingerprints, combinations of device identifiers and browser cookies, that let a buyer pass as the victim. Dark web monitoring doesn’t prevent the theft, but it can surface stolen sessions and credentials after a compromise, and it is worth adding for any team with the budget.

The delivery differs and the artifact does not, which is why detection has to focus on the replay rather than on the lure. One case cut the other way: an adversary-in-the-middle proxy captured a credential and then met a phishing-resistant factor at the MFA step, where it stopped. Where credentials were phished rather than sessions stolen, the controls held.

Where the four signals live in your alerts

The alerts that surfaced session hijacking last quarter came mainly from identity provider telemetry: Entra ID risk detections and Okta sign-in and threat insight alerts, with Defender, SaaS security platforms, and SIEM correlation rules supplying the rest. The highest-yield types were impossible travel, risky and unfamiliar sign-in properties, anonymous IP sign-in, and inbox rule creation, which is also a list of the alerts most likely to be bulk-closed.

Entra ID Protection carries several detections that map to the signals above. Anomalous Token flags abnormal characteristics in the token, such as an unusual lifetime or a token played from an unfamiliar location, and covers session tokens and refresh tokens. Adversary in the Middle fires when an authentication session is linked to a malicious reverse proxy. Microsoft describes it as high precision; it runs offline rather than in real time, and its licensing is Microsoft 365 E5 with Enterprise Mobility + Security E5. Unfamiliar sign-in properties, Anonymous IP address, and Atypical travel supply the first signal's context. Defender XDR adds the two alerts Microsoft named in its January 2026 campaign analysis: "Stolen session cookie was used" and "Possible AiTM phishing attempt." On the Okta side, the System Log records user.session.start, user.authentication.auth_via_mfa, and system.push.send_factor_verify_push. Each event carries client.ipAddress and geographic context, which is what makes it possible to compare where a login came from with where its MFA approval came from. Prophet's Okta alert investigation guide covers the field-level method.

The alert names the anomaly. Whether it is a salesperson on hotel Wi-Fi or a replayed session sits in the account's history and the authentication method behind each event, which is signals one through three.

Where current detection logic falls short

Most identity detection evaluates the authentication event, and a replayed session cookie is never presented as a credential. A stolen refresh token is the exception, since it returns to the identity provider at redemption, and that redemption is one point where policy can catch it. Continuous access evaluation adds another for the services that support it.

Geography-based logic has a second gap. Impossible travel fires on distance and time, so a replay from infrastructure in the victim's own region, or through a residential proxy near them, produces no anomaly at all. Where it does fire, the risk rating justifies an investigation without resolving it: the Sydney session was rated high for anomalous device, anomalous location, and anonymizing proxy, and those three attach to a large share of benign sign-ins from travelers and contractors.

Containment logic has a third. At two organizations the attacker kept working after the account was disabled, one of them still operating six days after deactivation, riding access issued before the disable and using it to change authentication methods and grant OAuth consents. Both teams believed they had contained it.

Logging gaps decide which detections are even possible. Comparing the country of a login with the country of its MFA approval requires the identity provider to record the approving client's address. Okta's System Log does; the Entra sign-in log generally does not expose it for push approvals. On the endpoint, App-Bound Encryption raises the cost of cookie theft without removing it, so alerting on any process reading the browser cookie database or touching Chrome's elevation service is the durable half of that control.

Containment has to revoke what was stolen

The hardening list is short and none of it is exotic. Add session and refresh token revocation to the account compromise runbook as a required step, since disabling the account is not containment on its own. Turn on continuous access evaluation and token protection where the identity provider supports them. Microsoft's continuous access evaluation revokes access in Exchange Online, Teams, and SharePoint Online after a critical event such as an account disable, a password reset, or an administrator revoking refresh tokens, with a stated propagation latency of up to fifteen minutes and IP location policy enforced instantly. Token protection accepts only sign-in session tokens cryptographically bound to the device. Check its scope before relying on it: it is generally available for native Exchange Online, SharePoint Online, and Teams clients on Windows, iOS, and macOS, while browser-based support remains in preview and covers only selected web apps reaching Azure Resource Manager. On Okta, Universal Logout terminates user sessions and tokens for supported applications when Identity Threat Protection identifies a change in risk, or when an administrator triggers it from the user's risk profile.

Three detection habits follow from the findings. Treat a sign-in as a token compromise when MFA was required, was satisfied by a claim in the token rather than performed, and the sign-in arrived from a device, browser, or location inconsistent with the device the token was issued to. Alert when a login and its MFA approval originate from different countries; one case last quarter was detectable on that alone. Treat "correct password, blocked by policy" as a confirmed credential exposure, because in several cases the block was held and the attacker returned with a session. On the endpoint, treat every confirmed infostealer as a session compromise and revoke sessions and refresh tokens as part of remediation, since reimaging alone leaves the attacker holding the access. After any compromise, audit inbox rules, OAuth consents, and newly registered authentication methods. Where phishing-resistant MFA is not yet possible, disable SMS, voice, and email factors and turn off automatic release of locked accounts. Automatic release was part of one attack path: brute force, lockout, automatic release, push bombing, then a new device registered.

The same four signals apply when the entry point is an MFA fatigue attack or a phished credential. In each case the investigation has to establish which artifact the attacker is holding, because that artifact determines what revocation has to cover.

Investigating session hijacking with Prophet AI

The four signals are ordinary. Running them takes the better part of an hour across identity, endpoint, and email telemetry, and that is the constraint. Each of a compromised account's alerts is individually unremarkable and closes correctly on its own terms, so the compromise appears only when somebody carries the count forward across all of them. That is the work that gets dropped when there is more work than hours.

Prophet AI SOC Analyst reconciles the four on every alert rather than on the ones that survive triage. For a sign-in alert it pulls the account's authentication history, the device inventory, the endpoint agent status, threat intelligence on the source address, and the organization's own prior investigations, all in parallel, and documents every query so an analyst can copy it and run it themselves. When the telemetry to answer a question was never connected, the determination says Inconclusive and names the missing source rather than guessing. The same reconciliation at scale is documented in a partner-environment case study, AiTM session hijacking and token persistence among the patterns worked. For the estate-wide question, whether a stolen session was replayed anywhere else, Prophet AI Threat Hunter ships curated hunts for emerging identity tradecraft that the team runs or schedules. What a hunt confirms becomes a candidate detection through the AI Detection Engineer, backtested against the organization's own history before anyone approves it.

The full quarter of findings, including the step-by-step reconstruction referenced here, is in the Prophet Security Quarterly Threat Report. To see what a full investigation of a suspicious sign-in looks like against your own identity telemetry, every question and every answer, request an investigation replay.