10 Tips for CPTS

This post contains general CPTS preparation advice only. It does not include exam-specific machines, flags, network details, solutions, or private exam content.

I passed the HTB Certified Penetration Testing Specialist exam, and it was one of the most challenging certification experiences I have had so far.

Not because it was impossible. Not because it required some mythical level of talent. But because CPTS tests something that is hard to fake: methodology.

You need to enumerate carefully, pivot effectively, manage credentials, troubleshoot when tools fail, document as you go, and keep moving when you feel stuck. It is not enough to know commands in isolation. You need to know when to use them, why they matter, how to validate the results, and what to do when they do not work the first time.

These are the ten biggest lessons I would give anyone preparing for CPTS.

No spoilers. No exam-specific details. Just the things that made a real difference.

1. Learn Ligolo Before You Need Ligolo

Ligolo is your friend.

Your best friend.

Your emotional support tunneling tool.

Your lover.

Learn Ligolo.

Seriously, if there is one tool I would tell people to get comfortable with before CPTS, it is Ligolo-ng. Pivoting is not something you want to be figuring out from scratch while under pressure. You want the workflow to feel boring before exam day.

You should be comfortable with:

• Starting the Ligolo proxy
• Connecting an agent
• Creating and enabling the TUN interface
• Adding routes
• Confirming which session is active
• Scanning through the tunnel
• Handling double pivots
• Using listeners when needed
• Troubleshooting when traffic does not route the way you expect

The important part is not just “can I run Ligolo?” The important part is understanding the flow.

At a high level:

Attack box -> Pivot host -> Internal network

And sometimes:

Attack box -> Pivot host 1 -> Pivot host 2 -> Deeper internal network

That second case is where people get uncomfortable if they have only practiced simple single-hop pivoting.

Know how to answer these questions without panicking:

• Which host is my current pivot?
• What network am I trying to reach?
• Did I add the correct route?
• Is my Ligolo interface up?
• Is the agent connected?
• Am I scanning with the right options?
• Is this a routing issue, a firewall issue, a DNS issue, or a service issue?

When scanning through Ligolo, you may need to adjust how you scan. For example, TCP connect scans are often more reliable through a tunnel than default SYN scans.

nmap -Pn -sT -p- --min-rate 5000 <target>

The exact scan strategy depends on the environment, but the principle stays the same: understand how your traffic is moving.

Do not treat pivoting as a side skill. Treat it as core methodology.

If you cannot reach the network, you cannot enumerate it. If you cannot enumerate it, you cannot compromise it. If you cannot compromise it, you cannot progress.

2. Enumerate Everything, Then Enumerate It Again

CPTS rewards careful enumeration.

That sounds obvious, but it is easy to underestimate what “careful” means.

Do not just check a share. Check every share.

Do not just check the obvious files. Check every file you can access.

Do not just test one user against one service. Track every user, every credential, every host, every protocol, and every result.

You need to build the habit of asking:

What do I know now that I did not know ten minutes ago?

Every new piece of information can change the meaning of old information.

A share that looked useless with anonymous access may become interesting with valid credentials.

A host that looked locked down externally may expose something useful internally.

A user that failed against SMB may work over WinRM, LDAP, MSSQL, SSH, or a web portal.

A password that seems low-privileged may unlock a completely different path elsewhere.

Enumeration is not a phase you complete once. It is a loop.

Enumerate -> Find something -> Validate it -> Re-enumerate -> Repeat

Examples of things worth re-checking after new access:

• SMB shares
• LDAP data
• User descriptions
• Group memberships
• Home directories
• Web apps
• Internal DNS
• Configuration files
• Databases
• Password reuse
• Local privileges
• Domain privileges
• Open ports from a new network position

A lot of progress comes from noticing that something changed.

That means you need to be willing to go back.

Not because you failed the first time, but because your access level changed.

3. Build Notes You Can Actually Use Under Stress

Good notes matter.

Not pretty notes. Not giant copy-pasted course dumps. Useful notes.

During prep, your notes should answer three questions:

What command do I run?
When do I run it?
What do I do if it fails?

That third question is where a lot of people get hurt.

A note that says:

bloodhound-python -d domain.local -u user -p pass -ns <dc-ip> -c all

is fine.

A better note says:

Use this when:
- I have valid domain credentials
- I can reach the DC
- DNS resolution works or I can specify the nameserver

If it fails:
- Check /etc/hosts
- Try using the DC IP as nameserver
- Confirm the domain name
- Confirm the username format
- Check time sync
- Try collection from a domain-joined host if available

That is the difference between a command list and an actual field guide.

Your notes should include:

• Commands
• Common errors
• Fixes
• Decision trees
• Examples
• What each tool is actually doing
• How to validate results manually
• Alternative tools for the same job

For CPTS prep, I would organize notes by situation, not just by tool.

