This is the first in a series of posts about the OSCP certification and my journey to acquire it. This first post is mostly aimed at people who are interested in the course but haven't taken it themselves. If you are an alumni of the program, you might be more interested in later posts where I talk more about how I feel about the program and offer some constructive criticism of it.

Several years ago, I was trying to figure out what the best route into information security would be. I had a bunch of questions about what I would need to know, what I could leverage from what I already knew about systems administration, and how I could prove that I understood what I was doing.

During the course of my research, I happened across the website of Offensive Security and the Penetration Testing with Kali Linux course. The program sounded very thorough, intimidating, and tough. I knew just from reading it that I didn't have what it would take to pass it, but further research showed that it was the only practical-based course that was available to me.

The hands-on nature of the program was important. I come from a bench technician background and I've seen all sorts of certifications that didn't prove squat about the ability to actually fix anything. It takes detailed observation and methodical diagnostics to actually be able to solve a wide range of computer repair issues. This is very hard to "test for," especially with multiple choice exams.

Offensive Security's emphasis on lab work and an exam that says "okay, you've been practicing, go DO it" really appealed to me for that reason. To peers and managers in the know, it should prove competency in a way the 'Certified Ethical Hacker' or Security+ certs do not.

I spent two years pulling together the knowledge I thought that I would need at a minimum to pass the course and acquire my OSCP. I got comfortable with Linux by playing sysadmin and standing up web applications like Redmine, gitlab, roundcube email and others, and then maintaining them through updates and new versions.

I became comfortable with VMWare ESXi 5, and then Xenserver in order to host the CentOS boxes that hosted the sites.

Then I dove down a storage rabbit hole for months, and came out of it knowing how to use iSCSI, NFS, SMB, and ZFS to provide performant storage to my VMs.

The last stage was programming. I've found it difficult to learn good programming skills in "traditional" college curricula, but I found I worked well with the Learn Python the Hard Way course.

At last, I felt I was armed as well as I was ever going to be. I trusted that the course guide and material would carry me the rest of the way to success. I enrolled in June of 2015 for the 60 day option.

Course Overview

I won't dive into this too much, because OffSec's own pages cover it pretty well, as they make the course syllabus freely available. When you enroll, you choose a start date that is variable based on their current enrollment. Mine was 2 weeks after my registration, but I've seen users of the OffSec IRC channel have rather longer waiting periods as the course grows in popularity.

