What Is Session Hijacking? How Attackers Steal Logins

Session hijacking is an attack in which someone takes over a logged-in user's active web session by stealing, predicting, or forcing the use of a valid session token — usually a cookie — so they can impersonate that user without ever knowing their password. Because the victim's browser has already proven its identity to the site, a hijacked session hands the attacker instant access: no password, no login prompt, and often no multi-factor authentication (MFA) check, since the server believes it is still talking to the real, already-authenticated user.

That is the detail that makes session hijacking different from, and in some ways more dangerous than, ordinary credential theft. A phished or stuffed password still has to pass a login form (and potentially an MFA challenge). A stolen session token skips login entirely.

What is session hijacking?

When you log into a website, the server does not ask for your password on every single page load. Instead, after you authenticate once, the server issues a session token — a long, randomly generated string — and your browser stores it, typically in a cookie. On every subsequent request, your browser automatically presents that token, and the server treats its holder as "you." According to Wikipedia's entry on session hijacking, the attack is "the exploitation of a valid computer session... to gain unauthorized access to information or services," and is especially associated with the theft of the "magic cookie" used to authenticate a user to a remote server.

Whoever holds a valid, unexpired session token is, as far as the server can tell, the legitimate account owner. Session hijacking is the practice of getting hold of that token through means other than logging in yourself, and then using it to ride on someone else's authenticated session.

How session hijacking differs from phishing and credential stuffing

These three attacks are often mentioned together, but they target different parts of the login flow:

This is why security teams increasingly treat session/cookie theft as a distinct, higher-priority risk than plain password phishing — or its voice-call cousin, vishing: MFA stops someone from logging in as you, but it does nothing once an attacker already has a live, authenticated session in hand. Microsoft's Threat Intelligence team has been explicit about this: describing adversary-in-the-middle (AiTM) cookie theft, it states plainly that stealing a session this way "is not a vulnerability in MFA" — the attacker simply inherits a session that already satisfied MFA.

How attackers steal or create session tokens

There is no single "session hijacking exploit." It's an umbrella term for several distinct techniques that all end with the attacker holding a valid token.

1. Session sniffing (session side-jacking)

On an unencrypted or poorly encrypted connection — classically an open Wi-Fi hotspot — an attacker running a packet sniffer can read a session cookie directly off the wire. Wikipedia notes that this became a mainstream, practical threat with the 2010 release of Firesheep, a Firefox extension that let anyone on a shared network capture unencrypted session cookies from sites like Facebook and Twitter with a few clicks; the resulting backlash is part of why major sites moved to HTTPS by default afterward (see Firesheep). The OWASP Session Management Cheat Sheet treats this as the baseline case for why TLS must cover an entire session, not just the login form.

2. Cross-site scripting (XSS) token theft

If a site has an XSS flaw, an attacker can inject JavaScript that runs in a victim's browser under that site's origin and simply reads document.cookie, then sends the value to a server the attacker controls. MDN's cookie documentation describes exactly why the HttpOnly attribute exists: a cookie marked HttpOnly "can't be accessed by JavaScript... This precaution helps mitigate cross-site scripting (XSS) attacks." Without that flag, any XSS bug anywhere on the page becomes a session-stealing bug.

3. Session fixation

Instead of stealing an existing token, the attacker plants one. A classic version: the attacker sends a victim a link containing a session ID the attacker already knows (or otherwise forces the browser to adopt it), waits for the victim to log in using that ID, and then uses the same, now-authenticated ID themselves. OWASP's guidance is to run session handling in "strict" mode — accepting only session IDs the server itself generated, and never ones supplied via a URL parameter — plus regenerating the session ID at every login, which defeats fixation outright.

4. Man-in-the-middle and adversary-in-the-middle (AiTM) phishing

A classic man-in-the-middle (MITM) attacker sits between the user and server and intercepts traffic directly. A more modern and far more damaging variant is AiTM phishing, where the attacker runs a reverse-proxy phishing site (toolkits like Evilginx2, Modlishka, and Muraena are commonly used) that relays the real login flow — including any MFA step — between the victim and the genuine site, while quietly capturing the resulting session cookie. Microsoft's July 2022 threat intelligence writeup on this technique found campaigns that had targeted more than 10,000 organizations since September 2021, with attackers beginning financial fraud roughly five minutes after the first phishing sign-in.

5. Malware and infostealers

Session tokens are also simply stolen off the disk. "Infostealer" malware families routinely harvest saved browser cookie databases (along with saved passwords and autofill data) and upload them wholesale to an attacker, who can then import a victim's cookies into their own browser and resume the session cold, with no phishing page involved at all. Wikipedia's session-hijacking article cites Google's Threat Analysis Group detecting campaigns in late 2019 that used exactly this method — infostealer malware plus stolen cookies — to hijack YouTube creator channels, with roughly 4,000 accounts restored by Google as of October 2021. Infostealers often arrive bundled with other spyware, such as a keylogger capturing everything else typed on the machine.

