How I Passed OSCP+

Tips, Tricks and Tactics for exam takers.

Look at the cybersecurity certifications roadmap. Most of those certifications are multiple-choice exams. OSCP is one of the few that is both widely recognized and genuinely hands-on: you pass by compromising real machines, not by picking answers. The exam is hard, passing it can be meaningful.

Timeline

I started PEN-200 in early October 2024 and passed OSCP+ on 15 July 2025, about 287 days start to finish. I finished the PEN-200 coursework by the end of 2024 and worked through the PWK challenge labs along the way (Secura, Medtech, Relia, OSCP-A, OSCP-B, OSCP-C). My first exam attempt was in March 2025, I scored 40 points (failed). I finished the AD set but could not crack the standalones. They were difficult enough that I still do not know if more time would have helped. After that, I focused on standalones and worked through 59 boxes from the Lainkusanagi OSCP-like list. I passed on the second attempt in mid-July 2025 with 70 points.

Before PEN-200 I had about five years in software engineering, roughly one of them security-focused but not as my main role. I had done some Hack The Box Academy modules and a handful of easy-to-medium Hack The Box machines shortly before starting PEN-200. I worked full-time throughout.

Observations from Two Attempts

The machines you get in the exam are a lottery. On my first attempt I finished the AD set in under six hours and thought I was close to passing, but the standalones were too hard for me at that point. On the second attempt the AD set took closer to ten hours and left me drained such that I thought I would need a third try, yet the standalones turned out more approachable and I solved them. Both attempts were OSCP+ specifically.
Pick one reliable tool per problem class and know it cold. During the exam you want to execute, not debug your setup or puzzle over unfamiliar output under time pressure. The same goes for everything around the exam: screenshots, the proctoring camera, your local environment. Confirm it all works before you start, ideally with automated setup checks. As an example, verify that file serving works (exam machines have no internet, so file transfer between them needs to be reliable), and that reverse and bind payloads land without your own firewall getting in the way.
Consistency matters more than intensity. Not every phase of preparation is fun. Taking planned breaks (even weekly ones) when your focus drops is more productive than grinding through diminishing returns. This certificate is about having fun, upskilling, and taking on a solid challenge.
Accept that you will struggle.

Preparation Strategy

I divided the preparation into three stages.

Stage 1: Know the material

The goal here is to understand the structure and approach, not to memorize commands. I built a base document covering general concepts, how a typical CTF engagement flows, and what the phases look like (service enumeration, initial access, etc.), filling it in chapter by chapter as I went through PEN-200. I used the broader frameworks (OWASP, NIST Cybersecurity Framework, MITRE ATT&CK, and D3FEND) for orientation, not deep study. The important techniques, like nmap for service enumeration, should not be skipped. By the end of the course I had a rough mental model of the whole process from initial scan to getting the flag, even without deep exploitation knowledge.

Stage 2: Build two working documents

I kept a writeups document and a personal cheatsheet, both as Google Docs. I chose Google Docs (against people’s recommendation), because I needed something portable, searchable with Ctrl+F, and without code-formatting overhead. For each Proving Grounds challenge I completed (leaving PG Practice for later), the cheatsheet got a short description and the commands I used. The writeups followed a fixed structure: Service Enumeration → Initial Access with Privilege Escalation → Post-Exploitation → References. I recorded only methods that actually worked. Writing down everything sounds thorough, but after fifty machines the document is too long to tell what methods you used, actually works.

Stage 3: Go wide

I moved to PG Practice and the Lainkusanagi list, rotating between one Linux machine, one Windows, one AD. The writeups kept the same structure. As the cheatsheet grew, I periodically merged repeating fragments, and consolidated the whole thing before the first exam attempt. In its final form the cheatsheet was organized by topic with commands underneath, and a short description where the procedure was non-trivial (for example, setting up ligolo-ng step by step).

Service Enumeration and Initial Access

This covers everything up to reaching the first flag, split into three categories.

Port scanning

I use nmap almost exclusively. It gives precise control over exactly what information comes back, which matters when most CTF machines only need you to find one viable entry point. You should be able to scan from any context: attacking machine or victim, Linux or Windows, any port type. The technique itself is straightforward, but do not skim over it.

Good sources: TCP and UDP port numbers for getting to know ports, an nmap cheatsheet, an nmap scripts reference, and PowerShell IPv4 Port Scanner as an alternative when nmap is not available.

Locating public exploits

For the initial foothold you rarely need to craft a sophisticated exploit. What matters more is knowing how to search efficiently and when to stop (it’s easy to spend too much time here). The most widely used exploit database is ExploitDB.

Per-port enumeration

After my first attempt I started organizing this per port or port set, following the structure from HackTricks. Under each port I had seen during preparation, I kept only techniques I had personally tested and verified. HackTricks covers a huge surface, but chasing exploitation paths unlikely to appear on the exam wastes preparation time. Focus on the fundamentals and the patterns that keep coming back.

