Okta Session Hijacking: Detect Stolen Session Cookies
Detect Okta session hijacking in the System Log: one externalSessionId used from several ASNs or browsers, roaming events, and ruling out VPN and mobile noise.
TL;DR. A stolen Okta session cookie lets the attacker skip the password and MFA entirely, so there is no failed sign-in to find. What you can find is one session used from two places: the same authenticationContext.externalSessionId appearing with two different securityContext.asNumber values, or two different user agents, within hours. Add Okta's own security.session.detect_client_roaming events, then rule out corporate VPNs and phones switching between Wi-Fi and mobile data before you call it theft.
How sessions get stolen
After a successful sign-in, the browser holds a session cookie. Whoever presents that cookie is the user until the session ends. Okta Security describes the two common ways cookies leave the victim's machine: infostealer malware that extracts cookies from the browser, and adversary-in-the-middle phishing sites that proxy the real sign-in and capture the resulting session (Okta Security: defending against session hijacking). MITRE ATT&CK tracks the theft as T1539, Steal Web Session Cookie and the reuse as T1550.004, Web Session Cookie.
Session artifacts also leak through less obvious channels. In Okta's own October 2023 support-system incident, a threat actor accessed files uploaded to support cases; some were HAR files containing session tokens, which were used to hijack sessions at five customers (Okta Security: root cause and remediation). Sanitising HAR files before sharing them is a lesson for every support process, not just Okta's.
The fields that identify a session
| Field | Use |
|---|---|
authenticationContext.externalSessionId | the session identifier (externalSessionId); group by it |
authenticationContext.rootSessionId | the root of the interactive session; Okta Security notes externalSessionId can be regenerated after factor lifecycle events while the root persists (rootSessionId article) |
securityContext.asNumber, asOrg | the network (ASN) the request came from |
client.ipAddress | the exact source |
client.userAgent.rawUserAgent | browser and OS |
The key idea: the victim's legitimate requests and the attacker's replayed requests share a session ID but differ in network and, usually, in browser.
Signals, from strongest to weakest
| Signal | Why it matters | Analyzer rule | Severity |
|---|---|---|---|
| Same session, 2+ ASNs within 12 h | the cookie is being used from another network | session.multi_asn | high |
| Same session, 2+ user agents within 12 h | another browser holds the cookie | session.multi_user_agent | medium |
security.session.detect_client_roaming | Okta itself flagged the session as roaming | session.roaming | medium |
| Session activity from a hosting provider or anonymizer | attackers replay from VPS and proxies | access.hosting_provider, access.anonymizer | medium |
| SSO into sensitive apps from the new network | the attacker is using what they stole | app.sso_after_suspicious | high |
On Identity Engine orgs, also look for user.session.context.change (the session's context changed enough to warrant policy re-evaluation) and policy.auth_reevaluate.fail, both listed in Okta's event types catalog. The analyzer does not use them as detections yet; the event table shows them.
Walking through a hit
Say the analyzer reports "Session used from several networks" for a.user:
- Open the evidence and sort by time. Where did the session start? The
user.session.start(and MFA) should come from the user's usual network. The later requests from a second ASN are the candidate replay. - Characterise the second network.
asOrga residential ISP in the user's city is probably the user's own phone or home. A cloud provider, a VPS host, or a country the user has never been in is not. - Check the user agent. Same browser string on both networks points to the user moving; a different OS or browser on the second network points to a copy of the cookie.
- List what the second network did. SSO targets, admin actions, factor enrollment. An attacker with a hijacked session often enrolls a factor or creates a token to persist beyond the session's lifetime.
- Check the user's machine. Cookie theft by infostealer means the endpoint is compromised; resetting the Okta password does not clean it.
False positives you will meet
- Phones switching between Wi-Fi and mobile data. Two ASNs (the home ISP and the mobile carrier) in one session, same user agent. Very common.
- Corporate VPN connected mid-session. The session starts on the home ISP, continues from the VPN egress. If your VPN egresses from a cloud provider, it also trips the hosting-provider rule.
- Security proxies and secure web gateways that egress from their own ASN for some traffic and not other.
- Browser updates during a long session change the user-agent string.
These are why the multi-ASN rule is a high finding, not a critical one. The tuning article covers how to handle them; the short answer is to know your VPN egress ASNs and mobile carriers and check them first.
Containment
- Clear the user's sessions and revoke their tokens: this invalidates the stolen cookie in Okta.
- Revoke sessions in downstream apps the attacker reached. Their sessions are independent of Okta's.
- Treat the endpoint as compromised if an infostealer is plausible: rebuild, then reset every credential used on it.
- Reset password and factors if the attacker also enrolled a factor or you cannot rule out credential theft.
Prevention
Okta Security's recommendations against cookie replay include binding admin sessions to the network (IP or ASN), requiring re-authentication for sensitive resources, phishing-resistant authenticators (which defeat adversary-in-the-middle phishing), device management requirements, and shorter session lifetimes where the data is sensitive (Okta Security). After the HAR-file incident Okta also described network-location binding for admin sessions as a product enhancement (root cause article).