Session hijacking involves taking over an active user session by stealing or predicting the session token. This module covers TCP session hijacking, SIDJACKING, XSS-based attacks, cookie poisoning, session fixation, and prevention measures including HTTPS and secure cookie flags.
The CEHStudy app carries 13 flashcards for Module 11 across 3 sections — learn the three hijacking flavors (network/TCP, web-session, client-side) in order; every exam question pairs one attack with its matching defense (HTTPS, ID rotation, cookie flags).
Key Topics Covered
TCP session hijacking: sequence prediction, IP spoofing, RST injection
SIDJACKING: stealing unencrypted session IDs over the network
XSS-based session hijacking: injecting JavaScript to steal cookies
TCP Session Hijacking: Attacker takes over an established TCP connection by predicting sequence numbers, spoofing the source IP, and injecting packets. Requires the attacker to be in-line with the traffic.
SIDJACKING: Stealing a user's session ID (cookie) from network traffic. Works when sessions use HTTP (not HTTPS). Tools: Wireshark, Firesheep.
XSS-Based Hijacking: Injecting malicious JavaScript into a vulnerable web page that reads the victim's cookies and sends them to the attacker. More common than SIDJACKING today.
Session Fixation: Attacker sets a known session ID for the victim, then waits for the victim to authenticate with that same ID. The attacker already knows the session token.
Cookie Poisoning: Tampering with session cookie data stored on the client side to manipulate application behavior or gain elevated privileges.
How to Study This Module
Understand the 4 steps of TCP session hijacking (sniff, sequence prediction, IP spoofing, RST injection)
Differentiate SIDJACKING from XSS-based cookie theft
Know prevention techniques: HTTPS, Secure/HttpOnly/SameSite flags, session regeneration after login
Frequently Asked Questions
What is session hijacking? An attacker takes over an active user's session by stealing or predicting the session token, allowing unauthorized access without needing credentials.
How do you prevent session hijacking? Use HTTPS for all sessions, set Secure and HttpOnly flags on cookies, regenerate session IDs after authentication, implement SameSite cookie attribute, and use multi-factor authentication.
Session Hijacking is a core domain of the Certified Ethical Hacker v13 (CEH v13) exam administered by EC-Council. It covers taking over an authenticated user's session without credentials — stealing the session token in transit (SIDJACKING), predicting TCP sequence numbers to inject packets into an active connection, or exploiting web vulnerabilities like XSS to exfiltrate cookies. The attacker acts as the legitimate user and every action appears authorized, a direct threat to the Integrity pillar of the CIA triad. Module 11 accounts for approximately 10% of CEH v13 exam questions.
Key Concepts in Session Hijacking
TCP Sequence Number Prediction: the foundation of classic TCP session hijacking. TCP uses sequence (SEQ) and acknowledgment (ACK) numbers to track packet ordering; an attacker who observes enough traffic to learn the increment pattern can predict the next value and craft packets with correct SEQ/ACK from a spoofed source IP, which the target accepts as legitimate. Modern OSes use random initial sequence numbers and entropy-based increments, making pure TCP hijacking extremely difficult — but it remains heavily tested.
SIDJACKING vs XSS-Based Cookie Theft: two distinct methods of stealing session identifiers. SIDJACKING: the attacker sits in-line (same LAN or via ARP spoofing) and captures unencrypted HTTP cookies with a sniffer (Wireshark, Firesheep for WiFi) — requires unencrypted HTTP. XSS-based: injected JavaScript reads document.cookie and exfiltrates it to an attacker server; works even over HTTPS because the script runs in the victim's browser context. Key distinction: SIDJACKING = network-level interception; XSS-based = application-level exploitation.
Session Fixation & Token Binding: fixation means planting or controlling the session ID before authentication — URL parameter injection (?JSESSIONID=attacker_token), Set-Cookie manipulation via proxy, or direct cookie planting. The fix is token regeneration on login: a new random session ID after credential verification invalidates any fixed token. Token binding (newer standard) cryptographically binds the session token to specific TLS connection properties so stolen tokens cannot be replayed from another connection. Less common in practice but frequently tested — it probes when session IDs should change.
Defense in Depth for Session Security: layered protections: (1) HTTPS everywhere (prevents SIDJACKING), (2) HttpOnly flag (blocks JavaScript cookie reads — stops XSS cookie theft), (3) Secure flag (cookie only sent over HTTPS), (4) SameSite attribute (prevents cross-origin cookie sending — mitigates CSRF-driven attacks), (5) session timeout and IP binding, (6) MFA for sensitive actions (extra verification even if the session is hijacked), (7) anomaly detection (geographic impossibility, rapid location changes). No single control is sufficient — defense requires multiple layers.
Common Exam Mistakes in Module 11
Confusing passive with active hijacking: passive work only observes and records traffic — capturing session IDs without disturbing the conversation. Active hijacking takes over a live session: desynchronize it (RST or null data), then inject spoofed packets while racing to predict the sequence number before the target answers. Any stem asking which mode needs sequence prediction wants active.
Treating session fixation like cookie theft: in fixation the attacker plants a known session ID (via a link or cookie) before login and wins when the app fails to regenerate the ID at authentication; sniffing steals an ID already in transit. Fixes differ — rotate the session ID after login for fixation; Secure + HttpOnly cookies over HTTPS for sniffing.
Answering client-side TLS questions with network fixes: CRIME and FREAK do not live at the firewall. CRIME infers secrets from TLS/HTTP compression-ratio differences, so the fix is disabling TLS compression; FREAK forces a downgrade to weak export-grade RSA (Forbidden reuses the handshake nonce). A rate-limit or routing answer applies to neither.
Tools Used in Session Hijacking
Session-theft and testing tools the CEH exam references for this domain, by job:
Firesheep: browser extension that lifts unencrypted session cookies from HTTPS sites by parsing HTTP Referer headers and Set-Cookie responses; the standing example of client-side session theft on shared networks
Ettercap: MITM framework covering ARP poisoning, TCP stream editing and session hijacking — filters rewrite live HTTP responses in real time to inject session-fixation payloads
hping3: low-level packet generator for crafting spoofed TCP segments, including the well-formed RST packets used to desynchronize a victim before takeover
tcpflow: reassembles captured packets into per-connection streams, making recorded session data readable
Wireshark: packet-level view of TCP sequence and ACK numbers — the raw material for predicting sequence values in active hijacking
Burp Suite: proxy for testing application-level session handling — inspect Set-Cookie flags (Secure, HttpOnly, SameSite) and replay a fixed session ID across login to check that the app regenerates it
Worked Example: From Sniffed Cookie to Fixed Session
On shared WiFi, tcpflow rebuilds a web session from captured packets: the Set-Cookie response carries no Secure flag and the session ID rides in an HTTP Referer header — textbook Firesheep conditions. The attacker copies the identifier and replays authenticated requests; the server accepts them because authentication happened once, at session start.
The twist: once cookie flags are fixed, the next test changes shape. The tester links a victim to a page that sets a known session ID; the victim logs in through it; and because the app kept the pre-authentication ID instead of rotating one, the tester now views an authenticated session. Flags protect the token in transit; regeneration on login makes a planted ID worthless — the exam pairs those two defenses with their attacks.
How to Study Session Hijacking for the CEH v13 Exam
To study Module 11:
Memorize the 4-step TCP hijacking process: (1) sniff traffic to capture SEQ/ACK values, (2) predict the next sequence numbers from the observed increment pattern, (3) send a spoofed-source RST to kill the victim's connection, (4) inject packets with correct SEQ/ACK — expect order-of-steps questions
Create a comparison table: Attack Method | Required Position | Works Over HTTPS? | Primary Tool — the exam asks which attack works under which conditions
Hands-on: in a VirtualBox lab with two VMs (attacker + target), ARP-poison with Ettercap, then use its filtering module to modify an HTTP response and inject a cookie. Observe the modified packet in Wireshark — one exercise demonstrating both SIDJACKING and session fixation
Frequently Asked Questions About Session Hijacking
Can session hijacking work over HTTPS?
Pure SIDJACKING (network-level cookie capture) cannot work over HTTPS — the cookie is encrypted in transit and an on-path attacker sees only TLS data. XSS-based hijacking CAN work over HTTPS, because the malicious JavaScript runs in the victim's browser context with full access to application data, regardless of transport encryption. The HttpOnly flag blocks that vector: document.cookie returns empty for HttpOnly cookies. HTTPS stops network-level interception but not application-level attacks — which is why HttpOnly is a critical complement; HTTPS + HttpOnly + SameSite together cover all common hijacking vectors.
What is the role of the SameSite cookie attribute in preventing session attacks?
The SameSite attribute (introduced in response to CSRF concerns) controls when cookies are sent with cross-origin requests. SameSite=Strict: only for same-site requests (never cross-origin). SameSite=Lax (browser default since 2020): not sent on cross-site POST/PUT/DELETE, but sent on cross-site GET for top-level navigations. SameSite=None: requires the Secure flag; always sent. SameSite doesn't directly prevent session hijacking (the attacker already has a valid token) — it prevents the related CSRF class, where an attacker's page makes requests against the victim's authenticated session. With Strict, a cross-site page can't trigger authenticated actions because the browser omits the cookie from cross-origin requests. Expect value-to-protection matching questions.
Related CEH v13 Modules
Module 14: Hacking Web Applications — XSS (reflected, stored, DOM-based) is the primary web vulnerability enabling session hijacking over HTTPS and the vector for cookie exfiltration
Module 8: Sniffing & Traffic Analysis — SIDJACKING rides on the sniffing techniques (ARP poisoning, MAC flooding, port mirroring) that expose session cookies in transit over unencrypted connections