Preparing for HTB CPTS: A Field Guide to the Ten-Day Marathon

A practical, no-spoiler preparation guide for the HackTheBox Certified Penetration Testing Specialist exam—covering the Academy path, lab practice, note-taking, reporting, exam-week pacing, and the emotional reality of getting stuck.

Before the terminal opens

The hardest part of the HTB Certified Penetration Testing Specialist (CPTS) journey is not a clever payload or an obscure Windows command. It is learning to stay methodical when nothing works.

That lesson usually arrives late at night. You have a shell on one host, a handful of credentials, and a tunnel that worked twenty minutes ago. Your scan results are spread across three terminals. One password authenticates to a service but not to the host you expected. Every lead feels almost right. The temptation is to search for a more exotic exploit.

Then you return to your notes, notice a service you never enumerated through the pivot, and the network opens again.

That is the CPTS experience in miniature. The certification is a practical penetration-testing engagement, not a trivia contest. HackTheBox expects candidates to complete the Penetration Tester job-role path, assess a black-box environment, and submit a professional report. The report is not paperwork added after the hacking; it is part of the work.

What you are really preparing for

The technical syllabus is broad:

• reconnaissance and service enumeration;
• web application testing and common foothold techniques;
• Windows and Linux privilege escalation;
• Active Directory enumeration and abuse;
• password attacks and credential reuse;
• pivoting, tunneling, and lateral movement;
• post-exploitation and evidence collection; and
• professional reporting and remediation writing.

But the exam evaluates three deeper abilities.

Can you create a reliable picture from incomplete information? A port scan is not enumeration; it is the beginning of enumeration. A credential is not merely a password; it is a question to ask of every reachable service and security boundary.

Can you maintain state across a multi-host engagement? As the network grows, you must know which machine can reach which subnet, where each credential came from, what privilege it has, and what remains untested.

Can another professional reproduce and understand your work? A technically correct compromise with missing evidence, vague steps, or poor remediation is unfinished.

Build the foundation before chasing speed

The official Academy path is the center of preparation. Treat 100% completion as a floor, not a finish line. The useful question is not, “Did I complete this module?” It is, “Could I reproduce its assessment from a blank terminal next month?”

For every module, use a four-pass routine:

1. Learn: Read actively and reproduce commands instead of pasting them blindly.
2. Explain: Rewrite each technique in your own words, including why it works and when it fails.
3. Perform: Complete the exercises and skills assessment with minimal hints.
4. Compress: Reduce the lesson into a checklist that can guide you under pressure.

A copied command collection feels reassuring until the exam asks for a variation. A useful note explains intent:

SMB enumeration
Goal: identify shares, readable files, users, domain information,
      and signing policy.

Inputs needed:
- target or target range
- domain, if known
- anonymous, guest, and recovered credentials

Record:
- successful authentication context
- share permissions and interesting files
- usernames, groups, and follow-up tests

This survives tool changes because it records the problem, not just one invocation.

A realistic study plan

There is no honest universal timeline. Experienced testers may compress preparation; candidates studying after work may need many months. One referenced candidate completed the path over roughly eight months while working full time, which is far more relatable than a dramatic “pass in a week” headline. Consistency matters more than speed.

My six months of preparation

I gave myself six months to prepare. At the beginning, that sounded generous. Once I saw the depth of the Academy path—and how quickly a technique disappeared from memory if I only used it once—it felt realistic.

Those six months were not six months of perfect productivity. Some evenings I could work through an entire section; on others, I opened my notes after a full day and managed only one lab or a thirty-minute review. There were weekends when a single skills assessment consumed the time I had planned for several modules. I stopped treating those slower days as failure. They were part of learning how to remain patient when a target refused to cooperate.

The first two months were about foundations and discovering how many gaps I had. Months three and four were where the pieces began to connect: web footholds led naturally into local enumeration, recovered credentials became lateral-movement opportunities, and Active Directory stopped looking like a collection of unrelated tools. The final two months were less about collecting new commands and more about repetition—redoing assessments, repairing tunnels, practicing chained labs, and writing findings while the evidence was still fresh.

The biggest change was in my notes. Early entries were command dumps. By month six, they had become decision guides: what I observed, what it might mean, what I had already ruled out, and what I should test next. That evolution made me feel ready more than any progress percentage did.

Phase 1 — Foundations and enumeration

Spend the first phase making reconnaissance boringly reliable. Build service-specific checklists for HTTP, DNS, SMB, LDAP, Kerberos, MSSQL, WinRM, SSH, FTP, SNMP, and the other protocols covered by the path.

