CEH common mistakes
CEH · Understand the traps and how to avoid them.
Classifying a hacker in a scenario stem by the attacker's intent or by the tools used instead of by authorization - e.g., labelling an uninvited political defacement as 'white hat' because it exposed a flaw, or labelling a contractually hired tester as 'grey hat' because the work was intrusive.
Candidates memorise the colour labels as personality traits and never anchor them to the presence or absence of written permission and scope. The stem usually hides the deciding fact in one clause (contract, scope document, no authorization), and the tool vocabulary (Nmap, Metasploit) is identical across all categories, so it feels like a distractor.
What to do instead
Build a two-axis table: authorization (yes/no) crossed with intent (good/malicious). White hat = authorized + ethical; black hat = unauthorized + malicious; grey hat = unauthorized but non-malicious. Then separately memorise the actor labels (script kiddie = low skill/tool reuse; hacktivist = ideology; state-sponsored/APT = long dwell time, high resources; suicide hacker = no intent to escape). For any scenario, write down 'authorized? yes/no' before reading the answer choices.
Answering 'which phase / which technique' questions by keyword association - calling a ping sweep or Nmap port scan 'footprinting', calling a Google dork or whois lookup 'scanning', or picking traceroute when the question specifies a passive technique.
Footprinting and scanning are taught back-to-back with overlapping tools (DNS utilities appear in both), so the tool name triggers the wrong phase. Candidates also equate 'passive' with 'not using a tool' rather than with 'no packets reach the target's own infrastructure'.
What to do instead
Apply a single test before choosing: does this activity cause the target's own systems to log a query or receive a packet? If no - search engines, Google dorks, whois, archive.org, job postings, social media, public DNS records - it is footprinting/passive. If yes - ping sweeps, port scans, banner grabbing, zone transfer requests against the target's name server, SNMP walks - it is active reconnaissance/scanning. Drill with a shuffled list of 30 techniques you classify from scratch each time.
Reading scan and vulnerability-scanner output literally and interchangeably - marking a 'filtered' port as closed, treating a Nessus/OpenVAS CVE hit as proof the host is compromised, or scoring CVSS 7.5 as 'medium' and 5.3 as 'high'.
Candidates practise running the tools but not interpreting the results, and the exam tests the interpretation layer. Port-state semantics (open / closed / filtered / unfiltered) and the FIN/NULL/XMAS response matrix differ between Unix-like and Windows targets, and scanner findings are only potential vulnerabilities requiring validation.
What to do instead
Memorise two compact matrices: (1) TCP flag scans - a FIN/NULL/XMAS scan gets RST from closed ports on Unix-like systems, but Windows sends RST regardless of state, which is why those scans are unreliable against Windows; (2) CVSS v3 severity bands - 0.0 none, 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical. State the rule out loud for each practice item: a vulnerability assessment enumerates and ranks findings without exploiting; a penetration test validates by exploiting under authorization.
Muddling the password-attack taxonomy and the Windows credential formats - calling pass-the-hash a cracking technique, calling password spraying a brute-force variant that triggers lockout, or saying a rainbow table defeats salted hashes.
Every option in these items sounds like 'guessing passwords', and the distinguishing facts (offline vs online, precomputed vs computed live, whether a lockout counter is involved, whether the plaintext is ever recovered) sit in one short clause of the stem.
What to do instead
Make an attack→precondition table: dictionary = wordlist, offline or online, no lockout offline; rule-based/hybrid = wordlist plus mutations; brute force = keyspace exhaustion, slow; rainbow table = precomputed hash chains, defeated by salting; credential stuffing = reused credentials across sites; password spraying = a few common passwords across many accounts to stay under lockout thresholds. For Windows, remember LM is disabled by default on modern systems, the SAM holds local hashes, NTLM/NTLMv2 are challenge-response, and pass-the-hash reuses the hash itself - no cracking step exists.
Confusing malware sub-types that the exam separates deliberately - treating polymorphic and metamorphic as synonyms, calling a rootkit a backdoor, or describing a worm as needing a host file or user execution.
The categories overlap in real-world samples, so candidates reason from malware they have read about rather than from the textbook definition. The differentiator is usually one property: self-replication, mutation mechanism, or stealth mechanism.
What to do instead
Learn each type by its single defining property: worm = self-propagating over networks, no host file, no user action; trojan = disguised as legitimate, does not self-replicate; backdoor/RAT = remote access path; rootkit = kernel/user-mode stealth and persistence; polymorphic = encrypted body with a mutated decryption routine each infection; metamorphic = rewrites its own entire code body, no decryptor; armored = anti-debugging/anti-VM; stealth = intercepts AV/OS queries; multipartite = infects boot sector and files; retrovirus = targets antivirus. Also separate dropper (delivery) from payload (action) from exploit kit (delivery platform).
Pairing a sniffing attack with the wrong countermeasure, or picking the wrong social-engineering label - e.g., answering 'port security' for ARP spoofing, 'DHCP snooping' for MAC flooding, or calling a voice-phone pretext 'phishing' instead of 'vishing'.
The countermeasures are all switch features with similar-sounding names, and candidates match on 'switch security' rather than on what the attack actually poisons (CAM table, ARP cache, DHCP pool, DNS answers). Social-engineering labels are tested purely as vocabulary.
What to do instead
Lock in four attack→control pairs: MAC flooding → port security / MAC limiting; ARP spoofing → dynamic ARP inspection plus static ARP entries; DHCP starvation → DHCP snooping with port rate limits; DNS spoofing → DNSSEC plus resolving to trusted servers. Memorise the channel-based labels: phishing (email), vishing (voice), smishing (SMS), pharming (DNS/hosts redirect), whaling (executive target), spear phishing (targeted), tailgating/piggybacking (physical), shoulder surfing (observation), dumpster diving (trash).
Misattributing DoS mechanics and IDS/firewall evasion techniques - calling smurf a UDP attack, calling teardrop a bandwidth flood, naming fragmentation as an IDS detection strength, or placing an IPS out-of-band.
These attacks are historical and rarely encountered hands-on, so candidates memorise names without the packet-level mechanism. Evasion techniques are tested as labels, and the IDS-vs-IPS distinction is assumed rather than reviewed.
What to do instead
Attach each name to one packet fact: SYN flood = half-open connections exhausting the backlog; smurf = ICMP echo to a broadcast address with a spoofed source (ICMP amplifier); fraggle = the same idea over UDP (chargen/echo ports 7 and 19); teardrop = overlapping fragment offsets; ping of death = oversized ICMP packet; reflected/amplified DDoS = third-party responders. For evasion, learn the mechanism not the word: fragmentation and overlapping fragments, session splicing, polymorphic shellcode, encoding/obfuscation, tunnelling through allowed protocols, source-port and TTL manipulation. Fix placement in one line: IDS is passive/out-of-band and alerts; IPS is inline and blocks.
Choosing the wrong SQL injection variant for a described condition - answering 'time-based blind' when the stem says error messages are displayed, or 'UNION-based' when the application returns only a true/false difference - and conflating SQLi with XSS or CSRF.
All injection answers look plausible until you check what the application gives back. Candidates also group every web input flaw under 'injection' without checking whether the payload executes in the database, in the victim's browser, or as an authenticated cross-site request.
What to do instead
Use a decision tree keyed to observable feedback: database errors echoed → error-based; query output reflected in the page → UNION-based (match column count/types); only a difference between true and false pages → boolean-based blind; only a response-time change → time-based blind; input echoed unescaped into HTML → XSS; state-changing request forged from another site using the victim's session → CSRF; object reference changed in a URL → IDOR. For web server items, keep directory traversal, unicode/encoding bypass, and SSI injection distinct from SQL injection.
Mixing wireless attack names and the layer they exploit, and applying IT answers to OT - saying WPA2-PSK is broken by capturing IVs (that is WEP), calling an attacker's look-alike SSID a 'rogue AP' when the stem describes an evil twin, or answering a Modbus/SCADA question with 'patch the PLC and enforce TLS'.
The wireless acronyms and handshake steps blur together, and OT/IoT content is the least-practised material on the exam, so candidates fall back on enterprise IT instincts that are actively wrong in OT environments.
What to do instead
Anchor each attack to its primitive: WEP → IV collection with RC4 weaknesses (FMS/PTW); WPS → PIN brute force (Pixie Dust); WPA2-PSK → capture the 4-way handshake via deauthentication and crack offline, or capture the PMKID; evil twin = attacker's AP impersonating a legitimate SSID to lure clients; rogue AP = unauthorized AP on the corporate network; karma = AP answers any probe request. For mobile/IoT/OT: Android rooting and ADB/backup exposure, OWASP IoT Top 10 defaults, and for OT remember Modbus/TCP port 502 has no authentication, the Purdue model separates levels, availability and safety outrank confidentiality, and active scanning can crash legacy devices.
Applying an on-premises mental model to cloud questions and picking 'encryption' as the answer to every cryptographic scenario - e.g., saying hashing provides confidentiality, calling a digital certificate a digital signature, or assigning OS patching to the provider in IaaS.
Shared-responsibility boundaries move with the service model, and the cryptographic primitives are taught together with one-line definitions that candidates never map back to the security goal (confidentiality vs integrity vs authenticity vs non-repudiation).
What to do instead
Memorise one mapping line and apply it mechanically: symmetric (AES, 3DES) = bulk confidentiality, fast, key distribution problem; asymmetric (RSA, ECC, Diffie-Hellman) = key exchange and signatures, slow; hash (SHA-2/SHA-3) = integrity only, no confidentiality, no key; digital signature = hash + sender's private key, giving integrity, authentication and non-repudiation but not confidentiality; digital certificate = a CA-signed binding of identity to a public key, used to establish trust. For cloud, state the boundary the same way every time: IaaS = customer owns OS and above; PaaS = customer owns application and data; SaaS = provider owns almost everything; customer always owns data, identities and access decisions.