CPEH common mistakes
CPEH · Understand the traps and how to avoid them.
Starting hands-on exploitation or scanning against a target in a scenario before confirming the engagement has written authorization, a defined scope, and an approved window, then treating the technical result as the answer.
Candidates treat CPEH-style items as pure technical puzzles and jump to the tool or payload, because the authorization facts are usually buried in a paragraph of scenario prose and the exploit path feels like the 'real' question.
What to do instead
Adopt a fixed first pass: for any scenario, extract authorization status, scope boundaries (hosts, domains, IP ranges), time window, and rules of engagement into a short note before evaluating any technique. If authorization or scope is absent or expired, the correct answer is to stop and escalate to the client contact in writing, not to proceed technically.
Confusing passive reconnaissance with active reconnaissance and choosing an active technique (direct DNS queries against the target's authoritative servers, port probes, banner grabs) when the scenario explicitly restricts the engagement to passive-only collection.
Tooling blurs the line: OSINT frameworks and DNS lookups feel passive but generate traffic to or about the target, and candidates default to the tool they know rather than classifying the traffic the technique generates.
What to do instead
Build a two-column mental table. Passive: search engines, certificate transparency logs, public WHOIS/RIR records, job postings, social media, third-party breach data, archived pages. Active: zone transfers, direct queries to target-owned name servers, subdomain brute force, port scans, web crawling of the live site. For each candidate technique ask 'does a packet reach an asset the target owns or controls?' and choose accordingly.
Reporting a scanner's raw output as confirmed vulnerabilities, or conversely dismissing a scanner finding without validating it, instead of distinguishing a suspected finding from a verified one.
Time pressure and tool-centric training encourage treating a high-severity scanner line as ground truth; candidates also lack a habit of recording the exact request/response that proves exploitability.
What to do instead
For every finding, record three things: the detection method, a manual verification step (a crafted request, a version-specific proof, or a configuration read), and the evidence artifact. Classify each as confirmed, probable, or false positive. Only confirmed or probable items go in the findings section with severity; unverified scanner output goes in an appendix or is discarded with a note.
Performing privilege escalation steps on a host without first establishing a stable, low-privilege foothold and documenting the current user, groups, and access level, leading to actions that lock out the account or destroy evidence of the initial access path.
Candidates rush to the 'win' (root/SYSTEM) and skip enumeration, then cannot explain in the report how they got in, which is often what the question is really testing.
What to do instead
Follow a fixed sequence: confirm identity and privileges, enumerate local users, groups, services, scheduled tasks, writable paths, and credential stores, then pick the least disruptive escalation path. Record the pre-escalation state and the exact command or misconfiguration used. Prefer reversible actions and avoid changing passwords or disabling accounts unless the rules of engagement permit it.
Treating a phishing or client-side scenario as a single-step 'send the email' answer, ignoring the delivery infrastructure, pretext credibility, payload delivery method, and the detection/response chain the scenario describes.
Social engineering questions look simple on the surface, so candidates answer the visible step and miss that the scenario is testing the full attack chain or the defensive control that would break it.
What to do instead
Map the chain explicitly: target selection and pretext, delivery channel (email, USB, watering hole, phone), payload or credential capture mechanism, execution trigger, and the control that intercepts each link (mail filtering, attachment sandboxing, MFA, EDR, user reporting). Answer the link the question actually asks about, and be ready to name the corresponding defensive control.
Assuming WPA2-PSK is broken by capturing a handshake alone, or proposing a WEP-style attack against a WPA3 network, without accounting for the offline dictionary step, PMKID capture, or the specific weaknesses that actually apply to each protocol.
Wireless attacks are frequently taught as a single recipe (capture handshake, crack with wordlist), so candidates misattribute the failure point and pick techniques that do not apply to the protocol version in the scenario.
What to do instead
Learn the failure point per protocol. WEP: weak IV reuse, keystream recovery. WPA/WPA2-PSK: four-way handshake or PMKID capture, then offline guessing against the passphrase, so strength of the passphrase is the real control. WPA2-Enterprise: evil twin and credential capture, certificate validation failures. WPA3-SAE: resists offline guessing; focus on downgrade/transition-mode weaknesses and client misconfiguration. State the capture requirement and the cracking step separately.
Reporting a web finding as 'SQL injection' or 'XSS' without specifying the injection context, the parameter, the payload class, and the database or browser behavior that proves impact, or conflating blind, error-based, and time-based variants.
Candidates memorize category names and payload strings but not the diagnostic reasoning that distinguishes variants, and under time pressure they write the category label instead of the evidence.
What to do instead
For each web finding, write a one-line proof template: endpoint and parameter, injection context (string, numeric, header, JSON body), technique variant (error-based, union, boolean-blind, time-based; reflected, stored, DOM), the exact payload shape, and the observed response difference. If you cannot fill in the observed difference, you have a suspicion, not a finding.
Choosing a hashing algorithm for password storage or an encryption mode for data protection based on familiarity (MD5, SHA-1, ECB mode, static IVs) rather than on the security property the scenario requires.
Candidates conflate 'encrypted' with 'secure' and 'hashed' with 'safely stored', and exam scenarios often describe a specific threat (offline cracking, pattern leakage, replay) that rules out the familiar choice.
What to do instead
Anchor each primitive to its property. Password storage: memory-hard or iterated salted KDF (Argon2, scrypt, bcrypt, PBKDF2 with high iterations), never a fast general hash. Confidentiality: authenticated encryption (AES-GCM, ChaCha20-Poly1305) with unique nonces; avoid ECB and static IVs in CBC. Integrity and signatures: SHA-256 or stronger with a proper signature scheme. Then check the scenario's stated threat against that property before answering.
Leaving artifacts during post-exploitation, such as new local accounts, modified service configurations, uploaded tools in common directories, or clear-text credentials in shell history, and then being unable to answer a question about covering tracks or about what a defender would detect.
Candidates optimize for getting the objective and treat cleanup as an afterthought, and they underestimate how much of the exam tests detection awareness and forensic traceability.
What to do instead
Keep an artifact ledger from the first action: accounts created, files written and their paths, registry or service changes, scheduled tasks, and log sources touched. For any persistence mechanism, be able to name the corresponding detection (new account creation events, service install events, task creation, unusual outbound connections). When a question asks about covering tracks, answer in terms of reducing detectable footprint while remaining within the rules of engagement, and note that destroying logs is usually out of scope.
Writing findings with severity assigned by scanner score alone, no reproduction steps, no business impact statement, and no prioritized remediation, so the report is technically accurate but not actionable.
Candidates spend their preparation on exploitation and treat the report as a formality, and they lack a consistent severity rubric, so they default to whatever the tool printed.
What to do instead
Use a fixed finding template: title, affected asset, evidence, reproduction steps, business impact in the client's terms, severity with the rubric named (for example CVSS vector plus environmental context), and a remediation recommendation with a verification test. Order the report by risk to the business, not by tool output. Include a short executive summary that states the overall risk posture and the top three actions.