CSPT common mistakes
CSPT · Understand the traps and how to avoid them.
Start scanning a hostname because it is in scope by name, without resolving it first and confirming the resulting IP is inside the in-scope range - and letting the proxy or browser follow redirects/CNAMEs to cloud or third-party hosts.
Scope documents usually list DNS names and URL ranges, while tools operate on IPs and follow referrals automatically; the mismatch is invisible until someone reviews the traffic log.
What to do instead
Before active testing, resolve every in-scope name and record name-to-IP mappings with timestamps. Build explicit allowlists in the intercepting proxy and in each tool's target file, disable automatic redirect-following to out-of-scope hosts, and re-resolve periodically since CDN and cloud IPs change. When a name resolves outside the range, pause and get written confirmation before touching it.
Testing begins before the signed authorisation and RoE are returned, with the tester relying on an email thread saying 'go ahead'.
Scheduling pressure and the assumption that paperwork is a formality; the email often lacks named signatory, dates, or defined targets.
What to do instead
Hold all active traffic until a countersigned authorisation is on file that names the signing authority, the exact in-scope targets, the test window, permitted techniques, and emergency stop contacts. Keep a pre-engagement checklist and treat missing items as a hard stop rather than a note for later.
Hitting the first internal service with a full-port aggressive scan and a dozen exploit attempts on discovery, without agreement on testing intensity or an escalation threshold for critical findings.
Momentum after the first foothold; the tester optimises for findings rather than for the client's tolerance for downtime and disclosure timing.
What to do instead
Agree in advance the escalation contacts, the maximum notification delay for critical findings (for example domain admin compromise or access to regulated data), and the permitted intensity per environment. When a critical finding appears, notify within the agreed window before continuing exploitation, and log the notification time.
Skipping passive reconnaissance and going straight to a port scan of the known IP range, missing leaked credentials in public repositories, certificate-transparency subdomains, and the organisation's cloud and ASN footprint.
Active scanning produces immediate visible output, while passive collection feels like it produces nothing - the missing subdomains and credentials are invisible, so the omission never self-corrects.
What to do instead
Run a fixed passive checklist first: all DNS record types, zone transfer attempts, certificate transparency and subdomain enumeration, ASN and whois, reverse-IP lookups, public code repositories, and document metadata. Record the results as a target inventory before any active scan, and use it to expand and re-verify scope.
Copying scanner output directly into the report as confirmed vulnerabilities, including items that were never manually reproduced or that have no demonstrable security impact.
Output volume and time pressure; scanners flag anything that resembles a signature, and a tester who has not reproduced a finding cannot tell a true positive from a misconfigured page.
What to do instead
Reproduce every candidate manually with a minimal request/response pair or command transcript, record preconditions, and state what an attacker gains. Move unreproduced items to an appendix as false positives or unverified observations rather than to the findings list, and note the scanner rule and why it did not hold.
Setting up a pivot without verifying routing first - starting a scan through a single SOCKS proxy with default timeouts, forgetting routes to the second subnet, and leaving the foothold with only one callback method.
Pivoting is improvised under time pressure; a proxy that works for one host is assumed to work for a whole range, and the fragility of the foothold only becomes apparent after it dies.
What to do instead
Document the pivot chain as you build it. Verify egress through each hop against a known reachable host before scanning, tune proxy timeouts and DNS resolution explicitly, add and confirm routes for every additional subnet, and establish a redundant callback (a second listener or a stable agent) before launching broad scans through the pivot.
Testing the application only as an administrator, or only unauthenticated, and never repeating object requests as a second low-privileged user - so broken object-level authorisation and privilege-boundary issues are never exercised.
One working account is convenient, and authenticated pages return data, which feels like progress; access control failures only appear when the same request is made by someone who should be denied.
What to do instead
Enumerate all roles and capture a session for at least two privilege levels. For every object identifier observed, replay the request from each session, swap identifiers, and compare status codes and response bodies. Record which role could reach which object as a table, and treat every successful cross-role read or write as a finding.
Treating Active Directory as a list of individual attacks - running Kerberoasting, AS-REP roasting and ACL scanners blindly and reporting each as a separate low-severity finding, with no attempt to connect them into a path.
Tooling makes each technique a one-line command, so the engagement drifts into checkbox collection rather than graph analysis of who can reach what.
What to do instead
Collect AD data early and map reachability from the starting principal to tier-zero assets, then validate only the edges on a candidate path. Present the result as a chain showing each hop, the credential or permission obtained, and where a control would have broken it, with individual techniques as supporting detail rather than headline findings.
Reporting a local privilege escalation as confirmed after reading that a binary is listed as exploitable, without executing it end-to-end from a clean low-privileged session and without checking that the current user can actually invoke it.
Reference lists such as GTFOBins are consulted for the binary name only; version, build, group membership, and whether the service runs as the target account are skipped because they slow the flow.
What to do instead
Prove escalation from a fresh low-privileged shell: capture whoami/id and the applicable version or build, show the exact command or misconfiguration, capture the resulting privileged context, and note any required group membership or interactive logon. If any precondition is unverified, downgrade the finding and state the missing condition.
Leaving report writing to the final hours, producing a chronological narrative with findings that lack business impact, reproduction steps, or remediation detail, and with the critical attack chain buried among informational items.
Technical work consumes the whole window and writing is treated as an administrative afterthought; notes taken during testing are too sparse to reconstruct the context afterwards.
What to do instead
Write each finding as it is validated using a fixed template (title, affected assets, preconditions, evidence reference, impact in business terms, likelihood, remediation with a specific configuration change, references). Order by exploitability and impact, lead with an executive summary containing the attack narrative and the top three priorities, and cross-check the findings list against the scope before delivery.
Capturing screenshots and terminal output with no host, user, date or address visible, storing captured credentials and files on the compromised host, and keeping no hash or index of collected evidence.
Capture happens mid-task and the surrounding context is assumed to be memorable; the same session that produced the evidence is also the most convenient place to store it.
What to do instead
Configure shell prompts and terminal logging to include timestamp, user, hostname and working directory, and include the target address in every capture. Name files to a fixed convention, hash any collected file or credential dump at the moment of capture, keep evidence only on the tester's system in a single case folder with an index listing each item and where it came from, and note the handling and destruction of any client data at close-out.