5.2 Session Hijacking
Key Takeaways
- Session hijacking takes over an already-authenticated session, sidestepping the need to crack credentials — it can be network-level (TCP/IP) or application-level (stealing a session token/cookie).
- TCP session hijacking requires sniffing the conversation, predicting the next sequence/acknowledgment numbers, then injecting spoofed packets and desynchronizing the legitimate client (often with a forged RST).
- An 'ACK storm' — endless ACK exchange between the desynchronized hosts — is a telltale side effect of active TCP hijacking.
- Application-level hijacking relies on session-token theft via XSS, packet sniffing of cleartext cookies, session fixation, or predictable session IDs.
- The single most effective defense is end-to-end encryption (TLS/HTTPS, SSH, IPsec); supporting controls are unpredictable session IDs, HttpOnly/Secure cookies, and session regeneration after login.
What Session Hijacking Is
Session hijacking is the act of taking over a valid, already-authenticated session between two hosts. Its power lies in avoiding authentication entirely — the attacker inherits the victim's logged-in state, so there is no password to crack and often no second authentication challenge. CEH divides hijacking into two levels:
- Network-level (TCP/IP) hijacking — the attacker manipulates the transport-layer session itself (TCP sequence numbers, IP spoofing) to inject or take over the data stream.
- Application-level hijacking — the attacker steals or predicts the higher-layer session identifier (a session cookie or token) that the application uses to recognize the user, then replays it.
Hijacking can be active (the attacker takes over the session, pushing the legitimate user out) or passive (the attacker silently monitors traffic, hijacking only when useful). The general attack flow is: sniff the traffic → monitor the session → desynchronize the connection → predict the sequence numbers → inject/take over packets.
TCP Session Hijacking and Sequence Prediction
TCP relies on sequence numbers (SEQ) and acknowledgment numbers (ACK) to order bytes and confirm delivery. To hijack a TCP session the attacker must be on-path (or able to sniff) and must correctly predict the next expected SEQ/ACK values so injected packets are accepted as legitimate. The steps are:
- Sniff the conversation to learn the current SEQ/ACK and the Initial Sequence Number (ISN) behavior.
- Predict the next sequence number — historically easy when ISNs were predictable; modern OSes use randomized ISNs, which is why prediction from off-path is now very hard.
- Desynchronize the victim, commonly by injecting a spoofed TCP RST (reset) or FIN to tear down the victim's half while the server believes the session is alive.
- Inject the attacker's packet bearing the predicted SEQ so the server accepts it as the victim's next data.
RST hijacking specifically forges a reset packet with the spoofed source and a correct acknowledgment number to drop the victim's connection. When both endpoints fall out of sync, they exchange ACKs trying to recover — producing a recognizable ACK storm, a key indicator of active TCP hijacking.
Blind Hijacking, MITM, and Application-Level Token Theft
If the attacker cannot see the traffic, they perform blind hijacking — guessing SEQ/ACK without feedback; success is low against randomized ISNs. A man-in-the-middle (MITM) position (achieved via ARP spoofing, DNS spoofing, or a rogue access point) makes hijacking far easier because the attacker sees and relays every packet and can selectively modify the stream.
Application-level hijacking targets the session token rather than the TCP stream. Common vectors:
| Technique | How It Captures the Session |
|---|---|
| Session sniffing | Capturing a cleartext (non-TLS) session cookie off the wire |
| Cross-site scripting (XSS) | Injected script reads document.cookie and exfiltrates it |
| Session fixation | Attacker sets a known session ID, victim authenticates into it |
| Predictable session ID | Weak/sequential token generation lets the attacker guess valid IDs |
| Session replay | Reusing a captured token before it expires |
Tools associated with hijacking include Ettercap and bettercap (MITM/ARP poisoning), Hamster/Ferret and the historic Firesheep (sidejacking cleartext cookies), and Burp Suite/OWASP ZAP for token analysis and replay.
Sidejacking is a specific application-level case: an attacker on the same network (an open Wi-Fi hotspot is the classic setting) sniffs an unencrypted session cookie sent over HTTP after the user already authenticated over HTTPS, then replays that cookie to impersonate the victim. The defense is to serve the entire site over HTTPS and mark the cookie Secure so it is never transmitted in the clear. This is why mixed HTTP/HTTPS sites were historically so dangerous: the login was protected but the session cookie leaked on every subsequent plain-HTTP page.
The broader lesson is that authentication and session protection must extend to every request in a session, not just the login form, and that the HSTS (HTTP Strict Transport Security) header should force browsers to use HTTPS so no request ever downgrades to cleartext.
Countermeasures
Defenses split between network-level and application-level controls, but the unifying theme is encryption, which makes both sniffing and injection impractical.
| Threat | Countermeasure |
|---|---|
| TCP injection / sniffing | IPsec, SSH, or TLS to encrypt and integrity-protect the channel |
| Sequence prediction | Randomized ISNs (default in modern OSes) |
| Cleartext cookie theft | HTTPS everywhere + Secure cookie flag |
| XSS token theft | HttpOnly cookie flag, output encoding, Content Security Policy |
| Session fixation | Regenerate the session ID after login; never accept client-set IDs |
| Predictable IDs | Long, cryptographically random session tokens |
| Stale/long sessions | Short idle and absolute timeouts, logout invalidation |
Additional best practices: bind sessions loosely to context (user-agent/IP changes prompt re-auth), use multi-factor authentication so a stolen session has limited blast radius, and monitor for ACK storms and duplicate-source anomalies. On the exam, when asked for the most effective single control against session hijacking, the answer is encryption (use TLS/SSH/IPsec) — it neutralizes the sniffing and injection that every hijack depends on.
During an active TCP session hijack, both the legitimate client and the server begin rapidly exchanging ACK packets in an attempt to resynchronize. What is this observable side effect called?
Why has off-path TCP sequence-prediction hijacking become much harder on modern operating systems?
An application assigns a session cookie at first visit and keeps that same ID after the user logs in, allowing an attacker who planted the ID to ride the authenticated session. Which weakness is this, and what fixes it?