PECB Certified Lead Ethical Hacker common mistakes
PECB Certified Lead Ethical Hacker · Understand the traps and how to avoid them.
Running active enumeration (port scans, service fingerprinting, directory brute force) against lab targets before documenting the signed scope, rules of engagement, and authorization window, then answering scenario questions as if any target were fair game.
Candidates treat the practical lab as a technical puzzle and skip the engagement setup, because reconnaissance tooling is more engaging than paperwork and the exam scenario text is skimmed rather than parsed for in-scope CIDRs, excluded hosts, and time windows.
What to do instead
Before touching any tool, write a one-page engagement brief: authorized targets, exclusions, time window, permitted techniques, escalation contact. Practice by reading a scenario and extracting scope into that brief in under five minutes, then re-check it before each active phase. When a question describes an out-of-scope host, the correct answer is usually to stop and seek written authorization, not to proceed quietly.
Reporting reconnaissance output as raw tool dumps (full Nmap XML, scanner screenshots, unedited whois records) without deduplication, prioritization, or a statement of what each finding means for the client's attack surface.
Candidates equate volume with thoroughness and worry that summarizing loses credit, so they paste everything. They also lack a habit of mapping discovered assets to business context, so they cannot rank findings.
What to do instead
Convert every recon artifact into a finding row: asset, exposure, evidence reference, business impact, recommended action. Keep raw output in an appendix and reference it by ID. Rehearse writing a two-page external footprint summary from a scan set, forcing yourself to name the three assets that matter most and why.
Treating threat modeling as a one-time checklist at project start, producing a list of generic threats (phishing, SQL injection, insider threat) that is never tied to the specific architecture, data flows, or trust boundaries described in the scenario.
Candidates memorize threat catalogues and STRIDE letters but never practice applying them to a described system, so they cannot identify where a trust boundary is crossed or which asset an attacker actually wants.
What to do instead
Practice drawing the data-flow diagram from a written scenario, marking trust boundaries and entry points, then applying STRIDE per element rather than per system. For each threat, record the asset, the path, and a concrete mitigation. If a threat cannot be traced to a specific boundary crossing in your diagram, delete it.
Conflating vulnerability identification with exploitation: marking a finding as confirmed critical because a scanner banner matched a CVE, without validating version accuracy, backported patches, compensating controls, or exploitability in the actual environment.
Scanner output feels authoritative and candidates fear under-reporting, so they skip validation. They also underestimate how often vendor backports leave version strings unchanged, producing false positives.
What to do instead
For each candidate vulnerability, record the evidence type (banner, response behaviour, authenticated check) and a confidence level. Practice distinguishing 'potentially affected' from 'confirmed exploitable' and state the validation step needed. Where a control such as network segmentation or WAF virtual patching exists, explicitly note how it changes exploitability and residual risk.
Launching exploits against a target without first capturing a baseline (reachability, service state, snapshot or backup confirmation) and without a rollback plan, then being unable to distinguish damage caused by the test from pre-existing conditions.
Candidates focus on getting a shell and treat pre-exploitation checks as delay. Exam scenarios often include a stability or availability constraint that is missed on first read.
What to do instead
Adopt a fixed pre-exploitation checklist: confirm target is in scope and reachable, record service state, confirm snapshot or restore point, note the least disruptive exploit variant. Practice choosing a proof-of-concept that demonstrates impact with minimal side effects, and be ready to explain why a read-only proof beats a destructive one.
Choosing an exploit or payload purely by CVE severity or popularity rather than by matching it to the confirmed target version, architecture, available egress, and defences such as ASLR, DEP, or EDR.
Candidates rehearse a small set of well-known exploits and force them onto every scenario, and they do not habitually enumerate mitigations before selecting a technique.
What to do instead
Before selecting a technique, write down target OS and patch level, architecture, memory protections, network egress, and endpoint controls. Then justify the chosen approach against each. Practice explaining why a lower-severity, better-matched technique is the correct answer when the higher-severity one would fail or be detected.
Assuming a successful exploit equals administrative control, and answering privilege escalation questions by naming a tool rather than describing the enumeration of the actual host: kernel and patch level, SUID/SGID binaries, sudo rights, scheduled tasks, service permissions, credentials in files, and group memberships.
Candidates memorize a list of escalation techniques but skip the discovery step, and they generalize across Linux and Windows without checking which platform the scenario describes.
What to do instead
Build a platform-specific enumeration checklist and practice running it mentally against a described host, listing candidate escalation paths in priority order with the evidence that would confirm each. Always state what you would check first and why, and name the specific misconfiguration rather than only the tool.
Pivoting without mapping the internal network first, or setting up a tunnel and then failing to record which hosts and ports were reachable through it, leaving the report unable to show how deep access actually went.
Once a tunnel works, candidates rush to the next target and treat the pivot as plumbing rather than a finding. They also confuse a proxy with a route and misconfigure tooling that ignores proxy settings.
What to do instead
Maintain a pivot log: pivot host, method, local port, remote network, hosts confirmed reachable, timestamp. Test reachability explicitly through the tunnel before running tools. Practice explaining the difference between application-layer proxying and network-layer routing, and note which tools need proxy-aware configuration.
Losing track of where transferred files landed, what was executed, and whether artifacts were cleaned up, or transferring tooling in ways that break integrity or trigger defences (plaintext download over HTTP, missing checksum verification, execution from a monitored directory).
File transfer is treated as a trivial step, so candidates do not plan staging directories, integrity checks, or cleanup, and they do not consider that the transfer method itself is observable.
What to do instead
For every transfer, record source, destination path, method, checksum, and cleanup action. Practice selecting a transfer method that fits the egress constraints and detection risk described in the scenario, and always verify integrity before execution. Include an explicit cleanup and evidence-preservation step in your notes.
Writing the report as a chronological narrative of what the tester did, burying findings in methodology, omitting reproduction steps and evidence references, and giving remediation advice that is generic ('patch systems', 'train staff') rather than specific to the root cause found.
Candidates confuse a diary with a deliverable and run out of time, so they paste notes. They also lack practice translating a technical finding into business risk and a prioritized, owner-assigned action.
What to do instead
Use a fixed report structure: executive summary, scope and approach, findings ranked by risk with evidence IDs, reproduction steps, root-cause-linked remediation with priority, and appendices. Practice writing one finding in the required format in ten minutes: title, risk rating with justification, evidence, impact, reproduction, specific fix. Have the executive summary readable by a non-technical owner without the body.