Thoughts on the OSCP exam

There are hundreds perhaps even thousands of articles out there about how to prepare for and pass the OSCP exam. I am not sure how helpful it is to share “my OSCP journey” types of posts at this point because after reading many of them and talking to my friends and colleagues who have received this certification (or at least tried) and then completing it myself, the one thing that has become clear to me is this: Everyone’s way of preparing for and passing the OSCP exam is unique. Everyone’s strengths and weaknesses differ.

I could tell you how many machines I knocked off on in the labs or on TJ_Null’s list of OSCP-like boxes, but I won’t. I’ve seen posts from people claiming to have done every machine without any hints saying they failed the exam multiple times. I’ve seen posts from people who claim to have barely prepared saying they passed easily on the first try. There’s no guarantee that what worked for me will work for you, so I’m not sure how much specific details about that type of preparation actually help.

But I can at least offer a few words of advice and wisdom, while trying not to just re-hash information you’ve already read.

Pre-Exam

1. Do the exercises and lab report if you can.

   Yes, it takes a lot of time. But it’s 10 points under the current exam format. It could easily be the difference between passing and not passing. If you are unable to complete the Active Directory chain in the exam, your only path to passing requires the lab report.

   Also … you might learn some new tricks. I certainly did.

2. At the very least read through the PEN-200 course material and/or watch the videos.

   If PEN-200 is a university course with the OSCP exam as the final exam, then the course material is the textbook and anything from the textbook is fair game on the exam (though keep in mind that the exam is not restricted to what is in the course material and lab). If you do NOTHING else, peruse the table of contents. Read through any chapters that you are not familiar with and do those exercises.

3. Build a “cheat sheet” (it’s not cheating!)

   As you work through the exercises, the lab machines and anything else you do, compile a cheat sheet of any commands or techniques that you use. You’re not expected to do everything from memory, so why try to remember lengthy commands to forward a port, transfer a file or build a payload in msfvenom if you don’t have to? Instead you can copy commands from your cheat sheet into your exam notes. Then make any necessary tweaks and then paste the final command into your VM to execute. It saves quite a bit of typing and helps cut down on getting tripped up by typos.

4. Get a good process in place for taking notes/screenshots

   Personally I do all of my notes in markdown format in Visual Studio Code. The Paste Image extension allows me to take a screenshot of my work and paste it into my notes using keyboard shortcuts. The extension takes care of putting the file into the folder alongside the notes and adding the markdown link to it. It’s a good idea to label your pictures in your notes because the filenames will be date/time based and you don’t want to have to go sifting through dozens of screen shots trying to find the one you want when it comes time to write your report. I also use a spell check extension to try to keep typos out of the final report.

5. Write your report as you go

   If you wait until an attack succeeds before you start writing down steps and taking screen shots, you might miss something and have to spend precious time re-creating your attack. Or worse, you might not remember exactly what you did and then you have to retrace your steps until you figure it out again.

   Instead…when you start an attack, record your steps and take screen shots as you go. If the attack does not succeed then just make a note of that and move on to the next idea. This also helps you keep track of things you already tried.

   When the attack succeeds, you’ve already got everything you need for your report.

