CAP-PL ENS common mistakes
CAP-PL ENS · Understand the traps and how to avoid them.
Writing a report that lists every finding with equal severity instead of ranking by exploitability and business impact, so the client cannot tell which two issues actually matter.
Candidates treat the report as a raw dump of tool output because the technical testing phase consumed most of the time budget and the write-up is compressed into the final hours.
What to do instead
Before writing, triage all findings into a ranked table (critical/high/medium/low) with exploitability, prerequisites, and business impact in one line each. Dedicate the most report space to the top two or three findings, and demote informational items to an appendix.
Submitting a report with no clear reproduction steps or evidence, e.g. 'SQL injection found on login page' without the exact request, payload, and observed response.
The tester reproduced the issue interactively and assumes the reader can follow the same path, or evidence was captured inconsistently during testing.
What to do instead
Adopt a per-finding template: affected endpoint/parameter, exact request, payload, response snippet or screenshot, and a one-line remediation. Capture evidence at the moment of discovery, not afterwards.
Testing beyond the agreed scope or rules of engagement, such as pivoting into out-of-scope hosts or running destructive payloads, because they were reachable.
Candidates chase the most interesting technical path and lose track of the scope document, or assume 'if it responds, it is fair game'.
What to do instead
Keep the scope list and prohibited techniques open throughout the engagement. Before any pivot or intrusive action, check it against scope and get written authorisation for anything ambiguous.
Presenting a finding with no remediation guidance, or with generic advice like 'patch the system' that the client cannot action.
Candidates focus on proving the vulnerability and treat remediation as an afterthought outside their skill set.
What to do instead
For each finding, give a specific fix (config change, code pattern, version to upgrade to) plus a compensating control if immediate remediation is not possible. Reference the relevant standard or CWE where it strengthens the advice.
Skipping reconnaissance and enumeration and jumping straight to launching exploits against the first host found.
Candidates equate pentesting with exploitation and want quick wins, or they are nervous about time and rush the discovery phase.
What to do instead
Budget explicit time for passive and active enumeration, build an asset and service inventory, and only then select exploits. Treat enumeration as a deliverable in its own right.
Running automated scanners and reporting their output verbatim as confirmed vulnerabilities, including false positives.
Scanner output looks authoritative and saves time, and candidates lack confidence to manually validate each result.
What to do instead
Manually verify every reported issue before it enters the report. Reproduce it by hand, note the scanner as a lead rather than evidence, and discard anything you cannot independently confirm.
Failing to manage the engagement clock, spending the whole window on one interesting host and leaving no time for reporting or the remaining scope.
Deep-diving one target is engaging and candidates underestimate how long documentation takes.
What to do instead
Split the engagement into timed phases (recon, exploitation, post-exploitation, reporting) with checkpoints. Reserve at least the final quarter for the report and stop testing when that phase begins.
Losing track of credentials, shells, and session state, then being unable to reproduce a finding or re-enter a host during report writing.
Candidates work ad hoc across terminals and notes without a consistent log.
What to do instead
Maintain a running engagement log from minute one: timestamps, commands, credentials, hosts, and outcomes. Use a structured notes file or tool so any action can be reconstructed later.
Treating privilege escalation as the finish line and not documenting the path, preconditions, and impact of the escalation chain.
Getting root or domain admin feels like success, so the candidate stops and moves on without recording how it was achieved.
What to do instead
After any escalation, immediately record the exact steps, the misconfiguration exploited, and what access it grants. Frame it as an attack path with preconditions so the client can prioritise the fix.
Ignoring the human and process side of the assessment, such as reviewing password policy, MFA coverage, patching cadence, and logging, and reporting only technical bugs.
Candidates equate pentesting with tool-driven exploitation and overlook that many findings are configuration and governance weaknesses.
What to do instead
Include a short posture review alongside technical findings: authentication controls, patch levels, segmentation, and detection capability. Tie each technical finding back to the process gap that allowed it.