The HTB Certified Penetration Testing Specialist exam is not a theory test. It checks whether you can work through a realistic attack path, stay organized under time pressure, and produce results that make sense. That is why “am I ready?” is not really about how many modules you finished or how confident you feel after a few good labs. Real readiness means you can repeat the core tasks, recover from mistakes, and keep moving when a target does not behave the way you expected. This checklist is built for that final stage. It will help you confirm your skills, spot weak areas, and use your last review days well.
What exam readiness should actually look like
Many candidates judge readiness the wrong way. They ask whether they have “seen” all the topics. That is not enough. In a hands-on exam, recognition is much weaker than execution. You need to be able to perform key actions without wasting mental energy on the basics.
You are likely close to ready if most of these statements are true:
- You can enumerate methodically. You do not scan randomly or skip common checks. You know how to build a quick picture of services, web content, users, shares, permissions, and possible attack paths.
- You can turn findings into decisions. For example, if you find SMB access, Kerberos data, password policy details, or an unusual web endpoint, you know what those findings suggest and what to test next.
- You can chain steps. The exam is not just “find one vulnerability.” You may need to combine enumeration, web testing, credential attacks, pivoting, or privilege escalation.
- You can troubleshoot calmly. If a tool fails, a shell dies, or a tunnel breaks, you do not freeze. You check ports, syntax, privileges, firewall rules, routes, and target assumptions.
- You take clean notes. You can track hosts, users, creds, hashes, URLs, commands, and proof in a way that you can actually use later.
- You can work for hours without losing structure. Endurance matters. A candidate who is “good at boxes” but becomes messy after three hours is still at risk.
A simple test is this: can you solve medium-difficulty lab paths from scratch, under a timer, while writing notes that another tester could follow? If not, your issue may not be knowledge. It may be process.
Core skills you should verify before the exam
Final review should focus on job-like actions, not broad reading. Below are the main skill groups to check.
- Host and service enumeration. You should be comfortable identifying exposed services, version clues, directory structures, virtual hosts, file shares, and likely misconfigurations. The reason this matters is simple: weak enumeration causes missed paths. Most exam failures start here.
- Web application testing. Be able to test authentication, input handling, file upload behavior, parameter tampering, common injection points, and access control mistakes. You do not need to guess wildly. You need to test logically based on what the application does.
- Credential abuse. Verify that you can work with passwords, password reuse, spray logic, hashes, and discovered secrets from configs, scripts, or shares. In many realistic environments, creds are the bridge between systems.
- Active Directory basics and attack flow. You should understand users, groups, shares, permissions, domain enumeration, service accounts, and common ways one foothold leads to wider access. The key is not memorizing every attack name. It is understanding what data matters and how privilege relationships work.
- Privilege escalation on Linux and Windows. Confirm that you know how to check permissions, services, scheduled tasks, sudo rules, PATH issues, writable files, registry or service weaknesses, and sensitive local data. Escalation often rewards patience more than cleverness.
- Lateral movement and pivoting. You should be able to move from one host to another when direct access is not possible. That includes port forwarding, tunnel awareness, and route discipline. This matters because many exam candidates do well on the first host and stall on internal reachability.
- Shell handling and file transfer. Reverse shells, bind shells, upgrading shells, transferring tools, using native utilities, and maintaining stable access should feel routine. If each shell takes 20 minutes to stabilize, you lose valuable time.
- Reporting discipline. Even if your main concern is technical success, your notes and evidence still matter. You should be able to capture proof, record steps, and explain what happened clearly.
Topic checklist for final revision
Use this as a practical pass-or-fail list. If an item feels shaky, it deserves focused lab time.
- Recon workflow: ports, service banners, web content discovery, subdomains or vhosts where relevant, SMB or NFS checks, SNMP checks, and basic AD-aware enumeration.
- Web testing workflow: logins, default creds, registration flows, password reset logic, file upload restrictions, hidden parameters, cookies, authorization checks, and input fuzzing.
- Credential paths: config files, backups, source code, scripts, browser-stored data, command history, shares, and exposed secrets in web apps.
- Linux privilege escalation: sudo rights, SUID files, writable scripts, cron jobs, service misconfigs, capabilities, kernel context, and weak file permissions.
- Windows privilege escalation: services, scheduled tasks, token or privilege context, writable paths, registry settings, stored credentials, and local group memberships.
- AD movement: user and group mapping, share access, Kerberos-related enumeration, password policy awareness, service account review, and privilege relationship analysis.
- Tunneling and pivoting: SOCKS or port forwards, local versus remote forwards, route checking, and validating internal service access through the pivot.
- Evidence capture: screenshots, command output, hostnames, IP mapping, hashes, users, and timestamps where useful.
The reason to review topics this way is that exams reward consistency. A candidate who is “pretty good” at many things but reliable at few things is still vulnerable.
Red flags that show you need more practice
Be honest here. These patterns usually mean a candidate is not fully ready yet.
- You depend too much on writeups. If you often need to check the next step after initial foothold, your attack logic is not stable enough yet.
- You scan but do not interpret. Running tools is not the same as understanding output. If you collect data but cannot explain why it matters, that is a warning sign.
- You miss easy privilege escalation checks. Repeatedly overlooking sudo entries, service permissions, writable scripts, or saved creds means your checklist is not internalized.
- You panic when the expected exploit does not work. Exams often require adaptation. If one failed path ruins your pace, practice more troubleshooting.
- Your notes are incomplete or messy. This usually causes duplicate work, forgotten creds, and lost proof.
- You cannot finish timed practice cleanly. Even if you eventually solve the target, taking too long on basic enumeration is a problem.
- You repeat the same mistake across labs. For example, forgetting to check alternate ports, not testing file permissions, or not revisiting creds on other services.
If two or more of these sound familiar, your best move is not more reading. It is targeted repetition on the exact failure pattern.
How to use timed practice sets the right way
Timed practice is useful only if you review it properly. Do not treat it as a score-only exercise. Treat it as process training.
Here is a better way to run a timed set:
- Set a clear scope. For example, one standalone host, one web app chain, or one mini AD path.
- Use fixed time blocks. Example: 30 to 45 minutes for enumeration, 60 to 90 minutes for exploitation attempts, then a structured escalation review.
- Write notes as if they matter. Do not tell yourself you will remember. You will not, especially under stress.
- Mark decision points. If you pivot from one idea to another, write why. Later, this shows whether your judgment was good or rushed.
- Do a post-mortem. Ask what you missed, what took too long, which command syntax slowed you down, and which assumption was wrong.
The goal is to reduce friction. Good candidates are not always the fastest at one trick. They are the ones who avoid losing 45 minutes to preventable confusion.
A practical 7-day final review plan
This plan assumes you are in the final stage and already have broad coverage of the material.
- Day 1: Full readiness audit. List your strong and weak areas. Run one timed target and review it hard. Identify where time was lost: enumeration, shell handling, escalation, pivoting, or note-taking.
- Day 2: Enumeration and web focus. Practice quick host triage, web discovery, login testing, and parameter analysis. The aim is to sharpen your first-hour workflow.
- Day 3: Linux and Windows privilege escalation. Run short drills. Use a checklist until the order of checks becomes natural. Focus on speed and completeness.
- Day 4: AD and credential chaining. Practice user and share discovery, service account review, policy awareness, and using found creds across systems. Think in paths, not single findings.
- Day 5: Pivoting and internal access. Build and test tunnels. Move traffic through a foothold. Confirm you can reach internal services and still stay organized.
- Day 6: Full timed simulation. Recreate exam conditions as closely as possible. No distractions. No writeups. Notes required. Then review your process, not just the result.
- Day 7: Light review only. Revisit your checklists, common commands, note templates, and proof-capture habits. Do not cram new content. Protect your energy.
The reason this works is that the final week should tighten execution, not expand your syllabus. Last-minute topic hunting often hurts more than it helps.
Exam-day checklist for sleep, time management, and review
Technical ability matters, but exam-day discipline protects that ability.
- Sleep normally the night before. Lack of sleep hurts judgment, memory, and troubleshooting speed. Those are exactly the skills you need most.
- Prepare your setup early. Check your lab system, note template, folders, terminal layout, and common tools before starting.
- Plan your opening hour. Start with broad enumeration, not random exploitation. Build your target map first.
- Track time by phases. If one path is going nowhere, step back and reassess instead of forcing it for hours.
- Document proof immediately. When you get access or find key data, capture it then. Do not trust later memory.
- Review assumptions. If stuck, ask: what do I know, what did I infer, and what did I never verify?
- Use micro-breaks. Two or three minutes away from the screen can reset your thinking and stop tunnel vision.
Near the end of your prep, it can help to test your timing and decision-making with focused exam-style questions. If you want one more structured round of final practice, use this HTB CPTS practice test as part of your review routine.
Final self-check before you book or sit the exam
Ask yourself these direct questions:
- Can I enumerate a host thoroughly without a checklist in front of me?
- Can I explain why I am trying each next step?
- Can I recover when a tool, exploit, or tunnel fails?
- Can I escalate on both Linux and Windows using a structured process?
- Can I keep notes that would support a clear report later?
- Can I work under a timer without becoming chaotic?
If your answer is “not really” on several of these, that is useful information, not bad news. It tells you where to train. Readiness is not about feeling fearless. It is about being reliable.
FAQ
What if my practice scores are low, but I sometimes solve hard labs?
That usually means your performance is uneven. Exams reward consistency more than occasional standout results. Look at where points or time are being lost. Often the issue is weak enumeration, poor note-taking, or spending too long on one path.
I keep making the same mistakes. What should I do?
Turn the mistake into a checklist item and drill it on purpose. If you keep forgetting to test found credentials across services, make that a fixed step after every credential discovery. Repeated mistakes usually come from process gaps, not lack of intelligence.
Should I do heavy practice in the final week?
Yes, but it should be focused. Do not try to learn every advanced topic at the last minute. Use the final week to sharpen workflow, timing, escalation checks, and pivoting discipline. Light review on the final day is better than exhausting yourself.
What if I get stuck for a long time during practice?
Study the reason, not just the solution. Did you miss evidence? Did you assume the wrong attack surface? Did you fail to verify access? Long stalls are useful if you turn them into changes in your method.
How many timed practice sessions should I do before the exam?
Enough to make your process stable. For many candidates, two or three serious timed simulations with full review are more valuable than many casual attempts. The review is where most of the improvement happens.
Is confidence a good sign that I am ready?
Only if it comes from repeatable results. Real exam confidence is quiet. It comes from knowing that even if the first idea fails, you still have a method.
The best final review is not glamorous. It is a clear checklist, honest self-assessment, and disciplined practice on the exact actions the exam will demand. If you can enumerate cleanly, chain findings into attack paths, escalate with structure, and manage your time without falling apart, you are not just “hoping” you are ready. You have evidence that you are.
