I wasn’t sure what to say at the beginning, but if you’ve started searching for OSCP experience write-ups, you probably already know something about OSCP. Here are a few official pages with the requirements, in case you’re interested.

Introduction to OSCP+: https://help.offsec.com/hc/en-us/articles/29840452210580-Changes-to-the-OSCP

Introduction to the exam changes: https://help.offsec.com/hc/en-us/articles/29865898402836-OSCP-Exam-Changes

OSCP report requirements (just take a look; most people use the project below): https://help.offsec.com/hc/en-us/articles/360046787731-PEN-200-Reporting-Requirements

Report project: https://github.com/noraj/OSCP-Exam-Report-Template-Markdown The template I used: OSCP-exam-report-template_OS_v2.md

Exam guide (if you’re going to take the exam, you absolutely must read this): https://help.offsec.com/hc/en-us/articles/360040165632-OSCP-Exam-Guide-Newly-Updated

Those are the official requirements. Keep in mind that the exam guide may be updated, so you must find the latest version; it contains all the requirements. I’ll put my certificates here too. I’ve blurred my name and the QR codes because I don’t want to reveal my name for now, so only my OSID is visible. (I don’t know what went wrong with the built-in CDN. The images used http and were forcibly redirected to https. After I fixed that, they stopped using https, but I still couldn’t load the images from the source. The strange part is that the images were also inaccessible normally. On PC, just click the blank area where the image should be; I added a hyperlink. They load normally on mobile.)

The blog below helped me enormously while I was learning. I’m not particularly good with domain environments, and this blog summarizes many domain penetration techniques. You can work through them one by one: see what the first item covers, build an environment, find a dedicated tutorial, and reproduce it. The blog is like a directory that also includes exploitation methods for each vulnerability. It was incredibly helpful to me. Many thanks to 0r@nge. https://0range-x.github.io/2022/01/26/Domain-penetration_one-stop/

Let me talk about my learning journey. Back in 2022, I was doing an internship and wanted to earn a certification. I looked around, but none of the options seemed especially valuable. Then, by chance, I learned about OSCP and made it my goal. Most of the labs I worked through were from VulnHub, though, and my practice was very on-and-off. I kept doing VulnHub labs intermittently from 2022 into 2023, and I also touched a few during the first half of 2024. I didn’t truly commit until the National Day holiday in 2024. HW had ended a month earlier. Most of what I had studied and done was security-service work, limited to blue teaming and penetration testing. My red-team experience had never reached the provincial level. I had met many people, most of whom were at the provincial level but not the guo level (after all, someone who genuinely had gh-level skills probably wouldn’t come do blue-team work). I was then a senior about to graduate, and I could look for an internship in the first half of 2025. I thought about it for a long time, decided to take the OSCP, and then planned to find a red-team internship in the kind of role that interested me.

First, I’ll summarize what I think of VulnHub, Hack The Box, and the OSCP Challenge Labs. Most of the machines came from TJ NULL’s recommendations in the spreadsheet below: https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8/edit?gid=530535513#gid=530535513

VulnHub leans heavily toward CTFs—to me, its machines practically are CTF challenges. Information may be hidden in source code, and instead of looking like a normal webpage, a page might resemble a pure CTF decryption puzzle. Some port-knocking techniques aren’t represented at all in HTB or OSCP, yet I remember seeing them often on VulnHub. If you don’t want to spend money but still want to practice on labs, I highly recommend it. Although it is very CTF-oriented and has only Linux machines, it can teach you many Linux services and commands as well as conventional penetration-testing techniques. You encounter things like UDP, FTP, NFS, SMB, and plenty more. Its advantages are that it strengthens your fundamentals, exposes you to many Linux services relevant to penetration testing, and is free. Its disadvantages are the excessive CTF focus, the need to download and set up the machines yourself, and the fact that it only has Linux machines. (I even bought a 1 TB portable hard drive solely to download VulnHub machines.)