6. Brute force and predictable tokens

Older or poorly built applications sometimes generate session IDs from predictable inputs (timestamps, sequential counters, weak random number generators). Imperva's write-up on session hijacking lists "calculation" of weakly generated IDs and outright brute-forcing short IDs alongside theft as viable attack paths. This is why OWASP specifies a minimum of 64 bits of entropy from a cryptographically secure random number generator for any session identifier.

Why session hijacking is hard to notice

A hijacked session usually produces no password-reset email, no "new device" login alert in some setups, and no failed-login log entry, because from the server's point of view, nothing failed — a valid, already-authenticated token was simply presented again, possibly from a new IP address or browser. That's what makes it attractive to attackers and why detection has to rely on behavioral signals rather than authentication failures.

How to prevent session hijacking

Defense against session hijacking is layered: no single control stops every technique above, but the combination closes off most paths.

Encrypt everything, not just login

Serve the entire site over HTTPS, enforce it with HTTP Strict Transport Security (HSTS), and never let a session drop back to plain HTTP mid-visit. This single control eliminates session sniffing on open networks and most classic MITM interception, though it does not stop AiTM phishing proxies, which relay HTTPS traffic rather than breaking it.

Set the right cookie flags

Per MDN and OWASP guidance, a session cookie should carry:

• Secure — the cookie is only ever sent over an encrypted HTTPS connection.
• HttpOnly — JavaScript cannot read the cookie, closing off the simplest XSS-based theft route.
• SameSite=Strict or Lax — the browser withholds the cookie on most cross-site requests, which OWASP recommends setting explicitly rather than relying on a browser default (Chrome currently defaults unset cookies to Lax).
• A __Host- name prefix — OWASP's cheat sheet recommends this for session cookies, which forces Secure, forbids a Domain attribute, and pins Path=/, making the cookie harder to overwrite from a sibling subdomain.

Regenerate the session ID at login and on privilege changes

OWASP calls for issuing a brand-new session identifier immediately after a successful login, and again after any privilege change (password reset, role change, elevation to an admin context), while invalidating the old one server-side. This single step defeats session fixation, since any ID an attacker planted before login is discarded the moment authentication succeeds.

Keep sessions short-lived

OWASP recommends an idle timeout (as short as 2–5 minutes for high-value applications, 15–30 minutes for lower-risk ones) plus an absolute maximum session lifetime regardless of activity. Shorter lifetimes shrink the window in which a stolen token remains useful.

Use MFA — and phishing-resistant MFA where possible

MFA stops attackers from logging in with a stolen password, and it raises the bar against simple credential-based attacks. It does not, by itself, stop AiTM cookie theft, since the session cookie is captured only after MFA succeeds. Microsoft's guidance is to move toward phishing-resistant methods, such as FIDO2 security keys or certificate-based authentication, which are far harder to proxy through an AiTM kit than a one-time code typed into a lookalike page.

Monitor for anomalous session reuse

OWASP recommends logging session creation, renewal, and destruction events (using a salted hash of the token rather than the raw value), and alerting on signals such as a session cookie suddenly being used from a new IP address, country, or browser/User-Agent string mid-session, or many session IDs being attempted from one source. Microsoft similarly points to tools like Continuous Access Evaluation and anomalous-token detection, which can revoke a session in near real time once risk signals change, even though a stolen cookie was technically valid.

Give users visibility and control

Let account holders see and revoke active sessions/devices from their account settings, and consider terminating all other sessions automatically whenever a password is changed, which cuts off any session an attacker was quietly riding on.

Who is most at risk

Session hijacking disproportionately affects people and organizations with high-value accounts and predictable habits: frequent public Wi-Fi users (travelers, remote workers in cafes and airports), anyone whose browser or device is already compromised by malware, and employees at organizations that rely solely on password-plus-one-time-code MFA against targeted AiTM phishing campaigns. Content creators and social media account owners have also been singled out specifically for cookie-theft malware campaigns, since a hijacked session can be used to post, message, or monetize on their behalf without ever needing to reset their password.

What to do now

For everyday users: avoid logging into sensitive accounts over open/public Wi-Fi without a VPN, keep your browser and operating system patched (infostealer malware often rides in through outdated software or cracked downloads), be skeptical of login pages reached via a link rather than typed directly or opened from a bookmark, and use a password manager plus phishing-resistant MFA where a site offers it. Log out of shared or public computers every time, and periodically check your account's "active sessions" or "connected devices" page if the service offers one, revoking anything you don't recognize.

For developers and site operators: audit your session cookies today for the Secure, HttpOnly, and SameSite flags; confirm your framework regenerates the session ID at login rather than reusing a pre-auth value; set sane idle and absolute timeouts; and add logging for session anomalies (IP/User-Agent changes mid-session, impossible-travel logins) so a stolen token gets flagged even when the login itself looked completely legitimate.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage