Session Theft: The New Battle After Authentication

What has been observed

Tokens inside support files. Okta’s published root-cause account of an incident in its customer support system found that some files uploaded to support cases were HAR files, which are browser traffic captures, and that they contained session tokens. The attacker accessed files tied to 134 customers, under 1% of Okta’s customer base, and used tokens from the HAR files to hijack the legitimate Okta sessions of five customers. Okta’s own logging missed the downloads for 14 days: opening a case attachment generated one kind of log event, while browsing straight to the Files tab, as the attacker did, generated a different one. The activity surfaced when a customer, BeyondTrust, supplied a suspicious IP address. Okta’s remediation included revoking the tokens in the affected files and releasing session token binding for administrators based on network location, with re-authentication when the network changes.

A valid session after a phish. In the SharePoint-themed campaign Microsoft documented against energy-sector organizations, the attacker held a valid session and used it from a different IP address, created a mail rule to hide replies, and sent more than 600 follow-on phishing emails. Microsoft’s point is that a password reset does not end the attacker’s access because the session stays valid until it is revoked.

Cookies copied by malware. Google describes cookie theft as a standing problem and states plainly that there is no reliable software-only way to stop malware on an operating system from exfiltrating cookies. Its answer, Device Bound Session Credentials, aims to make the copies unusable.

Three routes, three different fixes

What binding does and does not cover today

The coverage gap is the practical finding. Binding exists for a subset of browsers, applications and device types, and the documentation for each is specific about its scope. Check current scope before designing around any of them.

Shortening the window

Lifetime limits do not stop theft, but they cap how long a stolen session pays off. NIST SP 800-63B-4 gives reference points for federal assurance levels. At AAL2, the overall session timeout should be no more than 24 hours and the inactivity timeout no more than one hour. At AAL3, the overall timeout must be no more than 12 hours and the inactivity timeout should be no more than 15 minutes. These are federal guidance, not a private-sector mandate, and shorter sessions cost usability. They are a sensible starting range for administrative and financial applications.

Detecting a stolen session in use

The attacker’s session looks like the user’s. The tells are in context.

• A session used from a network, address or device context different from the one that created it. Microsoft describes exactly this after AiTM capture.

• Token use with no matching interactive sign-in from the user’s usual environment.

• Persistence actions shortly after, such as a new MFA method, a new mail rule that deletes and marks messages read, or new application consent.

• Bulk outbound mail or unusual download volume from an account that normally does neither.

• Administrative consoles reached from an unfamiliar network. Okta’s binding to network location exists because this is a strong signal.

• Coverage across every path to the same data. Okta’s missed downloads came from an alternate route that produced a different log event. Audit the event types for each way a record can be read, not just the common one.

Response order

1. Revoke sessions and refresh tokens. Resetting the password alone leaves the session valid.

2. Review and reverse MFA method changes made during the session.

3. Remove mail rules and other persistence the account created.

4. Establish what the session touched, from the issuing sign-in onward.

5. If the source was an artifact, revoke every token it contained and fix how that artifact type is handled.

Where to start

Do not bind everything at once. Rank applications by what a stolen session could do: administrative consoles, finance and payment systems, source code, and any system that holds support or diagnostic data. Apply binding and short lifetimes there first, and build detection on the same list.

What is not known

No authoritative public data shows how session theft divides across the three routes. Google’s reduction claim is the vendor’s own and comes without figures. Binding scope is changing, so the table above should be read as a snapshot of the documentation, not a permanent position.

Next step

Run one controlled exercise: take a test account’s session, replay it from a second network under an approved plan, and see which alert, if any, fires and how quickly the session can be revoked. The result shows whether your detection depends on binding that is not yet in place.

Sources

1. Okta Security. Root cause of unauthorized access to Okta’s support case management system. sec.okta.com

2. Google. Protecting cookies with Device Bound Session Credentials. blog.google

3. Microsoft Learn. Token protection in Microsoft Entra Conditional Access. learn.microsoft.com

4. Microsoft Security Blog. Multistage AiTM phishing and BEC campaign abusing SharePoint. microsoft.com

5. NIST. SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. csrc.nist.gov