6. Turn your markdown notes into a sharp PDF report

   There are some good tutorials out there (like this) for converting markdown notes directly to PDF. Trying to layout mixed graphics/text in Word or LibreOffice is never pleasant. Why make this process more painful than necessary?

   The tutorial I linked above nicely builds the PDF report and helps ensure you get the file names and 7zip archive set up according to the requirements from OffSec. It will even pull in a lab report PDF and bundle that correctly. What it does not do, however, is generate the lab report. So I ended up installing pandoc and texlive directly on my Mac using homebrew along with the Eisvogel Template. This allowed me to generate the lab report from my markdown notes in advance. It also allowed me to make some tweaks to the template. For example this tip for adding a background color to inline code blocks makes them much more readable.

   A couple other tips for using this technique:

   • Backslashes must be escaped or in code blocks. Otherwise pandoc thinks they are invalid raw LaTeX instructions and errors out. You’re likely to get caught up by Windows file paths and shellcode sequences. If you get an Undefined control sequence error, start searching for loose backslashes.
   • Fenced code blocks and images must have a blank line before and after in order to lay out correctly.
   • Both fenced and in-line code blocks are subject to spilling past the edge of the page if they are too long, so inspect your PDF carefully. If an in-line code block spills over you can put it on its own line with a blank line before and after. If it still does not fit, change it to a fenced code block. If a fenced code block spills over, you’ll need to break up the long line with spaces to get it to wrap.
   • Fenced code blocks must have a syntax declared after the opening fence in order to render correctly:

    ```python
    <Code goes here>
    ```
   

   If you don’t want any specific syntax highlighting in the block, use default or plaintext.

7. Prepare your report in advance

   A few weeks before your exam date, get your template in order. Pre-set any necessary dates, your OSID, etc. Make any tweaks necessary to the boilerplate in the intro. You might consider using a machine template to organize your notes during the exam (I used a modified version of the one here), so get that ready to go as well. Do a couple of dry runs so that you know exactly how to generate the report and that it looks the way you want it.

   If you’re not using the ruby script linked in step 6 above, once you figure out your pandoc command and your 7z command to zip your files, drop those commands right into that cheat sheet from step 1; after your exam you can just grab those commands and you’re ready to drop the report.

   Finally, have a folder ready on your computer with your templates ready to go so you can get right to work.

   You might burn a few hours on this, but if you do this preparation ahead of time, your report generation will be fast and easy. You’ll thank yourself when you’re tired and bleary eyed editing your report the day after your exam.

8. Taper

   The exam is a lot like running a long distance race. Athletes taper leading up to a big race to allow themselves to recover from the fatigue of training the weeks and months before. I can’t tell you exactly how to do this … you have to decide for yourself.

   What I did was slow down my practice quite a bit starting about 2 weeks out. I did no more than one practice machine a day. I also saved one of the AD chains in the lab to do about a week before the exam just so I would have some fresh practice on that side of things.

   

   And … I played some of The Witness again. You’re probably scratching your head at this, but if you know this game, stop and think about how The Witness relates to hacking, or at least the enumeration part of it. Before you can even try to hack a system, you have to understand what it’s supposed to do, how it works, what rules control its behaviors. You often do not get clear documentation and you’re left to figure these things out through experimentation and observation of how the system reacts to the inputs you send it.

   That’s The Witness right there. That’s the whole game. It’s a massive collection of puzzles that can only be solved by learning their rules through experimentation and observation. As an added twist that is perfect for stretching your hacker brain, some of the puzzles are broken - physically damaged in some subtle or not-so-subtle way. The only way through these puzzles is to figure out how they are broken and use that knowledge to deduce what the solution would be if the puzzle were undamaged.

   Put simply, I can think of no better way to keep that hacker mindset sharp in a relaxed and casual way than by playing The Witness, so I spent an hour or so daily playing it starting about 2 weeks before my exam date.

Exam Day

1. Eat and drink

   Have some healthy-ish snacks at the ready, and plenty of water. Plan your meals and do not skip them. Aim for foods that will not make you feel heavy or tired. This is also not the time to deviate from your normal habits. If you normally drink 4 cans of Monster Energy daily then go for it, but if you never drink it, don’t start on the day of your exam.

   

2. Take frequent breaks

   You’re allowed to step away from your terminal at any time; just let the proctors know. I have a dog that I walk 4x daily so she was a convenient reminder to take breaks, but I took several breaks in addition. More or less anytime I felt my anxiety rising or scored a flag I would take 5-10 minutes to re-compose myself.

