The HTB Certified Penetration Testing Specialist (CPTS) is not a trivia exam. It tests whether you can work through realistic attack paths, think clearly under pressure, and turn scattered findings into a usable methodology. That is why many candidates struggle even after finishing modules or labs. They study topics in isolation, but the exam expects them to connect enumeration, exploitation, post-exploitation, pivoting, and reporting decisions into one flow. This guide breaks the CPTS domains into practical study areas, explains what each one really tests, and shows how to review them in a way that matches how the exam feels.
What the CPTS domains are really testing
At a high level, CPTS measures whether you can assess targets the way a junior-to-mid penetration tester would in a real engagement. That means the exam is not only about knowing commands. It is about choosing the right next step when the first step fails.
Most CPTS preparation falls into a few broad areas:
- Methodology and scoping logic
- Enumeration and service analysis
- Web application testing and exploitation
- Active Directory attack paths
- Credential attacks and privilege escalation
- Pivoting, tunneling, and internal movement
- Defensive analysis and evidence interpretation
- Wi-Fi and network access concepts
- AI or LLM-related security basics
- Reporting discipline and proof collection
The important point is this: the exam rewards process. If you know five exploitation tricks but miss obvious enumeration, you will waste time. If you can enumerate well but cannot recognize a weak ACL, token abuse path, or web input flaw, you will stall. Good preparation means learning how domains connect, not just checking them off.
Methodology comes first because it saves time everywhere else
Many candidates underestimate methodology because it feels less exciting than exploitation. That is a mistake. Methodology is what keeps you from getting lost.
For CPTS, you should be able to move through a target in a repeatable way:
- Initial discovery: identify hosts, services, web apps, shares, and exposed interfaces
- Focused enumeration: dig into each service based on what it is, not based on random tool output
- Hypothesis building: ask what misconfigurations or attack paths are likely
- Validation: test carefully and collect proof
- Privilege escalation or lateral movement: use the new access to expand visibility
- Documentation: note commands, credentials, evidence, and dead ends
What to study here:
- How to build a host-by-host checklist
- How to prioritize likely attack surfaces
- How to track credentials, hashes, tokens, and sessions
- How to decide when to stop enumerating and start exploiting
What to practice: take a retired box or lab and forbid yourself from exploiting anything for the first 30 minutes. Just enumerate and write a decision tree. This trains the exact discipline the exam needs.
Enumeration is the highest-value CPTS skill
If there is one domain that affects every other domain, it is enumeration. Nearly every successful exam attempt depends on spotting details that look minor at first: a version string, an unusual web parameter, a writable share, a password policy clue, a forgotten subdomain, a certificate name, or a local file that reveals internal structure.
You should be comfortable enumerating:
- Common TCP and UDP services such as SMB, LDAP, Kerberos, DNS, FTP, SSH, RDP, WinRM, NFS, SQL, web servers, mail services, and SNMP
- File shares and permissions
- Usernames, groups, and domain information
- Virtual hosts, directories, API paths, and exposed source files
- TLS details, banners, and metadata
What to memorize here is limited. You should remember what a service usually exposes and which tools can query it. But the real test is scenario-based. Can you look at SMB output and recognize that anonymous access matters? Can you query LDAP and turn raw objects into useful attack ideas? Can you see a web app with file upload and test whether validation is real or superficial?
A useful review habit is to study service-by-service. For example, spend one session only on SMB: null sessions, shares, permissions, useful files, RID cycling, group policy clues, and common mistakes in Windows environments. Then do the same for LDAP, then DNS, then HTTP. That builds depth instead of shallow familiarity.
Web exploitation matters because it often opens the first door
Web testing in CPTS is not just about running a scanner and hoping for a hit. You need a practical grasp of how modern web flaws appear during manual testing.
Focus on the issues that often matter in realistic labs:
- Authentication weaknesses
- Access control flaws
- File upload issues
- SQL injection and query manipulation
- Command injection
- Server-side request forgery
- Path traversal and local file inclusion
- XXE, deserialization, and template injection basics
- JWT and session handling mistakes
What to study is not only “what is SQL injection?” You should study how to confirm it, how to safely escalate the impact, what evidence proves exploitation, and how a foothold from the web layer can expose the underlying host or internal network.
For example, a file upload flaw is not just a web bug. It can become code execution, credential theft from config files, a database pivot, or a route into the internal domain. That is why web exploitation belongs in a larger methodology, not in a silo.
Active Directory is a core domain because attack paths are chained
For many candidates, Active Directory is the hardest CPTS area because it combines enumeration, privilege relationships, credential handling, and lateral movement. AD questions and lab scenarios are rarely one-step problems.
You should be ready to work with:
- Domain enumeration of users, groups, computers, shares, sessions, SPNs, ACLs, and trust information
- Password attacks such as spraying, cracking, Kerberoasting, and AS-REP roasting where applicable
- Privilege escalation paths involving group memberships, delegated rights, ACL abuse, service misconfigurations, or token opportunities
- Lateral movement methods using valid credentials and remote management channels
- Common AD weaknesses such as reused local admin rights, writable scripts, insecure GPO-linked files, over-permissioned service accounts, and bad certificate-related assumptions if covered in your prep
This is a domain where candidates often over-memorize tool syntax and under-practice interpretation. The exam does not care whether you remember a fancy command if you cannot explain why a given object matters.
Example: if you find a service account with an SPN, the key question is not “what command do I run?” The key question is “is this roastable, can I crack it, what access would that account give me, and how does that move me closer to domain impact?”
Defensive analysis matters because not all clues come from obvious exploits
CPTS preparation should include reading systems like an investigator. In real labs and exam-style scenarios, useful evidence often sits in logs, configs, scripts, scheduled tasks, backup files, note files, browser artifacts, shell history, and permissions data.
This is where defensive analysis overlaps with offensive work. You are not defending the environment, but you are reading defensive traces and operational mistakes to guide your next move.
Study how to inspect:
- Configuration files for hardcoded credentials and internal addresses
- Logs for usernames, errors, token leakage, app paths, and network activity
- Process and service listings for unusual privileges or insecure startup behavior
- Scheduled jobs and automation scripts for credentials or writable execution paths
- Browser and shell artifacts for user behavior clues
Why this matters: many privilege escalations are not “exploit the kernel.” They are “read the environment carefully enough to spot how admins actually work.”
Wi-Fi and AI security should be studied as practical concepts, not niche trivia
Not every candidate expects Wi-Fi or AI security topics, but they fit the broader CPTS mindset: identify attack surface, understand trust assumptions, and test weak controls.
For Wi-Fi, focus on the basics that support assessment logic:
- Authentication types and why they matter
- Weak pre-shared key scenarios
- Evil twin, rogue AP, and client trust concepts
- Capture, handshake, and credential exposure fundamentals
For AI or LLM security, keep the same grounded approach:
- Prompt injection concepts
- Data exposure risks through model interaction
- Insecure plugin or tool-use assumptions
- Indirect prompt influence and trust boundary failures
You do not need abstract theory here. You need enough understanding to recognize where an application trusts input too much or leaks information through connected AI functionality.
What to memorize versus what to practice in scenarios
This is one of the biggest study efficiency questions.
Mostly memorize:
- Common ports and service defaults
- Authentication protocol basics
- Typical outputs from key enumeration tools
- Core web vulnerability patterns and terminology
- AD object types, common rights, and attack names
- Reporting structure and evidence requirements
Mostly practice in scenarios:
- Deciding which service to investigate first
- Turning weak clues into attack hypotheses
- Chaining web flaws into host access
- Moving from one credential to wider domain visibility
- Finding privilege escalation paths from messy system data
- Pivoting into internal-only targets
A good rule: if the topic involves judgment, sequence, or trade-offs, scenario practice matters more than memorization.
How to convert each domain into practice sessions
Do not study domains only by reading notes. Convert each one into a short lab routine with a clear output.
- Methodology session: enumerate one target and produce a written attack plan before exploitation.
- Service enumeration session: pick one protocol such as SMB or LDAP and extract every useful fact from a target.
- Web session: test one app manually for auth, input handling, file functions, and hidden routes.
- AD session: start with low privileges and map possible escalation paths without using hints.
- Privilege escalation session: focus only on local enumeration and abuse opportunities on Linux or Windows.
- Pivoting session: set up or use a foothold to reach an internal host and document the route.
- Evidence session: after solving a box, write short proof notes for each finding and access step.
If you want a focused way to pressure-test weak areas before the exam, use a practice resource that matches CPTS-style thinking, not just recall. One option is this HTB CPTS practice test to check how well you understand the domains and where your gaps are.
The key is to leave every session with something measurable: a checklist, notes, proof screenshots, or a timeline of decisions. That is how skill becomes exam-ready.
Recommended review order before practice tests
If your study feels scattered, use this order:
- Methodology and note-taking workflow
- Core enumeration across common services
- Web exploitation basics and manual testing habits
- Linux and Windows privilege escalation
- Active Directory enumeration and attack paths
- Credential attacks and lateral movement
- Pivoting and internal access
- Defensive artifact analysis
- Wi-Fi and AI security review
- Timed mixed practice and weak-area retesting
This order works because it mirrors how engagements unfold. You first need structure, then visibility, then exploitation, then expansion.
How to track weak areas without fooling yourself
Many candidates think they are weak in “AD” or “web” when the real issue is narrower. Track weaknesses at the task level.
Examples of useful weak-area labels:
- Missed subdomain or vhost enumeration
- Did not inspect file share permissions deeply enough
- Recognized SQL injection too late
- Found credentials but failed to test reuse systematically
- Enumerated AD objects but missed ACL abuse clue
- Got foothold but lacked local privilege escalation checklist
- Failed to document evidence while working
This matters because specific weaknesses can be fixed with focused practice. Vague labels usually lead to vague review.
Mini FAQ
Are all CPTS domains weighted equally?
No exam of this type feels truly equal in practice. Enumeration, methodology, web testing, privilege escalation, and Active Directory usually influence success more than niche knowledge because they appear in more attack chains.
Should beginners study everything before taking practice tests?
No. Start practice early. Otherwise, you may build false confidence from reading alone. Even small labs will show whether you can apply what you learned.
How do I know if I am ready for scenario-based questions?
If you can enumerate a target, explain three likely attack paths, test them in a sensible order, and document what happened without copying someone else’s walkthrough, you are getting close.
What is the biggest mistake CPTS candidates make?
Jumping to exploitation too early. The second biggest is poor documentation. Both mistakes waste time and hide the real path forward.
How often should I revisit weak domains?
Use a short cycle. Review the weak point within 48 hours, practice it again within a week, and retest it later under time pressure. That spacing makes improvement stick.
Final study advice
The best CPTS preparation is not “study harder.” It is “study in the same shape as the exam.” Build your process around enumeration quality, attack-path reasoning, service familiarity, and clean evidence collection. Learn the common concepts, yes, but spend more time practicing transitions: from web bug to shell, from credential to reuse, from foothold to privilege, from domain visibility to the one misconfiguration that changes everything.
If you review the domains this way, you will not just remember more. You will make better decisions, faster. And that is what CPTS is really testing.
