Pentesting Exams: Scope, Methodology, Evidence, and Time Control
What this domain tests
The Pentesting Exams domain checks whether you can run an authorized penetration test as a repeatable professional engagement: scope discipline, methodology, evidence handling, time control, and reporting under exam conditions. It is not a trivia test; marks come from showing a defensible path from discovery to proof and remediation.
Core rules and concepts
- Scope and rules of engagement are the exam contract. Confirm in-scope hosts, URLs, accounts, time windows, and forbidden actions. A reachable host is not automatically in scope. Destructive payloads, denial-of-service, social engineering, and real-data exfiltration usually violate exam rules.
- Use a methodology loop. Passive reconnaissance, enumeration, vulnerability validation, controlled exploitation, post-exploitation, cleanup, and reporting. PTES and NIST SP 800-115 provide engagement structure; OWASP WSTG is useful for web targets.
- Evidence must be reproducible. Record timestamp, source host, target host/port, account, request/response or command transcript, affected parameter, preconditions, and observed result. Redact secrets but keep enough proof to validate the finding.
- Time-box aggressively. Budget blocks for recon, web, infrastructure, and reporting. If a vector produces no signal after a short checkpoint, park it and move on; return only if new evidence appears.
- Track objectives, not just shells. Exam flags may require specific files, privilege levels, or application actions. Verify the objective rather than assuming access equals completion.
- Minimize impact and clean up. Remove test files, accounts, scheduled tasks, and payloads. Stop and report if you accidentally touch out-of-scope data.
Worked example
A web target exposes /api/v1/users?id=1042. Changing the numeric ID to 1043 returns another user's JSON record. Reasoning: this is a broken object-level authorization (IDOR/BOLA) candidate. Confirm with two low-privilege test accounts, capture the request and redacted response, and show that the server-not the client-fails to enforce ownership. Do not enumerate every user; one controlled proof is enough. Report the endpoint, parameter, required account, data exposed, impact, and a fix such as server-side object ownership checks plus authorization tests.
Traps that cost marks
- Treating a scanner alert as a finding without manual validation.
- Pivoting to an out-of-scope host because it is reachable from a compromised box.
- Losing terminal output by not logging sessions before a shell closes.
- Reporting “SQL injection” without the request, payload, evidence, and affected data.
- Spending the final hour on one stubborn vector instead of banking other objectives and writing the report.