Trying Harder and Passing the OSCP: A Developer’s Perspective

In my line of work, I design and develop enterprise products in the information security and risk management domains. These products generally serve blue teams, and I’ve wanted for a while to get the red team perspective.

So last Fall, I put myself through a self-imposed boot camp: earning the OSCP (Offensive Security Certified Professional) certificate. This is a intermediate-level certificate geared towards penetration testers. Before taking the exam, students spend significant self-directed time (30 to 90 days) in a specially constructed lab environment honing their hacking skills. The exam itself is a 24-hour test in which students are dropped into a network and need to gain admin access to as many machines as possible.

Below is a summary of my journey, along with tips for aspiring students.

Pre-Lab Time

Like most developers, I’ve invested most of my experience learning certain programming languages, tools, and frameworks. As a generalist, I’ve worked in a variety of languages (Python, Java, JavaScript, C++, PHP, SQL, etc.) and in a variety of areas such as backend web services, UI, desktop agents, and mobile apps. The breadth of my experience turned out to be beneficial for the OSCP, especially for reading different types of source code and modifying different types of exploits.

Where I lacked experience is the type of work typically done by system, network, or security admins such as configuring, securing, and troubleshooting networks and operating systems. I also hadn’t done any sort of pen testing before.

In the month leading up to the start of lab time, I worked through some exercises at Over the Wire, specifically the Bandit, Natas, and Narnia war games. I found all of these exercises to be worthwhile. Of these, the Narnia series was the most useful for teaching the basics behind exploiting buffer overflows. Buffer overflows are a big part of the OSCP syllabus.

I also loaded up the Offensive Security Kali VM on VirtualBox and used it to explore some of the VMs available at VulnHub. Through this, I practiced the basics of port scanning and vulnerability scanning, finding an exploit in ExploitDb and launching an exploit to get privileged access. It was not easy though, and I resorted several times to reading VM walkthroughs available online.

Lab Time

I started out with the default 60 days of lab time. In the first month I went through about half of the course material and was able to root 30 boxes and breach all the different lab subnets (Admin, Dev, IT, Public). There were a lot of long nights, trial and error, and looking up tons of stuff on Google and Stack Overflow.

At the end of that first month, I realized that my approach was not sustainable. I was disorganized and inefficient, and I didn’t feel like my approach could scale to passing the exam, when I’d have to root multiple boxes over the course of a single day. I felt like I was throwing darts rather than trying things with purpose. In some cases, I was also resorting to using cheap exploits (e.g. Dirty Cow or Eternal Blue) to get root rather than exploiting the box the ‘right’ way.

I realized at that point that the goal of the course is not simply to capture the flags – it’s to develop a systematic methodology for how one operates. I decided to use a proper note-taking tool to keep track of my attack methodology, and to keep notes on the boxes as I worked on them. I settled on Cherrytree, and I highly recommend it. (The bulk of my exam report was actually a straight PDF export from Cherrytree.) And I added another 30 days of lab time so I wouldn’t feel rushed.

For every box I tackled from that point on, I asked myself if I could improve my methodology, and revised it accordingly. I also began scripting common enumeration steps and revising my scripts from box to box.

At the end of the 90 days of lab time, I had gotten through all the boxes except one, including the “Big Bosses”: sufferance, pain, humble, and gh0st. I had a pretty good of collection of scripts and a wealth of resources that were organized as part of a methodology. I had enough time to redo the boxes that I had covered in the first month, and I was able to prepare some exploit scripts from scratch for known vulnerabilities.

Tips for Lab time
  • Think upfront about your attack methodology, and adjust it from box to box.
  • Use a note-taking tool to organize your attack methodology and keep notes from box to box.
  • Avoid taking shortcuts, such as using Metasploit, becoming overly reliant on the Offsec forums for hints, or using cheap exploits. Why? Because none of this will work for the exam. You’ll only be able to use Metasploit on one exam box, and it’s highly unlikely that any exam machines will be vulnerable to a one-shot well-known exploit. Of course there are caveats to this – I did use Metasploit in order to learn how to use Metasploit, and when I got desperate enough I did lean on the Offsec forums for help. The point is to not turn these shortcuts into crutches.


I scheduled my exam for the middle of December, a couple of weeks after my lab time ended.

There were still a couple of areas I felt weak in, namely privilege escalation and pivoting techniques on Windows. Rather than extending my time in the Offsec Lab, I thought it’d be best to try something new. I signed up for a VIP account on Hack the Box and went after some of the low difficulty, non-CTF-focused Windows machines. I learned a lot from tackling a few of these machines and watching the accompanying walkthroughs by Ippsec. The experience gave me extra confidence in the Windows environment. As it turned out, most of my exam boxes happened to be Windows machines.

I also spent the time before the exam writing up the optional Lab Report, which can be submitted to get an extra 5 points for the exam. Although I didn’t end up submitting the Lab Report, I’m glad I did it as it expedited the process of preparing the actual exam report the day after the exam.

The Exam

My exam started at 8 a.m. and lasted til 1 a.m. the next day. In that time period I managed to root 4 of the 5 boxes, and I knew I had enough points to pass. I submitted my exam report the next day and heard back that I had passed from Offsec within a few days.

Exam Tips
  • Script as much as you can ahead of time. Efficiency is key. There is a well-known challenge that everyone knows will be on the test. I wrote up scripts for this challenge ahead of time and practiced using them. As a result, I was able to complete the challenge during the exam in about an hour. Scripting also lets you work on boxes in parallel. While I was investigating one box, I had enumeration scripts running on other boxes.
  • Enumerate, enumerate again, and enumerate some more. In developer terms: do breadth-first search first instead of a depth-first search. The exam boxes are intentionally set up with rabbit holes that can eat up valuable time. To some extent you have to explore the rabbit holes in order to rule them out, but before doing so, make sure you’ve enumerated as much as possible. From your enumeration you can identify possible paths of exploration and work systematically through them. If you feel like you’re going too far down a rabbit hole, you can back up and explore other paths.
  • Use your Metasploit life-line wisely. You can only use Metasploit on one box. Make sure it’s the right one. I had enumerated all the boxes pretty thoroughly before choosing the box I wanted to use Metasploit against.
  • Prepare to be stuck, and try harder! There were several times during the exam where I felt like i had tried everything. But these boxes are designed to be vulnerable and there’s always a path. In these moments, I stepped away from my computer, cleared my head, and tried to go back to first principles.


Getting my OSCP was a great learning experience, and I highly recommend it if you have the interest and time. Be prepared to work hard. Looking back, I can really appreciate the construction of the Offsec lab. Each machine was interesting in its own right and yielded unique insights.

As a developer, I’ve found the OSCP experience has altered the way I write code. I now think upfront, without even really trying, about how I would attack the very code I’m writing. It also has injected a healthy dose of fear in me about the state of software security in general.

And going back to my original premise, as a developer of security products specifically, I’ve found the OSCP has given me a much better understanding of what kinds of features to build and how to build these features in such a way that customers can better defend themselves against the very real and difficult problems they face.

Leave a Reply

Your email address will not be published.