Session Hijacking & Token Theft

What it is

Session hijacking uses a stolen or misused session identifier to act as a signed-in user. Cookies and bearer tokens often represent authorization already granted after login. If the service accepts a replayed token, an attacker may not need the password or another MFA challenge. Not every token is equally reusable; expiry, scope, and binding affect the impact.

How it works

Tokens escape through malware, insecure storage, logs, vulnerable browser code, or other leaks. The attacker presents them to the service as proof of an existing session. Cookie attributes have distinct roles: Secure limits transport to HTTPS, HttpOnly restricts script reading, and SameSite helps limit cross-site sending. None makes a compromised endpoint harmless.

How people get tricked

Users assume MFA protects every later action automatically. Developers may treat a token as an ordinary string and put it in logs or URLs. XSS can perform actions within a session even when HttpOnly prevents reading the cookie directly.

Example scenario

An infostealer captures a logged-in browser session. The service accepts it from another environment, allowing access without a fresh password-and-code exchange.

Warning signs

• Concurrent or unfamiliar sessions and unusual post-login actions.
• Token values found in logs or shared material.
• Suspicious activity continues after a password change that did not revoke sessions.

If it happens to you

Revoke compromised sessions and refresh tokens using the provider's controls. Fix the theft source and rotate other exposed secrets. Confirm that password resets and sign-out actually invalidate the relevant access rather than assuming every provider behaves the same way.