Hack The Box has very few CTF elements. For example, when an author builds a machine around a particular vulnerability, they obviously need to devise an attack chain and make sure its logic holds together. At some point, that chain may require credentials or similar information, and this is where a CTF-like element may appear: its purpose is to make you obtain a key piece of information before you can move on. Of course, situations like this are extremely rare. HTB is excellent. Most of its machines are designed around a particular vulnerability or exploitation chain, with the goal of teaching you that method. It may look a little like simple reproduction, but the path is made of interlocking layers. Every step follows logically from the last, and the design is wonderfully clever. Sometimes it even involves low-level logic; only after reading a WP and understanding it do you realize just how interesting the design is. The advantage is that the machines are extremely well designed, so approaching them with the goal of learning is very rewarding and gives you a strong grasp of the underlying logic of certain services. The disadvantage is that it costs money. Many people also say it is harder than OSCP, while others say it works well as an OSCP supplement. I agree more with the latter view.

I never practiced on PG, but I’ll still share my impression. Before the exam, I specifically found a WP for a PG domain machine in TJ NULL’s list and read through it. Compared with HTB, it was even more ingenious, which fits OSCP’s long-standing idea of “try harder.” As I said above, HTB mainly focuses on one vulnerability or one exploitation chain. The PG domain machine I read about was more about layers of underlying logic fitting together, plus a small amount of vulnerability reproduction. Each part made sense, but it demanded broader thinking. That is completely different from HTB: HTB often asks you to dig stubbornly into one point, while PG is more about divergent thinking—if you’re sure there is no vulnerability here, hurry up and look somewhere else.

The OSCP Challenge Labs feel more like real penetration-testing environments. There isn’t one specific vulnerability; instead, each is a collection of machines. Every challenge tells you that a company has hired us to perform a penetration test, and you have to face all of that company’s servers. The goal is to simulate a real environment. Overall, though, they are fine and not especially difficult. Skylark is the harder one, and many people choose to skip it, but I worked through the labs in order. There are no WPs for the Challenge Labs; students and teachers on Discord will only give you some hints. Although the earlier labs, such as Medtech and Relia, aren’t actually difficult, I was stuck for a long time when transitioning from HTB. As I said above, HTB and PG require completely different ways of thinking, and the Challenge Labs also demand a completely different mindset from HTB. Medtech and Relia were mostly about changing my thinking and not limiting myself. I chose to finish Skylark because it would help me adapt to that mindset—treating it like a real environment. In the end, with help from classmates and teachers, I completed most of the labs.

The final two are outside the exam scope. They are mainly labs for people preparing for OSCE³, but you can give them a try.

That was my learning journey. Most of the machines I practiced on were Linux, while OSCP focuses more on Windows, so I recommend making Windows your priority. It took exactly one month from registering for OSCP to receiving the certificate—31 days, to be precise. I registered on December 11, spent about 21 days completing seven Challenge Labs (finishing on January 1), booked the exam for noon on January 8, submitted my report at 3 a.m. on January 10, and received the certificate on the afternoon of January 11. During the six days from 1.1 to 1.8, I spent most of my time playing games. Games only feel fun when I have something else I should be doing :). Of course, I wasn’t relaxing with games the entire time. I revisited every lab except Skylark and reproduced them all, then specifically looked for WPs of domain labs. Everyone knows the conventional approaches; I wanted to learn some different ways of thinking about domain penetration. (Unfortunately, I didn’t get to use them.)

Let me briefly talk about some of the things I encountered during the exam, because this part really was interesting. I ultimately had only 70 points. There are no bonus points now, so the domain environment foothold plus three standalone machines gave me 70 points in total, and I scraped through the exam. The domain-controller section is no longer the same as OSCP A-C, which is worth noting. If you’ve completed OSCP A-C, you should understand what I mean after reading this. Normally, obtaining the domain foothold is very difficult. Once you gain access to the first machine at the domain entry point, however, the second host inside the domain is very easy. You don’t even need to escalate privileges on that second host before taking the domain controller. The route is: domain foothold -> low-privileged access to an internal domain host -> domain controller. The difficulty is concentrated in obtaining the domain foothold. The new exam moves that difficulty further down the chain. Getting the domain foothold is extremely, extremely, extremely, extremely, extremely easy—you can think of it as ten free points. They give you a way into the domain, but then the internal domain host becomes extremely difficult. You’re also given a low-privileged account, and all you need to do is escalate privileges. I had the sense that once I escalated, reaching the domain controller would not be especially hard. The problem was the privilege escalation, and that deserves a paragraph of its own.

