CREST CPSA common mistakes
CREST CPSA · Understand the traps and how to avoid them.
Treating the scoping document as a formality and beginning testing without confirming the authorised target ranges, time windows, and out-of-scope hosts in writing.
Candidates are eager to start hands-on work and assume the engagement letter covers everything; the assessment-management questions test whether scope discipline is understood as a technical control, not paperwork.
What to do instead
Before any testing, restate the in-scope IPs/domains, excluded hosts, allowed techniques (e.g., no DoS, no social engineering), and test windows back to the client and get written confirmation; record this in the report methodology section.
Reporting a finding as 'critical' purely from a scanner severity label without validating exploitability or business impact.
Tool output is easy to copy and candidates conflate CVSS base score with risk; assessment-management questions reward contextual risk rating tied to asset criticality and exploit preconditions.
What to do instead
For each finding, state the evidence of exploitability, the affected asset's role, and a justified rating; downgrade or upgrade from the scanner label with an explicit rationale.
Confusing TCP and UDP behaviour when interpreting scan results, e.g., treating an unanswered UDP probe as a closed port or assuming a filtered TCP port means the host is down.
Candidates memorise port numbers but not the handshake semantics (SYN/ACK/RST, ICMP unreachable types) that determine what a 'no response' actually means.
What to do instead
Learn the decision tree: TCP open = SYN/ACK, closed = RST, filtered = no reply or ICMP admin-prohibited; UDP open = reply or no reply, closed = ICMP port unreachable. Apply it when writing up scan evidence.
Describing a service banner or version string as a confirmed vulnerability without checking whether the version is actually affected.
Banner grabbing feels like a result, and candidates equate 'Apache 2.4.x' with 'vulnerable' without correlating to advisories or patch levels.
What to do instead
Treat banners as fingerprinting only; cross-reference the exact version against vendor advisories and, where safe, confirm with a non-destructive check before reporting.
Failing to distinguish publicly available information gathering (passive OSINT) from active probing of third-party infrastructure, and querying services that log the client's IP against out-of-scope hosts.
Candidates blur the line between 'search engines and public records' and 'touching the target', which creates legal and scope problems the exam explicitly tests.
What to do instead
Classify each technique as passive or active before use; keep active enumeration within the authorised ranges and prefer cached/public sources (search engines, certificate transparency, WHOIS) for anything outside them.
Assuming a switch or router is secure because it is 'internal', and not checking for default credentials, exposed management interfaces, or unencrypted management protocols (Telnet, SNMPv1/v2c, HTTP).
Candidates focus on servers and skip network infrastructure, yet infrastructure questions test knowledge of management-plane weaknesses and default configurations.
What to do instead
Enumerate management services on network devices, test documented default credentials only within scope, and report plaintext management protocols and default community strings as findings with remediation (SSH, SNMPv3, HTTPS, ACLs).
Reading only the GUI security settings and concluding a Windows host is hardened, without checking effective policy (secedit, local policy vs domain GPO precedence) and actual service/ACL state.
Candidates trust the control panel view; the exam tests understanding that domain GPO overrides local policy and that effective configuration must be measured, not assumed.
What to do instead
Compare local policy with applied GPOs (e.g., gpresult / secedit export), check effective permissions on sensitive paths and services, and report the effective state with evidence.
Missing privilege-escalation primitives on Unix because only world-writable files were checked, ignoring SUID/SGID binaries, sudo rights, cron jobs, and PATH issues.
Candidates run one checklist item and stop; the exam expects systematic enumeration of the classic escalation surfaces and the reasoning behind each.
What to do instead
Enumerate SUID/SGID binaries against known-good lists, review sudo -l output, writable cron/init scripts, and PATH-relative calls in privileged scripts; report each with the escalation path it enables.
Listing web findings (XSS, SQLi, IDOR) without mapping them to the tested parameter, request, and observed response, so the report cannot be reproduced.
Candidates test broadly and record conclusions rather than evidence; web methodology questions reward proof-of-concept discipline and correct classification of the vulnerability class.
What to do instead
For each web finding capture the exact request (method, path, parameter, payload), the response difference, and the impact; state the vulnerability class precisely and the remediation at the code layer.
Confusing authentication bypass, authorisation flaws, and injection when describing a web issue, e.g., labelling a forced-browsing result as 'broken authentication' or missing that a parameter is injectable because only the response body was checked.
Candidates recognise a symptom but not the underlying control that failed; the exam tests precise taxonomy and the ability to distinguish vertical/horizontal privilege issues from injection.
What to do instead
Ask which control failed: identity proof (authentication), permission check (authorisation/IDOR), input handling (injection), or output encoding (XSS); classify accordingly and describe the failed control in the finding.
Treating a database as a black box and reporting 'SQL injection possible' without identifying the DBMS, the injection context (in-band, blind, error-based), or the privileges of the application's database account.
Candidates stop at the first error message; database questions test understanding of DBMS fingerprinting, least-privilege impact, and safe proof-of-concept limits.
What to do instead
Fingerprint the DBMS from error/version behaviour, determine the injection context, and report the application account's privileges (e.g., whether it can read other schemas or write files) as the impact statement, staying within the agreed proof-of-concept boundary.