What Is Session Hijacking? How Attackers Take Over Your Sessions

Session hijacking is when an attacker steals or takes over an already-authenticated session, using a stolen session token or cookie to impersonate a legitimate user without ever needing their password, since the session itself proves they’re already logged in.

What Is Session Hijacking?

Session hijacking means an attacker takes control of a legitimate user’s already-authenticated session rather than breaking in from scratch. Once a session has been hijacked, the attacker doesn’t need a password, doesn’t need to complete MFA, and doesn’t need to trigger any of the usual login checks at all.

The reason this matters so much is simple. A stolen session is functionally identical to a stolen identity, at least as far as the server is concerned. The service already believes this person proved who they are.

Cookie Hijacking vs Session Hijacking — a Distinction Worth Getting Right

Here’s a distinction worth stating precisely, since these terms get used loosely and interchangeably constantly.

Cookie hijacking specifically means stealing the browser cookie that stores session data. Session hijacking is the broader outcome: taking control of an authenticated session by any means at all. Cookie theft happens to be the most common method today, but it’s not technically the only path to the same result.

How Does an Attacker Steal a Session?

Several distinct methods can achieve session hijacking, though they’re genuinely not all equally common anymore.

• Packet sniffing: intercepting unencrypted network traffic to capture a session cookie in transit, largely mitigated by widespread HTTPS adoption today.
• Cross-site scripting (XSS): injecting malicious code into a vulnerable website that exfiltrates a victim’s session cookie directly to the attacker.
• Session fixation: forcing a known session ID onto a victim before they log in, so the attacker already holds a valid session identifier once authentication completes.
• Adversary-in-the-middle (AiTM) phishing: today’s dominant method, positioning a reverse proxy between the victim and the real login page, capturing the session cookie the moment MFA completes.

Session Hijacking Methods

Method	How It Works
Packet sniffing	Intercepts unencrypted traffic containing a session cookie
Cross-site scripting	Injects code that exfiltrates a cookie directly
Session fixation	Forces a known session ID onto a victim before login
AiTM phishing	Proxies a real login, capturing the cookie after MFA

Pass-the-Cookie — Why Security Teams Call This “the New MFA Bypass”

Pass-the-cookie means replaying a stolen session cookie to gain authenticated access without ever entering a password or completing MFA again. The cookie itself proves that verification already happened, making it functionally equivalent to bypassing MFA entirely.

Here’s why security teams specifically frame it this way rather than calling it something milder. MFA doesn’t get defeated through brute force or guessing here. It simply gets skipped entirely, since the server sees a valid, already-authenticated session and has no reason to ask for verification again. From the server’s own perspective, nothing suspicious happened at all.

The Current Threat Landscape: Named Infostealers and AiTM Phishing Kits

Tycoon 2FA and EvilProxy are the dominant adversary-in-the-middle phishing-as-a-service kits currently active. Both position a reverse proxy between a victim and a genuine Microsoft 365 or Google login page, capturing credentials and the resulting session cookie in real time as the victim completes a normal, legitimate-looking login.

Tycoon 2FA has been the dominant global AiTM platform since August 2023. Microsoft’s Digital Crimes Unit, working with Europol, disrupted its infrastructure in early 2026, and campaign volume dropped briefly to roughly a quarter of pre-disruption levels. It has since returned to normal activity, illustrating how resilient this infrastructure genuinely is against takedown efforts alone.

Infostealer malware compounds this problem separately. Rather than proxying a live login, infostealers sit quietly on an already-compromised device, harvesting stored session cookies directly from the browser and exfiltrating them for sale or reuse elsewhere, regardless of how the device got compromised in the first place.

Real Examples: Electronic Arts, Lapsus$, and What Happened

Here’s a real breach worth walking through in specific detail, since the actual mechanics are more striking than a vague summary suggests. The Lapsus$ extortion group purchased a stolen session cookie belonging to an Electronic Arts employee for just $10, from a dark web marketplace called Genesis.

That single cookie gave them access to EA’s Slack instance, letting them convincingly spoof an existing employee’s login. From inside Slack, the attackers messaged EA’s IT support team directly, claiming they’d lost their phone at a party the night before and couldn’t complete MFA. IT support issued them a fresh MFA token, twice, granting full network access based entirely on a social engineering pretext layered on top of a stolen cookie.

The result: 780 gigabytes of stolen data, including source code for the Frostbite game engine and FIFA 21, later used in an extortion attempt against the company. Ten dollars and a believable excuse turned into one of gaming’s largest source code leaks. That’s the real, concrete scale a single stolen session cookie can reach once it lands in the right, socially confident hands.

Does Switching to Passkeys Solve This? What NCSC’s Own Guidance Says

Here’s the honest, technically precise answer most competitor content oversimplifies badly in one direction or the other.

NCSC’s 2026 guidance, published at CYBERUK, formally recommends passkeys as the default login method wherever a service supports them, a genuine departure from decades of password-plus-MFA advice. Passkeys use device-bound cryptographic key pairs rather than shared secrets, meaning they only authenticate against the legitimate, exact origin domain, making them genuinely resistant to AiTM credential phishing in a way traditional MFA simply isn’t.

Here’s the honest limitation worth stating directly, drawn from NCSC’s own published research rather than marketing enthusiasm. Passkeys stop an attacker from phishing your credentials in the first place. They don’t inherently stop what happens after a legitimate, successful login. NCSC’s own technical paper explicitly names session hijacking as one of the attack categories it evaluated, and notes that a session cookie generated after a completely legitimate passkey login remains vulnerable to theft through infostealer malware or a compromised endpoint, exactly the same way a traditional session cookie would be. NCSC’s research also flags a genuine emerging concern: downgrade attacks, where an AiTM proxy deliberately forces a fallback to a non-FIDO2 authentication method still registered on the account, specifically to route around passkey protection entirely.

The practical takeaway worth sitting with directly: passkeys close the credential-theft door very effectively, but the session-theft door stays open unless something else, specifically token binding, closes it too. An organization that adopts passkeys and stops there has genuinely improved its posture, but hasn’t fully solved session hijacking. Cyber Security Solutions Ltd routinely sees businesses treat passkey rollout as the finish line, when NCSC’s own research makes clear it’s a major, necessary step, not a complete, standalone solution to this specific problem.

The Hierarchy of Defences — From Basic to What Closes the Gap

1. Enforce HTTPS and short session timeouts as a basic, foundational floor, closing off passive interception and limiting how long a stolen cookie stays useful.
2. Deploy phishing-resistant MFA, passkeys or FIDO2 hardware keys, closing the AiTM credential-theft vector directly, per NCSC’s current recommendation.
3. Monitor for impossible-travel and anomalous session patterns, since a stolen session often shows up from an unexpected location or device shortly after legitimate use.
4. Implement token binding or device-bound session credentials specifically, the layer that closes the remaining gap passkeys alone don’t address, tying a session cryptographically to the specific device that created it so a copied cookie becomes useless elsewhere.
5. Reduce cookie and session lifetime deliberately for high-value applications, shrinking the window a stolen session remains valid even if every other layer fails.

Conclusion

Session hijacking works because it skips the front door entirely and walks in through a session that’s already open, which is exactly why MFA alone was never going to be the full answer. Passkeys close the credential-theft path NCSC now recommends prioritizing, but pair them with real session monitoring and token binding to close what’s left. If you want help figuring out where your own session security genuinely stands, Cyber Security Solutions Ltd can walk through it with you.