Your goal is to turn raw output into hypotheses:

Observation -> Meaning -> Next test -> Result -> New hypothesis

Do not merely save scan output. Annotate why a result matters.

Phase 2 — Web attacks and footholds

Practice web discovery, virtual-host enumeration, authentication analysis, file inclusion, injection classes, file upload behavior, proxy workflows, and safe payload adaptation. Work from requests and responses rather than depending entirely on automated scanners.

For every successful foothold, answer:

• What clue made this path worth testing?
• What assumption did the application make?
• What evidence proves impact?
• How would the owner fix the root cause?

Phase 3 — Privilege escalation and Active Directory

Alternate Linux and Windows privilege-escalation practice so neither becomes rusty. Then spend focused time on Active Directory: identities, groups, ACLs, Kerberos, delegation, credential material, sessions, shares, and lateral movement.

Draw the environment. A simple map is often more valuable than another tool:

ATTACK HOST
    |
    v
EDGE01 (foothold)
    |
    +-- tunnel --> 10.20.0.0/24
                     |
                     +--> APP01 (user)
                     +--> DC01  (seen, not owned)

Attach credentials and evidence references to the map. The point is not artistic quality; it is reducing cognitive load.

Phase 4 — Chained practice and reporting

Redo the Academy capstone or enterprise-network material from the engagement letter alone. Avoid the walkthrough until you have exhausted your methodology. If time and budget allow, a chained lab such as Dante or Zephyr can help make pivoting and multi-host tracking feel routine. Candidate accounts repeatedly describe Pro Labs and retired Active Directory machines as useful—but supplementary—practice.

Write at least one complete practice report. If you have never produced an executive summary, attack narrative, reproducible finding, risk explanation, and actionable remediation before exam week, the exam is a bad time to learn.

The notebook that carries the engagement

Use whatever note system you can operate quickly and export safely. The format matters less than consistency. Create one page per host and a separate credential ledger.

Host page

Hostname / IP:
Role / OS:
Reachable from:
Ports and services:
Web hosts / domains:
Credentials tested:
Access obtained:
Privilege level:
Interesting files and secrets:
Potential paths:
Completed checks:
Evidence references:

Credential ledger

Never store only the secret. Its origin, scope, and successful uses are what make it actionable.

Evidence log

Record commands and results as you work. Give screenshots meaningful names such as APP01-03-service-account-config.png, not Screenshot_47.png. Capture the command, the relevant output, the affected identity, and the host context. A screenshot should prove something; it should not replace reproducible text.

A readiness test that is harder to fake

You are close to ready when you can complete a multi-host practice environment and truthfully say:

• I can enumerate a host without waiting for a checklist written by someone else.
• I can establish and repair a tunnel without losing an hour to syntax.
• I retest credentials systematically across appropriate services.
• I know how to recover when automated tools fail.
• I can explain every command in my notes.
• I can reconstruct an attack chain the next day from my evidence.
• I can write remediation that addresses the cause, not just the payload.
• I can stop working, sleep, and resume without forgetting the state of the engagement.

The last item is underrated. CPTS rewards continuity, not heroics.

Exam week: what the experience feels like

The first hours can feel strangely quiet. There is no instructor pointing to the next module and no machine title hinting at a theme. You receive scope and objectives, connect to the environment, and face an ordinary-looking attack surface. That ambiguity is part of the assessment.

Day 1: build the map

Read the engagement material twice. Translate it into a scope sheet and a deliverables checklist. Verify connectivity, create your folder structure, start the activity log, and perform broad discovery followed by careful service enumeration.

The emotional trap on day one is urgency. You may feel behind because you do not have a shell immediately. Resist it. A clean map, verified host list, and prioritized hypotheses are progress.

Days 2–4: earn and expand access

Once the first foothold lands, pause before sprinting ahead. Capture evidence while the steps are fresh. Enumerate the local host completely: privileges, processes, services, scheduled tasks, configuration, history, keys, tokens, shares, routes, and credentials.

Then update the map. New network access changes what “complete enumeration” means. Scan from the correct vantage point. Reuse credentials deliberately. Treat each host as both a target and a possible observation post into another segment.

This is usually where the experience becomes exhilarating. One small finding unlocks a second host; that host exposes a credential; the credential reveals an Active Directory relationship. The environment stops looking like isolated boxes and starts looking like a system.

The wall: when nothing moves

Nearly every long practical exam has a stretch where progress stops. The worst response is random tool switching. Use a reset protocol:

