Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 10 November 2026.

Part of the Wolfcore Resources library: Hacking techniques explained.

In one sentence: Session hijacking is when an attacker steals the small token that proves you are already signed in, then uses it to act as you without needing your password or your MFA code.

What session hijacking is

When you sign in to a website, the server gives your browser a session token, usually stored in a cookie. Your browser sends it with every request so you do not have to log in again. Whoever holds the token is treated as you.

OWASP describes the risk plainly: disclosure, capture, prediction, brute force or fixation of the session ID leads to session hijacking, where an attacker can fully impersonate a victim user. MITRE tracks this as ATT&CK T1539, Steal Web Session Cookie, and notes that session cookies can be used to bypass some multi-factor authentication protocols.

How it works

1. You sign in properly. Password and MFA both succeed, and the server issues a token.
2. The attacker gets a copy. MITRE lists several routes: cookies can be found on disk, in browser process memory and in network traffic, and attackers may inject malicious JavaScript into sites or run a malicious proxy in a phishing campaign.
3. The attacker replays it. They present the token to the service from their own machine. The server sees a valid token and lets them in.
4. They act as you. They read mail, change settings, create forwarding rules or approve payments, until the token expires or is revoked.

What they are after is access that looks legitimate. Because the sign-in step is skipped, the usual alarms for a wrong password never fire.

Vulnerable and fixed pattern

A generic illustration of a login cookie, not tied to any product.

Weak: the cookie can be read by page scripts and sent over plain HTTP.

Set-Cookie: sessionid=abc123

Better: OWASP’s example sets Secure, HttpOnly and SameSite and a host-only prefix.

Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/

OWASP explains that the Secure attribute tells browsers to send the cookie only over HTTPS, and that the HttpOnly attribute stops scripts reading it through document.cookie. HttpOnly does not stop an attack running inside the page, so cross-site scripting must be fixed too: see how XSS works.

Who it affects and how badly

• Sole trader to 10 staff (trades, recruitment, estate agents): a stolen Microsoft 365 or accounting session. Worst case: invoice fraud from a real mailbox.
• 10 to 250 staff (accountancy, legal, SaaS start-ups): a stolen admin session on a business app. Worst case: data taken and customers contacted.
• Regulated firms (fintech, insurance, healthcare): stolen sessions on systems holding personal data. Worst case: a reportable breach and loss of client trust.

Real example

In October 2023 Okta reported that an attacker used a stolen credential to reach its support case system and view files uploaded by certain customers. Okta explained that HTTP Archive (HAR) files customers upload for troubleshooting can contain cookies and session tokens that malicious actors can use to impersonate valid users, and revoked the embedded tokens. Okta’s closing report added options such as binding sessions to an IP address, which invalidates a session if the source IP changes. The lesson for small firms: never send support files containing session data without cleaning them first.

What we check on a test

• Cookie flags on every session cookie: Secure, HttpOnly, SameSite.
• Whether a new session ID is issued after login and after privilege changes.
• Idle and absolute session timeouts, and whether logout really ends the session on the server.
• Whether tokens appear in URLs, logs or error messages.
• Whether cross-site scripting could expose the token.

The UK angle

Cyber Essentials v3.3 expects MFA on administrative accounts and accounts accessible from the internet. That is necessary, and it is not the whole answer: a stolen session token comes after MFA. Treat MFA as the front door lock and session protection as the second lock.

Diagram

How to detect it

1. Check sign-in logs in Microsoft 365 or Google Workspace for one session appearing from two locations or devices in a short time.
2. Look for new mailbox forwarding rules and unexpected consent grants.
3. Watch for users who report being signed out or seeing unknown sessions.
4. Alert on sign-ins from commercial VPN or hosting ranges for staff who normally work from one place.

How to prevent it

1. Use phishing-resistant MFA and managed devices, so tokens are harder to capture; see phishing-resistant MFA.
2. Set Secure, HttpOnly and SameSite on all session cookies.
3. Serve everything over HTTPS only.
4. Issue a new session ID at login, and expire sessions on idle and absolute timeouts.
5. Revoke all sessions when a password changes or an account is suspected stolen.
6. Fix cross-site scripting, and keep malware protection on every device.
7. Sanitise HAR files and logs before sharing them with a supplier.

FAQ

Does MFA stop session hijacking? Not by itself. MITRE says stolen session cookies can bypass some MFA protocols.

What is the quickest response? Revoke the user’s sessions and reset the password.

Is HttpOnly enough? No. It stops scripts reading the cookie but not an attack running in the page.

Related terms

cross-site-scripting, how-xss-works, multi-factor-authentication, phishing-resistant-mfa, mfa-fatigue-attack, business-email-compromise

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. See web application penetration testing, penetration testing and the free web vulnerability scan.