HTB CPTS common mistakes
HTB CPTS · Understand the traps and how to avoid them.
Starting to attack the first reachable host after a quick port scan, without building a written target map or recording the scope boundary and any excluded hosts/IPs given in the exam brief.
Time pressure and adrenaline push candidates straight into exploitation; the CPTS brief includes scope and flag/target details that are easy to skim, and unstructured starts make it hard to tell later which hosts were already covered.
What to do instead
Before any tooling, spend 10-15 minutes writing a scope sheet: in-scope subnets, excluded hosts, required deliverables, and a numbered host list. Track every host in a table with columns for open ports, services, credentials found, foothold status, and privilege level. Update it after each phase.
Treating enumeration as a one-pass step: running a single default nmap scan and a single gobuster run, then moving to exploitation without full-port TCP scans, UDP spot checks, version detection, or recursive content discovery.
Default scans miss high ports and non-standard services, and candidates underestimate how much of the exam hinges on finding the one unusual service or vhost; they also fear 'wasting' time on enumeration.
What to do instead
Adopt a fixed enumeration checklist per host: full TCP port sweep, service/version scripts, targeted UDP on common ports, then per-service deep enumeration (SMB shares and users, LDAP anonymous bind, SNMP, DNS zone transfer and vhost brute force, web directory and file extension fuzzing). Only declare a host 'done' when the checklist is complete.
Ignoring Active Directory attack paths after obtaining a single low-privilege domain credential, and instead continuing to hunt for standalone service exploits on member servers.
Candidates are more comfortable with single-service exploits than with AD concepts like ACL abuse, delegation, and certificate services, so they avoid the domain-wide tooling that actually solves the exam's AD portion.
What to do instead
Once any domain credential exists, immediately run BloodHound collection and analyze shortest paths to Domain Admin, plus enumerate AD CS, Kerberoastable and AS-REP-roastable accounts, unconstrained and constrained delegation, and writable ACLs. Prioritize the identified path over further host-level exploitation.
Discovering a web vulnerability and immediately firing a public exploit or a reverse shell payload without first confirming the exact application version, framework, and whether the endpoint is reachable from the attack host.
Public exploit code and default payloads often fail silently due to version mismatch, egress filtering, or WAF rules, and candidates misread the failure as 'the box is patched' rather than a payload or routing problem.
What to do instead
Confirm version and behavior with a benign proof first (a controlled request showing the vulnerable parameter, a file read of a known file, or an out-of-band callback). Then choose a payload matching the discovered egress path (HTTP/S, DNS, or common allowed ports) and verify the listener before sending it.
Getting a shell and then running a generic automated privilege-escalation script once, reading only the first few lines of output, and concluding the host has no escalation path.
Automated scripts produce long output with many false positives and low-signal items, and candidates lack a structured manual triage habit, so real findings such as a writable service binary, a stored credential, or a misconfigured scheduled task get buried.
What to do instead
After the automated scan, manually verify in a fixed order: current user privileges and groups, sudo or token privileges, writable paths in services and scheduled tasks, credential files and history, installed software versions, and network-internal services. Record each candidate with the exact command that confirms or rejects it.
Trying to pivot with a full interactive toolset on a host that only supports a limited shell, or assuming every internal host is reachable from the attack machine, without establishing a tunnel or proxy first.
Candidates conflate 'I have a shell' with 'I have routing', and they forget that internal-only services need a proxy or port forward; failed connections are then misdiagnosed as closed ports.
What to do instead
Map reachability explicitly: from the compromised host, test which internal subnets and ports respond, then set up a tunnel or SOCKS proxy and verify it with a known-open internal port before scanning. Keep a diagram of which host provides which pivot and which tooling runs locally versus through the proxy.
Spraying a single password across many accounts without checking lockout policy, or reusing one credential set everywhere without first harvesting hashes and credentials from memory, files, and configuration stores.
The exam includes lockout thresholds and candidates lock accounts by guessing too aggressively; separately, they chase brute force when a dumped hash or config file credential would have answered instantly.
What to do instead
Before any spraying, query the domain password and lockout policy and pace attempts below the threshold. Prioritize credential extraction from accessible sources (LSASS, SAM, configuration files, history, unattended install files, CI secrets) over guessing, and log every credential with its source and tested scope.
Leaving findings undocumented until the end, then writing a report that lists tools run instead of vulnerabilities, impact, and reproducible evidence.
Candidates treat reporting as an afterthought squeezed into remaining time, and they confuse activity logs with findings; reconstructing evidence afterwards is slow and often incomplete.
What to do instead
Maintain a running findings log during the exam: for each finding record the affected host, the vulnerability, the exact reproduction steps, the evidence (command output or screenshot description), impact, and remediation. Write the report from that log incrementally rather than at the end.
Exfiltrating or collecting sensitive-looking data (large database dumps, user file shares, credential stores) without a defined objective, and copying everything to the attack host 'just in case'.
Candidates equate collecting data with progress and lack a rule for what evidence the exam actually requires, which wastes time and risks touching data outside the intended scope.
What to do instead
Define the objective before collecting: proof of access, a specific flag or artifact, or evidence needed for the report. Collect the minimum that proves the finding, record its source path and hash or size, and avoid bulk transfer of unrelated user data. Document the exfiltration channel and method used.
Abandoning a host after the first failed exploit attempt and never returning, so partially enumerated hosts with an unresolved service remain unexamined at time-out.
A single failed exploit feels like a dead end, and candidates prefer the momentum of a new host over revisiting notes; the exam's intended path often depends on a second, less obvious service on an already-touched host.
What to do instead
Keep a 'parking lot' list of unresolved services with the exact reason each was paused. On every stall, revisit the parking lot and re-read enumeration output for missed details such as version strings, comments, or non-standard ports before starting a new host.