1. Step away for fifteen minutes.
2. Re-read the objective and current network map.
3. Verify tunnels, routes, DNS, time synchronization, and authentication context.
4. Re-enumerate the latest compromised host.
5. Review every credential and every service it has not been tested against.
6. Separate facts from assumptions.
7. Ask, “What can this host see that my attack machine cannot?”

Many apparent technical walls are state-management failures: the wrong proxy path, a stale ticket, a missed virtual host, an untested share, or an assumption that a credential belongs to only one service.

Final technical days: close loops

Do not confuse “I reached the objective” with “the engagement is documented.” Re-run the critical path where safe, fill evidence gaps, validate affected assets, and make sure every finding has reproducible steps.

Keep an explicit unresolved list:

[ ] Verify exact privilege before escalation
[ ] Capture clean proof of access
[ ] Record tunnel command and route
[ ] Confirm remediation applies to root cause
[ ] Remove test artifacts where required

Report days: become the consultant

Reserve protected time for writing and review, but draft throughout the exam. A practical rhythm is to write a finding immediately after stabilizing each major step, then polish the complete document near the end.

A strong report has two audiences. Leadership needs the business meaning: what was exposed, how far an attacker could travel, and what should be fixed first. Technical staff need exact evidence, affected systems, reproduction steps, and remediation they can implement.

For each finding, include:

1. title and affected asset;
2. severity with a defensible rationale;
3. concise description of the underlying weakness;
4. evidence and reproducible steps;
5. impact in the context of the environment;
6. root-cause remediation; and
7. references where useful.

Then write an attack narrative that connects the findings. A list of vulnerabilities says what was wrong. An attack chain explains why the combination mattered.

Energy management is part of the methodology

A multi-day exam encourages unhealthy bargaining: one more scan, one more payload, one more hour. Fatigue quietly destroys judgment. You reread the same output, mistype commands, and chase ideas you rejected earlier for good reasons.

Set working blocks, meal breaks, and a sleep floor before the exam begins. End each session with a short handoff note to your future self:

Current access:
What changed today:
Best next hypothesis:
Commands/listeners to restart:
Evidence still missing:

The next morning, that note turns a cold start into a continuation.

Common preparation mistakes

Collecting commands instead of building methodology

A huge cheatsheet is not useful if you cannot decide which command belongs to the current hypothesis. Organize notes by objective and decision point.

Treating enumeration as a one-time phase

Enumeration restarts after every foothold, privilege change, credential discovery, and pivot. The attack surface changes with your position.

Practicing single boxes only

Standalone machines teach exploitation. Chained environments teach memory, routing, credential tracking, and restraint. CPTS preparation needs both.

Leaving reporting until the end

Cold notes produce vague findings. Write while context is alive.

Measuring readiness by path completion

The progress bar measures coverage, not recall. Repeat assessments and explain the technique without the lesson open.

Ignoring current exam rules

Policies evolve. HackTheBox currently requires professional English-language documentation submitted through the exam dashboard and publishes specific rules on report format, retakes, and AI usage. In particular, do not paste exam data into public AI systems or use AI to generate the exam report. Read the current certification terms yourself before the attempt.

The final pre-exam checklist

One week before

• Freeze major tooling changes.
• Rehearse VPN, note, screenshot, and report workflows.
• Review weak modules and redo selected assessments.
• Test backup connectivity and local storage.
• Prepare a clean report skeleton and evidence naming scheme.
• Confirm the current official rules and submission format.

The day before

• Update only what must be updated.
• Verify disk space, time synchronization, VPN, and essential tools.
• Prepare food, water, breaks, and sleep—not just commands.
• Stop studying early enough to begin rested.

Before submission

• Confirm every required objective and current portal requirement.
• Check that each finding is reproducible from the report.
• Remove secrets that do not belong in the deliverable.
• Verify hostnames, IP addresses, figure numbers, and severity labels.
• Export to the required format and inspect the final file page by page.
• Remember that final submission ends the live attempt and cannot be replaced afterward; verify before clicking.

What stays after the badge

The most valuable result of CPTS preparation is not memorizing a particular privilege-escalation path. It is becoming calmer inside ambiguity.

You learn that being stuck is not proof that you lack talent. It is a signal to reduce the problem: confirm access, inspect assumptions, restore the map, enumerate again. You learn that documentation is not separate from technical work; it is how technical work remains trustworthy. You learn that sleep can be a tactical decision and that a clean methodology beats bursts of inspiration.

The exam may feel like a ten-day marathon, but it is won in the ordinary weeks before it—one carefully documented lab, one rebuilt tunnel, and one honest post-mortem at a time.