Instead of only having:

nmap.md
crackmapexec.md
bloodhound.md
ligolo.md

also have:

I found credentials.md
I found a new subnet.md
I found SMB open.md
I found MSSQL open.md
I have a shell.md
I am stuck.md
I need to pivot.md
I need to write the report.md

That structure is more useful when you are tired.

The exam is not the time to remember where a random command lives in your notes. Your notes should work like a second brain.

4. Track Credentials Like They Are Evidence

Credentials are not just “loot.” They are state changes.

Every credential should be tracked.

At minimum, record:

Username:
Password / Hash:
Domain:
Where found:
Access confirmed:
Services tested:
Hosts tested:
Privileges:
Notes:

For example:

Username: jsmith
Password: ExamplePassword123
Domain: example.local
Where found: config file on web server
Access confirmed: SMB, LDAP
Services tested: SMB, LDAP, WinRM, MSSQL
Hosts tested: DC01, FILE01, WEB01
Privileges: Domain user
Notes: Can read Finance share

This prevents you from wasting time and missing reuse.

Password reuse is one of the most important things to test methodically. Do not assume a credential only belongs to the first place you found it.

Try credentials across:

• SMB
• WinRM
• SSH
• FTP
• MSSQL
• MySQL
• PostgreSQL
• Web logins
• Admin panels
• LDAP
• Internal applications

Also track failures.

A failed login is still information, especially if you know where it failed and how.

There is a huge difference between:

creds don't work

and:

creds work for SMB on FILE01, fail for WinRM on DC01, work for LDAP, no admin rights, can read SYSVOL

The second one gives you a path forward.

The first one just gives you frustration.

5. Think in Attack Paths, Not Individual Vulnerabilities

CPTS is not just about finding a vulnerability and firing an exploit.

It is about chaining.

A single finding may not be enough by itself. But several small findings together can become a full compromise path.

For example, a realistic chain might look like:

Public information -> Username generation -> Weak credential path -> Internal access -> More enumeration -> Privilege escalation -> Lateral movement -> Domain compromise

The key is to constantly ask:

What does this give me?
What can I now access?
What can I now enumerate?
What changed?

Avoid thinking only in terms of named vulnerabilities.

Think in terms of capability.

Did you gain:

• A username?
• A password?
• A hash?
• A shell?
• Read access to files?
• Write access to a directory?
• Access to a new subnet?
• Access to a database?
• A new domain context?
• A new user context?
• A new group membership?
• A new internal web app?
• A new way to execute code?

Every capability should trigger another round of enumeration.

A lot of people get stuck because they are looking for “the exploit” instead of recognizing that the path is already forming.

6. Do Not Trust One Tool’s Output Blindly

Tools fail.

Tools lie.

Tools timeout.

Tools mislead you.

Sometimes the problem is the tool. Sometimes the problem is your syntax. Sometimes the problem is routing. Sometimes the problem is DNS. Sometimes the account is valid but not allowed to log in through that service. Sometimes a scan misses a port. Sometimes a service behaves differently through a pivot.

You need to validate important findings more than one way.

If SMB auth fails in one tool, try another.

If BloodHound collection fails, check LDAP manually.

If a web scanner shows nothing, browse manually.

If a port scan looks too clean, rescan from another position.

If DNS is weird, add entries manually and test again.

A good troubleshooting mindset is:

Is the target reachable?
Is the port open?
Is name resolution working?
Is authentication working?
Is authorization the issue?
Is my tunnel working?
Is my syntax correct?
Is there another way to test the same thing?

For example, if a domain tool fails, do not immediately assume the credentials are bad.

Check:

• Can I ping or otherwise reach the host?
• Can I connect to the port?
• Is /etc/hosts correct?
• Am I using the right domain format?
• Is the domain controller reachable?
• Is DNS resolving?
• Is my clock synced?
• Does the password contain special characters that need quoting?
• Does the account work against a different service?

This matters because the difference between “dead end” and “breakthrough” is often just troubleshooting.

7. Get Comfortable With Active Directory Enumeration

You do not need to be an Active Directory wizard before CPTS, but you need to be comfortable with the fundamentals.

Know what you are looking at when you see:

• Users
• Groups
• Computers
• Service accounts
• SPNs
• Kerberos
• LDAP
• SMB
• ACLs
• Delegation
• Local admin rights
• Domain admin rights
• DCSync-capable rights
• GPOs
• Shares
• Sessions
• Password policy
• Reuse patterns

BloodHound is extremely useful, but it should not be your only understanding of AD.

You should know how to ask basic questions manually:

Who are the users?
What groups exist?
What groups is this user in?
What machines exist?
What shares can I read?
Can I authenticate over LDAP?
Can I authenticate over SMB?
Can I access WinRM?
Does this account have interesting rights?
Does this machine have local admin exposure?

