Certified Ethical Hacker guideStudy & preparation
CEH Sniffing vs Session Hijacking: Read the Scenario Clues
Separate traffic observation from session takeover, match HTTPS, cookie flags, and session-ID renewal to their purpose, and practice with original scenarios.
Short answer
Sniffing observes network traffic; session hijacking takes over a session. EC-Council's CEH Exam Blueprint v5.0, checked November 3, 2026, lists them as separate six-question subdomains within Network and Perimeter Hacking. In a web-session scenario, distinguish capturing traffic, reading a session identifier, and successfully using that identifier as another user; those are different outcomes.
Is sniffing the same as session hijacking?
Sniffing observes network traffic; session hijacking takes over a session. EC-Council's CEH Exam Blueprint v5.0, checked November 3, 2026, assigns six questions each to Sniffing and Session Hijacking within Network and Perimeter Hacking. Treat them as related concepts with different outcomes.
NIST's testing guide explains traffic observation and its limits. A capture depends on what traffic is visible from the observation point, and encryption limits what the observer can read. Capturing traffic alone does not establish that its contents were exposed or that anyone took over a session.
For the web-session examples below, OWASP's session guidance supplies the distinctions between protecting a cookie in transit, restricting script access, and replacing an identifier after authentication. These examples illustrate the concepts; they are original study cases, not actual exam questions or a claim that all session hijacking involves web cookies.
Use the CEH exam blueprint guide to place these topics in the full exam. Here, practice identifying what a scenario actually proves.
Which clue tells you what the attacker has achieved?
Underline the action and then the result. The presence of a packet capture or a cookie is only a clue; the result determines which distinction matters.
| What the scenario explicitly says | What you can conclude | What you should not assume |
|---|---|---|
| Traffic was captured, but its encrypted contents were unreadable | Traffic observation occurred | A password or session identifier was recovered |
| An unprotected session identifier was readable in captured traffic | Sensitive session information was exposed | The identifier was accepted or used to take over the session |
| Another party used the identifier and the service accepted requests as the victim | The web session was hijacked | Sniffing was necessarily how the identifier was obtained |
| An attacker chose an identifier before the victim authenticated, and it remained valid afterward | The scenario describes session fixation | Setting a cookie flag alone fixes the identifier's continued validity |
A useful reasoning sequence is observe, expose, use. This is a study aid, not a mandatory attack sequence: a question might establish only one of these outcomes. Do not fill in missing steps merely because you recognize a tool or term.
For broader question practice, full CEH prep planned for launch includes 1,800 questions across nine domains. For each practice answer, write the one phrase in the scenario that supports your choice.
Why do HTTPS and Secure cookies matter?
HTTPS protects traffic in transit, while the Secure cookie attribute tells the browser to send that cookie only over HTTPS. OWASP describes Secure as a restriction on cookie transmission. It does not mean that the cookie can never be obtained or misused through another weakness.
Keep two questions separate:
- Could the observer read the protected content? Encryption matters when the scenario concerns readable data in captured traffic.
- Could the browser send this cookie over an unencrypted connection? The Secure attribute directly addresses how the browser transmits the cookie.
For example, suppose an authorized lab observer captures encrypted traffic but cannot read its session information. The correct explanation is that traffic was observed while its protected contents remained unreadable in the stated case. Calling that a successful hijack adds an outcome the scenario does not provide.
Now suppose the case explicitly says a session cookie was sent over an unencrypted connection. Secure is the cookie attribute relevant to restricting that transmission. HttpOnly answers a different question, about script access.
After reviewing the distinction, try the 20 free CEH practice questions. Use each explanation to practice matching a control to the specific failure described, without assuming that every question will cover this topic.
What do HttpOnly and session-ID renewal protect against?
HttpOnly restricts scripts from reading a cookie through the browser's document interface. It does not prevent every consequence of cross-site scripting, and it does not stop the browser from sending the cookie with requests. A statement that HttpOnly makes every session attack impossible is too broad.
Session-ID renewal addresses a different problem. OWASP calls for a new identifier after authentication or another privilege change, with the old identifier invalidated. That matters for session fixation, where an attacker sets an identifier before the victim's session gains privilege.
Consider a fictional training site that retains an attacker-chosen identifier after the victim signs in. The weakness is the continued validity of that identifier across authentication. Regenerating the identifier and invalidating the old one addresses that mechanism; making the old identifier harder for a script to read does not remove its validity.
For recall practice, full CEH prep planned for launch includes 500 flashcards alongside its question bank. Your own short prompts can be: “Secure restricts transmission,” “HttpOnly restricts script access,” and “renewal replaces the identifier.” Add the limitation to each answer so a familiar control does not become a universal solution in your notes.
How do you answer these original CEH-style scenarios?
These fictional cases deliberately state the decisive fact. Answer each with the concept, the supporting clue, and one conclusion the evidence does not justify.
Case 1: Captured but unreadable. During an authorized assessment, an observer captures traffic. The scenario explicitly says encryption prevents the observer from reading its session identifier. What has been demonstrated?
Answer: Sniffing or traffic observation. The capture is the clue. Neither identifier exposure nor session takeover has been established.
Case 2: Readable but unused. A capture exposes an unprotected session identifier. The case gives no evidence that anyone submitted it or that a service accepted it. Has successful session hijacking been demonstrated?
Answer: No. Exposure has been demonstrated. A takeover conclusion requires evidence of using the session, which is missing here.
Case 3: Accepted as the victim. The case states that another party used the victim's session identifier and the service accepted the requests as the victim. The method used to obtain the identifier is unspecified.
Answer: Session hijacking. The decisive clue is accepted use of the victim's session. Do not add sniffing as the acquisition method without evidence.
Case 4: Same identifier after login. An attacker selects a session identifier before the victim authenticates. The site continues accepting that identifier after login. Which change directly addresses the fixation mechanism?
Answer: Renew the session identifier after authentication and invalidate the old one. HTTPS and cookie flags have their own purposes, but they do not replace this change in identifier validity.
If you confused observation with discovering services or collecting names, review footprinting, scanning, and enumeration. Keep your answer tied to the activity and result the question supplies.
What should you review next?
Make a brief review sheet with four entries: sniffing, session hijacking, session fixation, and the three controls discussed above. For each, write its purpose and a limitation from this guide. Then revisit the cases without looking at the answers and explain why a nearby alternative does not fit.
Use the free CEH study plan to schedule another review, and the practice-test readiness guide to move from isolated concepts into broader practice. If you are still arranging the exam, the CEH cost and eligibility guide covers that separate decision.
When you want a broader rehearsal, full CEH prep planned for launch includes a 125-question mock exam. Before that rehearsal, aim to explain the difference between seeing traffic, exposing an identifier, and using a session without relying on memorized attack names alone.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.