Examples of other people’s approaches: 0xdf’s cheatsheets, kashz PG writeups, aditya-3 walkthroughs.

Privilege Escalation

I split this by operating system: Linux and Windows. You might encounter something unusual, but it is not common enough to prepare for alternatives specifically. For both, my starting point is always linpeas or winpeas. In my cheatsheet I highlight the things that are frequently actionable (for instance token and privilege abuse, services, processes) with the focus on reading and interpreting the output, not just running the tool.

Good cookbooks: Linux Privilege Escalation and Windows Local Privilege Escalation. Not everything covered there falls within OSCP scope.

Early on, I went through the full linpeas output section by section on one Linux machine, and the full winpeas output on one Windows machine, trying privilege escalation at each section even when nothing was exploitable. The point was to understand what each section covers, how complex the techniques are, and what tools exist. It took about two weeks, but after that I could read PEAS output much faster on every subsequent machine.

Depending on the OS and context, other tools come into play. In AD environments, Kerberos-related executables become relevant (see Active Directory attacks on PayloadsAllTheThings). My cheatsheet has sections that apply only under certain conditions (for instance tooling that makes sense once you have credentials from earlier phases), or when the current user is already in a privileged group.

Before the exam I also pre-wrote scripts for file and directory enumeration, as a fallback for when linpeas/winpeas turns up nothing interesting. On a few PG machines I ran into relevant files that the automated scanners missed.

One thing to keep in mind: the OSCP curriculum has a defined scope. Some methods you encounter during practice, especially on the AD side, belong to OSEP or other certifications. Staying within scope and being deliberate about what you prepare for is more efficient than trying to cover everything.

Post Exploitation

This is about operating in chained Active Directory environments, gathering information and moving laterally. The main tools are Bloodhound (with SharpHound for collection), plus supplementary scripts and methods from PayloadsAllTheThings Active Directory attacks. Bloodhound is the first thing I run after landing a user shell in a domain. Even a single user’s Kerberos ticket is enough for the graph to show what is reachable (see more Bloodhound queries).

One non-default tool I found extremely useful is ligolo-ng for port forwarding in AD chains. Its agent runs on the victim and connects back to a proxy on the attacker, where you manage the tunnels. It handles arbitrary forwarding scenarios from a single interface and gives a full TTY regardless of how deep into the DMZ you are. I found it more reliable and simpler than SSH tunneling.

AD can look intimidating, especially if you have never administered it in an organization (my background is primarily Linux). In practice, PEN-200 does not go extremely deep into AD: you need to know how to run the relevant tools and get what you need from their output. Mimikatz, for example, produces a huge amount of information, most of which I have never used.

My “Nothing Found”

At the end of each section in my cheatsheet I keep a “Nothing Found” reference. It’s a list of external sources (other writeups, cheatsheets, PayloadsAllTheThings, HackTricks, GTFOBins, revshells.com, and relevant GitHub repositories) for when everything I have prepared comes up empty.

Mindset

Treat the exam as a procedure: step after step, even when a single step takes ten hours.
Multiple attempts are normal. There is a cooldown period and a retake fee, but the cost is small compared to the preparation already invested. Very few candidates with a structured strategy, who have done most of the LK list and finished PEN-200 and the challenge labs, still fail after five or more attempts.
From at least two days before the exam, do nothing beyond checking your setup. It is not about how you prepare, it is about how you perform.
Even though the AD set is worth more points, prioritize standalones. PEN-200 and the challenge labs give reasonable AD coverage. Standalones are more variable and less predictable.
Keep your normal routine. If you normally sleep seven hours, sleep seven hours before the exam. Do not oversleep. Do not overprepare.
I chose McDonald’s for lunch and salmon with rice for dinner. McDonald’s food preparation is standardized enough to minimize the chance of digestive issues.
Do not talk about the exam beforehand. External pressure does not help. I also did not set rigid timers for machines, food, or breaks. Every exam is different, and a fixed schedule does not account for that.
After the AD set and initial standalone enumeration, I went for a walk around the building, partly to recover physically, partly to let a strategy for the remaining machines form. During the standalones I stayed aware of my own tunnel vision. When something was eating time without progress, another walk helped me reset.
Save screenshots for breakthroughs and flags. Most attempts during initial exploration will not work, and accumulating screenshots of failed paths just creates noise. Write down what you tried as bullet points instead.
If your goal is to pass, prioritize a complete report over maximizing your score. You get 24 hours for the exam and another 24 for the report. I aimed to have a near-complete report by the time the exam ended, because once it is over, the machines are gone.
Consider your personal circumstances. The exam requires sustained focus over 24 hours and is easier to approach when you have few outside responsibilities.