3. Have a plan

   Decide in advance when you will eat, when you will sleep. Set your limit for how long you’ll spend completely stuck on a box before you set it aside and try a different one. Think about whether you’ll tackle the AD chain first or one of the standalone boxes. You don’t have to adhere to a minute-by-minute schedule and of course you can adjust it as you go based on how things are going. But just having some idea of how you want to manage your time will help keep you grounded and less fatigued.

4. SLEEP

   If I made one tactical error on exam day, it was not getting enough sleep. I planned to sleep 6 hours from 1AM to 7AM. I have never been the type of person to pull all-nighters and I wasn’t about to pull one here. I picked up a new box around 11PM. This was actually good timing because my game plan was to not spend more than 2 hours on a box if I was not making progress. If I got stuck for two hours, it would be my planned sleep time anyway.

   Well, maybe it was because I was getting fatigued and not thinking clearly but after 2 hours at 1AM, I somehow felt like I was making progress, so I allowed myself another hour.

   At 2AM, I still somehow felt like I was making progress so I allowed myself yet another hour.

   At 3AM I finally conceded to myself that I had made little to no progress and went to bed.

   In retrospect I think having another 2 hours of sleep would have been more productive. I should have stuck to my plan.

5. Think: shells

   Most of my exam day tips are around the mental and physical part of this. Honestly, if you’re prepared on the skill/technical side of things, then the biggest hurdle that you have to overcome is your own self.

   But if there’s one exam taking strategy tip I can offer, it’s this…

   On a multiple choice test, you can improve your chances of getting the correct answer by eliminating the answer choices that you know cannot be correct. Of course if you care enough to have read this far, you likely know that the OSCP is a hands-on practical test. There are no multiple choice questions to winnow down. In fact the OSCP certification derives some of the respect that it garners from this very fact.

   But you can still bring some small amount of conventional test strategy to the OSCP exam.

   The OSCP Exam Guide is very specific about how you must obtain proof that you broke into the machine - which in early 2022 is that you must have an interactive shell on the target. Webshells don’t count. Exfiltrating the flag file doesn’t cut it. You have to either pop a shell or log in with credentials.

   Always keep this requirement at the top of your mind. As you consider possible attacks, think about how each attack would get you closer to that all important interactive shell. Defer any attack that does not move you in that direction. If an attack requires some pre-requisites (authentication, for example) and you have not yet satisfied that pre-requisite then you should either try a different attack first or focus on satisfying the pre-requisites.

   Regularly revisit what you know and think about what you need to find or do to get from there to a shell. This will help keep you from falling down time consuming rabbit holes.

Parting Words

I had a mantra on exam day, which I wrote down and kept on my desk. Here’s what it was:

Stay calm.
Enumerate EVERYTHING.
Start over.

Stay calm, because when I start getting panicky I get sloppy and make stupid mistakes. 23 hours and 45 minutes is a lot of time. There’s enough to pause, gather your wits, make sure you didn’t mistype something or make another silly mistake.

Enumerate EVERYTHING, because fundamentally the OSCP exam is about reviewing every possible angle of attack and figuring out which one will succeed. You know that every machine in your exam network is pwnable. You just have to be able to spot that loose thread that gets you through. It’s somewhere on the part of the system that’s accessible to you, but if you don’t look everywhere you might miss it.

Start over. Because sometimes what you have already seen distracts you from what you’re missing. If you are getting nowhere on a machine, grab a fresh template for your notes, revert the machine and start from the beginning with fresh eyes. With less than two hours left in my exam I started fresh on a box that had completely stumped me hours earlier. I saw something new that second time around. With less than an hour remaining I realized what I needed to do. I logged 10 more points with 17 minutes left on the clock, and that was entirely because I started over. I’ve heard it said that you will truly understand what it means to “Try Harder” when you take the exam and I can attest to that 100%.

Hopefully some of this information helps you prepare. I wish anyone taking the OSCP exam best of luck. It’s a difficult, but ultimately rewarding experience.