EC-Council LPT Master common mistakes
EC-Council LPT Master · Understand the traps and how to avoid them.
Reporting findings without a reproducible methodology: the report says 'SQL injection found on the login page' but gives no request, payload, timestamp, or evidence chain, so a reviewer cannot retrace how the conclusion was reached.
Candidates treat the report as a summary of results rather than a record of a repeatable process. Under time pressure they jump from discovery to write-up and skip capturing the raw request/response, tool output, and sequence of steps that produced the finding.
What to do instead
Adopt a fixed engagement template: scope, methodology phase (recon, scanning, exploitation, post-exploitation), and for every finding a numbered reproduction recipe with the exact HTTP request, the payload used, the observed response, and a timestamped screenshot or log excerpt. Draft the finding record at the moment of discovery, not at report time.
Confusing a reflected payload echo with confirmed XSS: the candidate reports cross-site scripting because the string appears in the HTML response, without checking whether it executes in a browser context or whether output encoding neutralises it.
Grep-style confirmation is fast and feels conclusive. Candidates do not distinguish between HTML-encoded reflection, attribute-context reflection, and genuine script execution, and they skip verification in an actual browser or DOM environment.
What to do instead
Confirm execution, not reflection. Identify the output context (HTML body, attribute, JavaScript string, URL), craft a context-appropriate payload, and verify it fires in a browser or headless browser with a callback or alert substitute. Report the context and the exact execution evidence; downgrade to 'potential' if execution is unproven.
Treating local file inclusion as file read only: the candidate proves /etc/passwd can be read and stops, never testing whether log poisoning, session file inclusion, or php://filter wrappers turn the inclusion into code execution.
Reading a sensitive file feels like a complete finding, and turning LFI into RCE requires extra steps (poisoning an access log, locating a writable session path) that candidates avoid because of uncertainty or time.
What to do instead
For every LFI, run a structured escalation checklist: test php://filter and data:// wrappers, attempt log poisoning via the User-Agent field, check session file paths, and test whether the included content executes. Report the base finding plus the escalation outcome and its impact, or explicitly state that escalation was attempted and failed.
Testing RFI without confirming the remote-include capability: the candidate assumes a parameter is remotely includable because LFI works, and reports RFI without demonstrating that an external URL is fetched and its content executed.
LFI and RFI are often taught together, so candidates conflate them. allow_url_include is frequently disabled, and candidates do not verify the configuration or observe an outbound request from the target.
What to do instead
Verify RFI independently: host a controlled payload on an attacker-owned listener, pass its full URL to the parameter, and confirm both the inbound fetch in your listener logs and code execution on the target. If allow_url_include is off, report LFI only and note the configuration that blocks RFI.
Writing a report that is technically dense but has no management layer: no executive summary, no risk ratings tied to business impact, no remediation priorities, just a raw vulnerability list.
Candidates optimise for demonstrating technical skill and underestimate the management audience. They also lack a consistent severity framework, so findings are listed in discovery order rather than by business risk.
What to do instead
Structure the report in two halves: an executive summary with overall risk posture, top three business-impacting findings, and a prioritised remediation roadmap; then a technical section with evidence per finding. Assign severity using a stated framework (for example CVSS plus business context) and map each finding to the asset and data it exposes.
Skipping the exploitation and post-exploitation phases after identifying a vulnerability: the candidate lists the missing patch or the injection point but never obtains a shell, proves access, or documents what an attacker could reach.
Fear of causing damage, unfamiliarity with writing or adapting exploit code, and time pressure push candidates toward scanner output. They mistake vulnerability identification for penetration testing.
What to do instead
For each high-severity finding, carry the attack to a defensible proof: obtain a session or demonstrate data access in a controlled way, capture the evidence, then clean up. Where writing a custom exploit is required, adapt a public proof-of-concept to the target version, document the modification, and record the before/after state.
Attempting privilege escalation with a blind spray of exploits rather than enumerating the host first: running several kernel exploits without checking patch level, architecture, or whether the exploit matches the target build.
Candidates memorise exploit names but not the matching conditions. A failed exploit that crashes the host is worse than no attempt, and blind spraying produces noise and instability instead of a reliable path.
What to do instead
Enumerate before exploiting: OS version and patch level, kernel build, SUID/SGID binaries, sudo rights, cron jobs, writable service paths, capabilities, and scheduled tasks. Match each candidate escalation to the exact version and configuration, test the least disruptive path first, and record the enumeration output as evidence.
Treating Windows and Linux privilege escalation as the same skill: applying Linux enumeration habits (SUID, cron) to a Windows host without checking service permissions, unquoted service paths, token privileges, or scheduled task ACLs.
Candidates prepare deeply on one platform and assume the other behaves analogously. Windows escalation depends on ACLs, service configuration, and token privileges, which have no direct Linux equivalent.
What to do instead
Maintain separate checklists. On Windows: whoami /priv, service binary and directory ACLs, unquoted service paths, AlwaysInstallElevated, scheduled task permissions, stored credentials, and token impersonation opportunities. On Linux: SUID/SGID, sudo -l, cron and timers, writable PATH entries, capabilities, and kernel version. State which platform checklist you ran in the report.
Staying on the obvious path and never testing lateral or out-of-the-box routes: the candidate compromises one host and stops, or tests only the primary web application and ignores trust relationships, alternate entry points, and chained weaknesses.
Linear thinking under exam pressure. Candidates follow the checklist they rehearsed and do not ask what else the compromised host can reach, what credentials it holds, or how a low-severity finding combines with another into a high-impact chain.
What to do instead
After each foothold, ask three questions: what credentials or tokens are on this host, what other hosts trust this one, and what low-severity issues can be chained. Document the chain explicitly (for example information disclosure leading to credential reuse leading to lateral movement) and show the combined impact rather than listing each finding in isolation.
Mismanaging the proctored online environment: starting late, failing the environment check, losing connectivity mid-exam, or leaving the camera view without realising it invalidates the session.
Candidates prepare for the technical content and ignore the logistics of a remotely proctored exam. They do not test their camera, microphone, bandwidth, or workspace against the proctoring rules in advance, and they do not read the identity-verification requirements.
What to do instead
Run a full dry run at least a day before: test the proctoring client, camera, microphone, and network, confirm a compliant private workspace, prepare accepted identification, and arrive early. Read the proctoring rules on permitted materials and behaviour, and keep the session uninterrupted so the certification result remains valid and defensible.