PenTest+ gives you a solid base in penetration testing concepts, tools, and workflow. OSCP+ asks for something different. It expects you to work through messy, unfamiliar systems with limited guidance, make good decisions under pressure, and document your work clearly enough that someone else can verify it. That is the real skill gap. It is not just “more advanced hacking.” It is the shift from knowing what a technique is to knowing when to use it, how to adapt it, and how to keep moving when the first five ideas fail. This guide breaks that gap into a practical checklist and a 30-day bridge plan you can actually follow.
What changes when you move from PenTest+ to OSCP+
PenTest+ usually rewards broad knowledge. You need to understand scanning, vulnerabilities, web testing, cloud basics, reporting, and compliance. OSCP+ rewards applied depth. You are given a target, and you need to find a path in with the tools and techniques you know. That changes how you should prepare.
Here is the simplest way to think about it:
PenTest+: “Do you understand the process and the common techniques?”
OSCP+: “Can you execute that process on real targets when the path is unclear?”
This matters because many candidates overestimate readiness. They know what Kerberoasting is, what SQL injection looks like, and what a reverse shell does. But they lose time in the areas that OSCP+ cares about most:
Missed enumeration
Poor note-taking
Weak Linux and Windows command-line comfort
Fragile privilege escalation habits
Over-reliance on one tool or one exploit path
If you want a fast test of your current level, try a focused OSCP+ practice test. It helps expose where your process breaks down, especially in enumeration and reporting.
The skill gap checklist
Use this as a hands-on readiness checklist. If several items feel shaky, that is normal. The goal is to identify the gaps before they cost you hours.
You can enumerate without guessing. You should be able to scan TCP ports, verify services manually, inspect web apps, review source code, enumerate SMB, test authentication, and pivot based on what you find. Good candidates do not run one scanner and wait. They confirm results and branch out.
You know basic Linux privilege escalation from memory. This includes SUID binaries, writable paths, cron jobs, weak file permissions, service misconfigurations, credential reuse, and kernel exploit checks. The point is not memorizing every exploit. It is knowing what to look for first.
You know basic Windows privilege escalation from memory. You should be comfortable checking services, unquoted service paths, weak permissions, scheduled tasks, token privileges, stored credentials, AlwaysInstallElevated, and local group memberships. Again, the habit matters more than the trick.
You can get a stable shell and improve it. Many people get initial access and then waste time in a weak shell. You should know common reverse shell methods, how to upgrade a shell on Linux, how to transfer files, and how to maintain access long enough to enumerate properly.
You can move between web, network, and local testing smoothly. OSCP+ targets often require switching modes. A web bug may give credentials. Those credentials may unlock SMB. SMB access may reveal a config file. That file may lead to privilege escalation. You need to follow the chain.
You can troubleshoot calmly. A failed exploit does not always mean a dead end. Maybe the version is wrong. Maybe the architecture is different. Maybe the service is filtered. Maybe your shell is unstable. Good testers check assumptions before changing direction.
You take notes that another person could replay. This is not optional. You need timestamps, commands, output snippets, screenshots where needed, credentials found, file paths, hashes, and proof steps. Bad notes turn a successful compromise into a weak report.
You can manage time on a box. If enumeration shows nothing useful after a reasonable period, you need a reset process: review open ports, revisit web content discovery, test found credentials across services, inspect hidden files, and verify assumptions. Time discipline is part of the exam skill set.
Hands-on prerequisites before you start the bridge
Before you begin a 30-day push, make sure your base setup is ready. This sounds boring, but it removes friction. Friction kills practice quality.
A working lab machine. Your VM or host should have your core tools installed and tested. Do not spend training time fixing Python package issues or terminal problems.
A notes system you will actually use. Pick one place for everything. Keep sections for scans, credentials, findings, proof, and report material. If your notes are split across text files, screenshots folders, and browser tabs, you will lose details.
Command-line comfort. You should be able to navigate Linux quickly, search files, inspect processes, check permissions, transfer files, and use common networking tools without looking up basics every few minutes.
A repeatable box methodology. Start with the same sequence every time: scan, verify, service-specific enumeration, web checks if present, credential testing, local enumeration, privilege escalation, cleanup, documentation. A repeatable process reduces panic.
Report templates. Create a simple template now with sections for objective, scope, methodology, findings, impact, evidence, and remediation. This prevents the common mistake of leaving reporting until the end.
Enumeration habits that close the gap fastest
If one habit makes the biggest difference between PenTest+ level and OSCP+ readiness, it is disciplined enumeration. Most failed box attempts are not caused by impossible exploits. They are caused by missing obvious clues.
Build these habits:
Never trust one tool alone. If a scanner says a service is open, connect to it manually. If a web scanner finds a path, open it yourself. Tool output is a lead, not proof.
Treat each port as a separate puzzle. FTP, SMB, HTTP, LDAP, SSH, RDP, WinRM, and databases all require different checks. Do not lump them together.
Look for relationships. Usernames on a website may match SMB users. A config file may contain database credentials. Database data may reveal password reuse. Enumeration gets powerful when you connect findings.
Write down dead ends too. If you tried anonymous SMB access, tested default creds, or checked a known path and failed, note it. This stops you from repeating work when tired.
Enumerate after every new level of access. Initial access is not the end of enumeration. It is the start of better enumeration. Once on the box, inspect services, configs, logs, scripts, and user history.
A simple example shows why this matters. Imagine you find a web app with a login page and SMB open. A surface-level approach is to brute-force the login and stall out. A better approach is to enumerate SMB shares, pull a config backup, recover a hardcoded password, test it on the web app, and then try the same credential on WinRM or SSH. That is the OSCP+ mindset: follow evidence, not hope.
Documentation is not admin work. It is part of the attack process.
Many candidates treat note-taking as something they will clean up later. That usually fails. In OSCP+ style work, documentation helps you think clearly while you test.
Good notes should capture:
IP address and target name
Scan commands and key output
Discovered services and versions
Interesting files, directories, and endpoints
Credentials found and where they came from
Exploit attempts, including failures
Privilege escalation checks performed
Proof of access and proof of escalation
Why does this matter? Because documentation reduces rework. It also improves your decision-making. When your notes are clear, patterns become visible. You see that a username appeared in three places. You notice that a version mismatch explains a failed exploit. You remember exactly where a password was found. Good notes are not a report artifact. They are a live map of your attack path.
The 30-day bridge plan
This plan assumes you already know the basics from PenTest+ and want to build OSCP+ style habits quickly. The focus is not on reading more. It is on doing more, reviewing your process, and tightening weak spots.
Week 1: Build your workflow and fix obvious weak points
Set up your notes template and reporting template.
Create a standard enumeration checklist for network, web, Linux, and Windows.
Review common shell stabilization and file transfer methods.
Run 2 easy boxes with a strict methodology.
After each box, write a short report, even if the box was simple.
The goal this week is consistency. Do not judge success by how hard the boxes are. Judge it by whether you followed your process and captured clean notes.
Week 2: Focus on Linux and web-led attack paths
Run 3 boxes that involve Linux privilege escalation or web entry points.
Practice manual web testing, not just automated scans.
For each box, list three missed clues after completion.
Build a short personal checklist for Linux privilege escalation.
This week teaches an important lesson: many boxes are won by careful observation, not exotic exploitation. A writable script, reused password, exposed backup file, or vulnerable upload function is often enough if you notice it.
Week 3: Focus on Windows, credentials, and lateral thinking
Run 3 boxes that involve Windows enumeration or credential abuse.
Practice checking SMB, shares, policies, user lists, and remote management paths.
Build a short Windows privilege escalation checklist.
Write one full report with screenshots and reproducible steps.
Windows often exposes the value of patient enumeration. A candidate who only hunts for exploits misses the easier wins: weak permissions, saved creds, accessible shares, scripts with passwords, or bad service configs.
Week 4: Simulate exam pressure and refine decision-making
Run 3–4 boxes on a timer.
Set checkpoints: if no progress in 45–60 minutes, pause and review evidence.
Force yourself to document while solving, not after.
Complete one final self-review: enumeration, exploitation, escalation, notes, report quality.
This week is about control. You are training yourself not to spiral when a path fails. Timed practice reveals habits you do not notice in casual labs, such as rescanning too often, skipping manual verification, or jumping into exploitation before understanding the target.
How many boxes should you run each week?
A good target is 2 boxes in week 1, 3 in week 2, 3 in week 3, and 3 to 4 in week 4. That gives you roughly 11 to 12 focused box runs in a month. Quality matters more than volume. One box solved with clean notes, a report, and a review of missed clues is worth more than three rushed solves with no reflection.
Try to vary the box mix:
At least a few Linux targets
At least a few Windows targets
Several web-based entry points
A few credential-driven paths
This spread helps you avoid a common trap: feeling strong because you are good at one style of box.
Common mistakes during the PenTest+ to OSCP+ transition
Collecting resources instead of building process. More cheat sheets do not fix weak habits.
Using tools without understanding output. If you cannot explain why a result matters, slow down.
Skipping manual verification. This leads to false assumptions and wasted hours.
Ignoring reporting until the end. This creates gaps in evidence and missing steps.
Practicing only easy wins. You need some friction to improve troubleshooting and time control.
The reason these mistakes are so costly is simple: OSCP+ style testing rewards disciplined execution. Weak process compounds over time. A missed username early on can block the rest of the path.
Your 30-day gap checklist
Set up one note system and one report template
Create a standard enumeration checklist
Review Linux and Windows privilege escalation basics
Practice shell stabilization and file transfer
Run 11–12 boxes over 4 weeks
Write at least 4 short reports and 1 full report
Track missed clues after every box
Practice timed sessions in the final week
Test yourself with an OSCP+ style practice assessment
The bridge from PenTest+ to OSCP+ is not mainly about learning brand-new attacks. It is about building reliable habits under pressure: enumerate thoroughly, verify everything, document as you go, and adjust based on evidence. If you can do that for 30 days with intention, you will not just know more. You will work more like the kind of tester OSCP+ is designed to measure.