When I worked through OSCP A-C, ordinary direct scanning caused no problems. In a domain environment, though, as soon as I used ligolo-ng to build a tunnel (chisel was even worse) and scan the internal network, I got a pile of errors.

It was utterly despairing. The moment I ran an nmap scan, it threw errors. I wrote OffSec many emails, and they worked with me, but we simply couldn’t fix it. The nmap results were completely inaccurate and led me to make wrong judgments. I even installed nmap on the domain foothold machine, but it still couldn’t find anything. All I could do was search by intuition. I knew the normal ports in a domain environment, but if a service was on a nonstandard port, it was simply game over. On top of that, the tunnel crashed easily, which was the most painful part. I had not noticed any problem with ligolo-ng on Medtech or Relia. Perhaps it was because I changed networks while working through OSCP A-C. There was nothing I could do about that, and I couldn’t switch back. The new connection was extremely fast at 60MB/S, but the problem remained. This may be where chisel comes in (frp, ew, and lcx don’t work, so don’t bother trying). The curious difference is that ligolo-ng sends everything in one burst and then errors out, while chisel sends according to the available rate, staying under the limit. Imagine a water pipe: ligolo-ng throws an entire basin of water at it, and however much enters the pipe is all you get; it doesn’t care about the rest. chisel slowly pours the water in as fast as possible without spilling any. With chisel, an nmap scan took 5-6 hours to finish. By then, I had already realized something was wrong. I was using Ethernet at 60MB/s, and the connection was very stable with extremely low latency, but there was still a problem. It was basically black magic. If you run into the same issue, switch networks as quickly as you can.

Back to the main subject: the domain environment I failed to take down. The network problems above were a major reason. I gambled wrong; I didn’t expect the exam VPN to behave almost exactly like the regular environment. After entering through the domain foothold, you’re given some information about the next internal domain host, which lets you access it. I encountered the jxxxxs service, and my experience felt very similar to this person’s: https://blog.restkhz.com/post/before-oscp-exam If you’re interested, take a look at that blog. It was precisely because of this post that I reviewed vulnerabilities involving jxxxxs. I could almost say that I understood the vulnerability-exploitation side and some of the standard approaches. (If you’re interested, try the Object box on HTB.) There was no privilege-escalation path on that internal domain host, and only this service was listening locally. I had two ideas. The first was jxxxxs-cli.jar. Unfortunately, anonymous access was disabled, and I knew the version. At first glance, that version appeared vulnerable to arbitrary file read. If I could reach the backend, I would be 100% certain of getting a shell, and that shell would most likely have the privileges I wanted. Although the installed version number looked lower than the vulnerable version, I put both version numbers into Google (one vulnerable version and the version on the target). Only then did I discover that the vendor had published an advisory for the vulnerable release in January 2024, while the version on the target had been released in May 2024. It was not vulnerable! I had spent half a day on it for nothing. That brought me to my second idea: find credentials for any account at all. If I could access the backend, I would undoubtedly be able to get a shell. I tried for a long time but couldn’t find a password. The jxxxxs directory couldn’t be entered, and there was no other information. I’m sure I tried most of the available methods. As I mentioned, the service listened locally. I had to use ligolo-ng to reach this domain member host, then use chisel to forward that host’s port to the domain foothold before I could access it. The tunnel was still terribly unstable, just as I described above. It kept crashing—three times in a single hour. The fix was to restart the target, upload ligolo-ng and chisel again, and rebuild the tunnel. It was agonizing. Getting the domain foothold took less than 30 minutes, but I then spent more than nine hours trying to escalate privileges. I’m certain I was only one username and password away. I never found them, and the repeated tunnel failures drained every bit of my energy.

Afterward, I thought it over. I hadn’t tried brute-forcing the application’s directories (the connection was far too slow to brute-force anything). Some credentials might have been hidden in files. Near the end, I discovered that a Jxxxx_history file was actually accessible, but I had no permission to access other users’ directories, and the current user’s history contained nothing else. Perhaps that was a hint to use dir /S across every directory to find this history file. At that point, the exam had five hours left and I had been working continuously for 19 hours. I had no energy left.