BloodHound is best when paired with your own understanding.

Do not just click paths blindly. Understand what the edge means. Understand why it matters. Understand what access is required to abuse it. Understand how to validate it.

CPTS is very good at exposing shallow understanding.

If you only know “run tool, click path,” you will struggle when the tool breaks or the environment does not match the example exactly.

8. Web Enumeration Still Matters

Even when the exam feels infrastructure-heavy, do not neglect web enumeration.

Web apps can expose:

• Usernames
• Emails
• Internal hostnames
• Source code
• Credentials
• Upload functionality
• Admin panels
• API endpoints
• Debug information
• Version numbers
• Virtual hosts
• Default credentials
• Configuration leaks

You should be comfortable with both automated and manual web testing.

Automated tools are useful for coverage, but manual testing is where you often find the thing that matters.

Check:

• Page source
• JavaScript files
• Comments
• Hidden parameters
• Upload behavior
• Authentication logic
• Default routes
• Error messages
• Directory brute forcing
• Virtual hosts
• API responses
• Cookies
• Headers
• Technology stack
• Git exposure
• Backup files
• Config files

Also, learn to slow down with web apps.

Click everything. Read everything. Watch requests. Change parameters. Compare responses. Test assumptions.

A small web finding can become the first domino in a much larger compromise.

9. Document While You Work, Not After

Do not wait until the end to document.

You will forget things.

You will forget where a credential came from.

You will forget which host had which file.

You will forget the exact command that worked.

You will forget the order of the attack path.

You will forget why something mattered.

Take notes as you go.

At minimum, capture:

• Commands that produced meaningful results
• Screenshots of important proof
• Credentials and where they came from
• Hosts and services discovered
• Changes in access
• Successful exploitation steps
• Failed paths that consumed time
• Evidence for findings
• Remediation ideas while they are fresh

A good habit is to write mini-summaries during the assessment.

For example:

Current status:
- Have shell as low-privileged user on HOST01
- Found credentials for svc_example in config file
- svc_example works over SMB and LDAP
- New internal subnet reachable through pivot
- Need to enumerate SMB shares and AD rights with svc_example

That kind of note keeps you oriented.

It also makes report writing dramatically easier.

The CPTS report is not something you want to reconstruct entirely from memory. Treat your working notes like raw report material.

Future you will thank you. I learned this the hard way.

10. The Report Is Part of the Exam

Do not treat the report as an afterthought.

The report is where you prove what you did.

It is not enough to compromise systems. You need to explain the compromise clearly, professionally, and in a way that someone else could understand.

Your report should show:

• Scope
• Methodology
• Attack path
• Evidence
• Impact
• Reproduction steps
• Findings
• Remediation
• Risk

The biggest thing is clarity.

A good technical section should answer:

What was discovered?
Why did it matter?
How was it exploited?
What access did it provide?
What evidence supports it?
How should it be fixed?

Screenshots help, but screenshots are not the report.

Do not just paste images and hope the reader understands the story. Explain the decision-making.

For each major step, write:

I found X.
X mattered because Y.
I validated it by doing Z.
This allowed the next step: A.

That structure makes the report readable.

Also, write findings as security issues, not just as a chronological diary.

For example, instead of only saying:

I used this password to log in.

frame the finding as:

Insecure credential storage allowed recovery of valid domain credentials.

Then explain the evidence, impact, and remediation.

CPTS is a penetration testing certification. Reporting is part of penetration testing.

Take it seriously.

Bonus: Manage Your Mindset

This exam can mess with your head.

You may get stuck.

You may question whether you are good enough.

You may spend hours on something that goes nowhere.

That does not mean you are failing. That means you are doing a real hands-on exam.

When you get stuck, do not spiral.

Reset with a checklist:

What hosts do I know about?
What ports are open?
What credentials do I have?
Where have I tested them?
What shares can I access?
What files have I not read?
What users have I not checked?
What changed since my last enumeration pass?
What can I reach now that I could not reach before?
What have I assumed but not verified?

The answer is often not “try harder.”

The answer is usually:

Go back and enumerate better.

That sounds simple, but it is the truth.

CPTS is not about being a genius. It is about staying methodical when you are tired, frustrated, and unsure.

Final Thoughts

The biggest lesson I took from CPTS is that methodology beats panic.

You do not need to know every exploit on earth. You do not need to be perfect. You do not need to instantly recognize every path.

But you do need to be disciplined.

Learn pivoting. Take real notes. Enumerate everything. Track credentials. Re-check old targets when you gain new access. Understand Active Directory. Troubleshoot your tools. Document as you go. Treat the report seriously.

And above all:

Do not stop at the first dead end.

CPTS rewards the person who keeps asking:

What changed?
What can I see now?
What have I not checked yet?

That mindset made the difference.