Session Hijacking: Cookies, Tokens, Detection, and Response
Learn how sessions are created, stolen, replayed, detected, revoked, and investigated across browsers and cloud services.
A session is delegated authority
After authentication, applications issue cookies or tokens so users do not prove identity on every request. These artifacts may authorize valuable actions without exposing the password. Their audience, scope, lifetime, storage, and refresh behavior define the damage possible after theft.
Treat the session as a credential with a lifecycle: issue, use, renew, elevate, expire, and revoke. Browser cookies may be sent automatically, bearer tokens may work for anyone who presents them, and refresh tokens may mint new access tokens after the original expires. Document which service validates the artifact and whether it is bound to a device, client, cryptographic key, or transaction. Labels such as “temporary token” are meaningless without the renewal path.
Understand common theft paths
Attackers obtain sessions through infostealers, malicious extensions, cross-site scripting, adversary-in-the-middle phishing, exposed logs, insecure storage, or compromised endpoints. Secure flags and short lifetimes help, but endpoint trust and application design remain part of the boundary.
Controls address different theft paths. HttpOnly can keep some cookies away from browser scripts but cannot stop malware with user-level access. Secure limits transport to encrypted connections but does not make the endpoint trustworthy. SameSite constrains cross-site sending but is not a general anti-theft control. Avoid logging secrets, minimize token scope, harden extension and endpoint policy, rotate identifiers after privilege changes, and make high-risk actions require fresh proof.
Detect use rather than possession
Detection usually depends on use: unfamiliar devices, impossible sequences, unusual token refresh, privilege changes, new integrations, or access to atypical resources. IP changes alone are weak evidence. Correlate identity, device, application, and resource activity over a bounded period.
Build detections around combinations and consequences. A new network plus a known managed device may be travel; an old cookie used from a new client immediately before mailbox-rule creation is more concerning. Preserve token or session identifiers only where policy permits, and avoid putting the secret itself in logs. Compare issuance and use times, authentication method, client properties, refresh behavior, sensitive operations, and concurrent legitimate activity. State when privacy relays, mobile networks, or shared proxies limit location conclusions.
Contain every surviving access path
Resetting a password may leave cookies, refresh tokens, API keys, OAuth grants, and application sessions alive. Revoke the relevant artifacts, remove persistence, isolate affected devices, and require trusted reauthentication. Preserve enough evidence to explain which authority was actually abused.
Containment should cover the issuer and every relying application that accepted the session. Use provider-supported “sign out everywhere” or token revocation where available, but verify its scope and delay; some applications cache authorization or remain offline. Remove newly registered factors, devices, integrations, forwarding rules, and credentials. If the source device may be compromised, keep it from receiving the replacement secret and follow the endpoint-response process before restoring access.
Scope before declaring recovery
Determine when the session was acquired, where it was replayed, which resources it reached, and whether new credentials or persistence were created. Malware intelligence can help explain the theft mechanism, but local evidence establishes scope and consequence.
Start before the first confirmed misuse because theft and replay may be separated by hours or weeks. Review authentication, token issuance, mailbox, cloud, developer, finance, and administrative records according to the account’s reach. Distinguish “artifact could have been collected” from “artifact was used” and “resource was changed.” Close only after the team has bounded exposure, restored a trusted identity path, monitored for reuse, and recorded any retention gaps that limit confidence.