Fortunately, network connections that didn’t involve a tunnel were unaffected. I’m better at Linux, but my exam set contained two Windows machines and one Linux machine. I got root on the Linux machine in two hours, and obtaining the initial shells on both Windows machines was also very easy. The difficult part was their unconventional privilege escalation, but fortunately, I solved it in the end. This is why, when discussing practice labs, I recommend doing more Windows and less Linux. I had done far too many Linux labs and too few Windows labs, while the exam emphasizes Windows.

That was my entire exam experience. I regret not taking the domain controller, but a good outcome is enough. After I finished my driving test, I once saw a line that said: the passing score is 90, and as long as you pass, stop worrying about the score. Once it’s over, you can even say you scored 101. You passed and earned the qualification, so don’t keep regretting it. I feel the same way. I can’t keep dwelling on past mistakes. I’ve already earned the right to get on the road; how much I improve from here depends on how well I drive. We always have to look forward.

On the night of the exam, with 13 hours remaining, I was already exhausted. I had only 30 points: the domain foothold and initial shells on two standalone Windows machines. I wanted to rest for a while, but I kept tossing and turning and thinking. I couldn’t sleep at all. I lay there for about an hour, and it felt endless. I wondered whether the entire journey—from when I first started working hard to staying away from home just before the New Year so I could prepare for this certification—had been worth it. Honestly, I even thought about giving up. I had spent most of the first 11 hours in the domain environment, and the tunnel kept crashing. It consumed all my energy. I even wanted to talk to the proctor and say, “Look, this tunnel simply won’t come up. I can’t take the next step at all!” I felt a little cursed for drawing a relatively difficult domain set. Snow was falling outside. I didn’t go out for food; I just forced down a few bites of bread I had bought earlier. After all that thinking, I realized I simply couldn’t sleep. Before continuing the exam, I thought about what I should do. First, I would try a few possibilities in the domain environment for no more than one hour. If they didn’t work, I would abandon it. If they did work and I took the domain controller, I would have 60 points in total, and taking the Linux machine would be enough. If I remained stuck in the domain environment, I would go straight after the Linux machine, then keep trying unconventional privilege-escalation approaches on the two Windows machines until the exam ended. Fortunately, my plan was right. I couldn’t make any further progress in the domain environment. I enumerated the initial Linux shell and tried both unconventional and conventional privilege escalation, then worked through the unconventional privilege escalation on the two Windows machines. I fully compromised all three standalone hosts. It was already 3 a.m. I was incredibly excited because I had reached the passing threshold, but I was also exhausted. Even so, I spent more than three additional hours reproducing and saving every step. That was the right decision: after I slept, my computer blue-screened and restarted. If I hadn’t saved everything and had instead waited until writing the report to retrieve it from Kali, I would have been unable to finish the report. It was wild. The blue-screen issue had existed for a long time and seemed to be related to the graphics driver. Kali had also restarted itself once while I was attempting the domain environment. So here’s another reminder: learn how to write the report in advance, and once you reach the passing threshold, remember to take a snapshot of Kali.

Finally, a few words about the official OSCP course. Once I learned there were no bonus points, I went through the whole thing and read all of the text. I got something out of it, but not much. It mostly covers the fundamentals, so it is worth a look.

I also want to talk about the value of OSCP. Before the exam, I saw many discussions in the r/oscp community on Reddit. Some people said OSCP deliberately prevents a fixed number of candidates from passing to protect its value, making it extremely difficult, and that some people who passed may simply have been lucky. Others said many employers first check whether someone holds OSCP and give preference to OSCP holders, even though they had also met many highly skilled people without OSCP. They thought that was unfair and considered it a marketing tactic. Some people said they currently had no plan to take the exam but had learned a great deal from the course. Others mentioned needing 2-4 attempts to pass. What I want to say is that OSCP proves a floor for your ability. If you pass the OSCP exam, then however weak you may otherwise be, you still meet the OSCP standard: you can independently complete a penetration test and write a report, and you can allocate limited time sensibly to achieve your goal. It raises your floor. When you perform a penetration test for someone else, they have no idea what you can do. All you can tell them is how many penetration tests you’ve performed, how many CVEs you’ve found, and how many years you’ve worked in the field. But when you say you have OSCP, they already know that, at the very least, you can complete a penetration test. Your ceiling, of course, depends on you. That is why I believe OSCP carries so much weight.