On your start date, you get an email with quite a lot of information in it. It includes how to connect to the lab (which you've already done as a pre-requisite to enrollment), your credentials for various services like a forum and VPN, a very large PDF with the course material, and an archive of videos to watch as you move through the course.

The PDF and videos have your student name and serial number burned into them. If you've wondered why you don't see easy-to-find leaks of these items, this is why. OffSec takes the course very seriously, and if you leak documents out, they will rescind your certification, or ability to continue in the course. Few people want to risk it, although documents are out there.

Getting Started

To move through the course, I followed this process.

  1. Watch the video for a given section
  2. Read the section in the PDF, moving along until I got to the questions at the end
  3. Do the work/solve the questions
  4. Go back to 1

That was it.

While I'll talk more extensively about this in the second post, I did not jump straight into the lab, and I didn't "peek" in the lab either. You do work with nmap during the course material, along with several other tools that interact with the lab. But I refrained from doing more than the PDF instructed or section questions implied.

I found the videos and PDF to be quite good. It was rare that I got confused about something or noted a discrepancy between the two that caused actual issues. The videos and PDF aren't a mirror of each other however. Some PDF sections cover a topic more completely than the video will, and you would do well to watch and read.

For me personally, it was good to see a technique performed, or a tool used, so that I could see how it should act. If I performed something incorrectly, I didn't have to wonder if there was a problem with a tool (usually...), but rather could focus on what I had done wrong.

The Labs

The PWK course is most well-known for the virtual lab you have access to. There are 50-ish machines (depending on whether you want to count in-scope-but-never-the-less-not-hacking-targets like routers), some of which aren't accessible directly. You have access to a network control panel which allows you to reset a given computer's VM in order to set it to a known-good state.

This is really important, because you aren't alone in the labs and others may be working on hacking the same computers you are. This activity can leave a host in an unstable state. Worse, some students don't practice good "hygiene" and leave exploit binaries lying around, or open firewall ports to vulnerable code that wouldn't normally be exposed. At best this just wastes time, at worst it can "give away" the actual killchain and spoil the host's ability to teach.

There are files on each host ("proof.txt") that contain an MD5 hash that is unique to that host. They act as evidence that you gained administrative access to that host. Some hosts are multi-homed and thus will also have a "network-secrets.txt" file with another MD5 hash. This hash, when entered into your control panel, will allow you revert access to whatever network that machine was a part of.

This process isn't flawless. There were a couple of instances in the lab where I found a multi-homed machine that nonetheless did not contain the secrets file. It would seem that there are certain hosts OffSec assumes you will breach first and the tokens are on those computers. This got in my way as I seemed to take a less obvious route into one network and couldn't revert machines because of it.

You will find Linux, FreeBSD, Windows client OSes and Windows Server OSes of various versions on lab hosts. The lab has been updated since I took the course, but at the time the newest Windows machine I encountered was Windows 8.1. Windows 10 released right at the beginning of my course, so it not being in the labs was pretty understandable. I was a little surprised to not see any Windows Server 2012/R2 machines.

The lab has a certain notion of being part of a pretend corporate network. You'll find references to the same core group of users and admins, email domains and addresses, etc. The simulation is mostly skin deep; there is little in the way of a pervasive corporate simulation going on, and that's fine. It's largely immaterial to the work you're doing, and a deeper simulation would be an awful thing to have to automate. That being said, it's a little disappointing that your ability to practice lateral movement is limited to a certain core of Windows machines.

The machines are designed to mimic real-world configurations that OffSec has seen on actual penetration tests. Their purpose is to be forgiving targets for your tools and techniques as you get used to being a penetration tester. With one notable exception, they don't react to being scanned, and you aren't really penalized for being "noisy" on the network. This is probably for the best, but doesn't let you practice being stealthy.

As I got more used to the tools and techniques, I found myself using fewer and fewer of the daily "reverts" you get for resetting VMs in your control panel. I made fewer setup mistakes, made fewer wrong assumptions, and overall just got better at the process of breaching hosts. I emphasized understanding what I had done, taking good notes and trying not to despair if I just wasn't getting somewhere with a given machine.

At the beginning of my lab time, approximately 25 days after starting the course, I was averaging less than a host a day. It was pretty brutal. However, after another 7-10 days I was getting the hang of the tools and techniques and my breach rate was accelerating. By the last day, I was doing 3-4 a day.

I didn't breach all of the hosts. There are some that I just ran out of time to do, and others where I just never enumerated the right first step. Of the three "hero" machines, famous for their names and escalated challenge level, I got the first, 'pain.' I will say that if I was able to get any sort of code execution on a host, I invariably rooted it; the hosts I failed to breach were all instances of not getting even a first foothold on them.


As you do the questions and such in the PDF, you're recording them in some fashion because you're going to compile all of the work into a "lab" report. Here's what you need to know.

  • Your lab and coursework report is optional.

  • Your PDF exercises and your lab work reports can be separated.

The report isn't really 'graded.' Its thoroughness and correctness is taken into account in the event that your exam score is borderline (it takes 70/100 to pass). Thus, it can help your pass. If you are extremely confident in your ability to pass the exam with the required points, then honestly there's no need to compile and submit this. However, if you don't have enough points to pass, you simply won't have time to compile a meaningful, organized report, and you'll have doubled your pain. My advice? Do the report anyway.

Further, it was easier to break out my lab machines report into its own document. The coursework report is full of sections that have lengthy log output and disparate media like screenshots, code blocks, etc. It's also quite large in volume. If you've read elsewhere on the Internet "My lab report was 250 pages!" this is what they're talking about. The bulk made more sense to keep contained in its own document. My actual lab report was 107 pages (12k words), and the coursework document was 197 pages.

Remember to name and label your documents so that its easy for the person processing them to understand what you've submitted.

The Exam

The exam is the subject of a great deal of curiosity. What's it like? Did you feel prepared after the labs? What kind of machines are there?

I can't talk about the machines directly, because OffSec will get mad at me. So I'll talk around the machines instead...

There are several other blog posts around the web of people talking about their exam experiences. I think the one that matched up most closely with my own was Mike Czumak's here. I did a lot of prep beforehand, had 90/100 points by about 9 hours, and chose to finish up instead of pushing for the last 10 points. Some of his scripts linked above are extremely useful as-is, and building upon them in your own time is a worthy endeavor.

The exam, in my opinion, was a closer match for the PDF material rather than the lab machines. If you are competent with all material covered in the coursework, like buffer overflow exploit modification, password attacks, probing and exploiting poorly designed web applications and such, you'll be fine. Bearing in mind that I didn't have time to attack Sufferance or Humble, I never encountered a point where I had to modify public exploit code to breach a lab machine. Password attacks got me nowhere. Web applications are all over the place in the labs though, and I feel like that was well-represented, but manually probing them? Not so much.

Overall yes, I did feel prepared for the exam, but more-so by the coursework and not the labs. The labs are there for practice, and to get you in the habit of doing research and fussing with things when they don't work than a "this is exactly how the exam will be."

I'll go more into exam prep in the third post in this series where I talk about tools tactics and procedures (TTP).


Having passed the OSCP challenge was a fantastic event for me, and definitely qualified as one of the hardest things I've ever done. Part of why I'm writing this series is to encourage others to take the course. It is great for earning foundational knowledge that you'll need in a career on the pioneering edge of penetration testing, not just running Nessus and calling it a day.

Part 2 will talk about my thoughts and criticisms of the course (no, it isn't perfect) and addressing some tribal knowledge I take some issue with.

Part 3 will talk about the 'how' of what I did in the labs, and some general tips. No, it will not tell you how to breach a given machine.

Thanks for reading.