More Lessons Learned About Passing the OSCP Exam

On February 11, 2020, Offensive Security introduced a major overhaul and update to their already fantastic course: Penetration Testing with Kali Linux. Those changes included updates to their lab environment.

The study materials were substantially updated, with additional material including entire new sections on Bash Scripting, Active Directory Attacks, and PowerShell Empire. The training videos and the labs themselves were also substantially updated with many more machines available to try and compromise.

The original OSCP study guide document is 380 pages, and the 2020 updates bring the total to 853. One benefit of previously failing the OSCP is that I was able to test out the new study materials and the new lab environment. I was also able to crack a few machines that previously escaped me, giving me bragging rights to some of the most challenging machines like Gh0st, Pain Sufferance, Humble, and 1nsider. The updates and study materials are very high quality with many gems I was able to add to my toolkit. The specifics about the 2020 updates are available on the Offensive Security site.

In my previous blog, my first point was that you do not need prerequisites for this course. I just want to reiterate this point, especially because my advice is different than just about everybody else’s in this respect. You will learn the skills you lack doing the course and working the labs far better and faster than even the best courses you will find online. That’s because these skills are gamified; you will actually enjoy learning them. Obviously, it doesn’t hurt to take any of these online courses, and having prior experience and knowledge is great, but don’t let not having these prerequisites hold you back. I say this as somebody who is a big fan of online courses. Prior to this course, I took classes on Python, Metasploit, Nmap, web penetration testing, as well as others. The course material is very well thought out and is there to take you from “zero” to “hero.”  The labs are where the actual learning happens, where you are putting these ideas into practice.

If you are entirely unfamiliar with the material (known affectionately as being a total noob), this is still a great course. Just don’t let failure stop you. With the right dedication and study, you will succeed. Having said that, let’s get on with a are few more gems I’ve picked up on this go-round that may help you.

When I began my studies, I made the mistake of using tools like tcpdump and Wireshark to debug and troubleshoot an exploit that wasn’t working or to just scratch my head staring at code while trying to figure out exactly what it was actually doing. Now, I run everything through Burp. I can view everything that is sent across the wire (and returned!), and I can easily edit any values before they are sent. This is a far easier process than sifting through Wireshark or tcpdump. I always recommend doing it even when your scripts are successful. It allows you to see exactly what is happening in real-time. It can also save you the time of editing code and even compiling code if just a small detail is wrong, like trying the same thing on a different TCP port.

Needle in a haystack

It is important to recognize the “needle in the haystack” problem. To clarify, I often made the mistake of looking at a lot of data, believing there were no needles to find. No signal in the noise. It could be a web scan that becomes overwhelming, a file share with numerous files or even an entire disk drive. When you first get low privilege access on a box and you begin privilege escalation scripts, you are in the midst of a classic needle in the haystack problem; you will get a laundry list of installed packages, running processes, SETUID files, and so on.

It takes some time to recognize what is normal and what seems out of place. I like to look at the date that packages were installed and the creation date of the SETUID files and other files. You can even search the entire file system for things close to the date of the user.txt file (the proof file that you gained user access). For example: find / -newermt 2019-05-15 ! -newermt 2019-05-19 -type f 2>/def/null (between May 15th and 29th, -type f is for files, pipe errors to dev null). This is just one example, but regardless of the tool you are using, try and figure out how you can reduce the noise.

Time management

Full TCP, UDP, and web directory scans take a very long time, and they are also the bare minimum of the scans you must perform. My advice is to run an initial and quick scan first on all machines: nmap -sC -sV -oN initial.txt then the full TCP, UDP, and web directory scans. Then work on the buffer overflow machine while these lengthy scans are running. “Do the buffer overflow machine first” is great advice, but always keep in mind the mantra of “always have recon running,” so don’t work on this machine at the expense of not having recon running.

The point being, always keep recon going until you know what the next steps are. I also practiced the buffer overflow the week before the OSCP exam, so it was fresh in my head. If you are well prepared and rehearsed for the buffer overflow machine, you can make fast work of it and have more time for the four other machines in your exam. Don’t make this machine take any longer than it needs to.

Privilege Escalation scripts

In addition to the suggested privilege escalation scripts in the training guides (Sherlock and PowerUP for Windows, LinEnum and Linux exploit suggester for Linux), I consider the Privilege Escalation Awesome Scripts (winPEAS and linPEAS) as a “must have” in your toolbox. These scripts do a whole laundry list of things the other scripts do not including enumerating recently touched files and too many other things to mention here. One thing I especially like about winPEAS is that they include the MITRE ATT&CK technique ID’s into the specific thing they are checking, clearly using MITRE ATT&CK to help them create these scripts. As somebody who has been working on developing MITRE ATT&CK content for Tripwire and admires the team and effort of MITRE, I truly appreciate this, and I hope to see it developed further. A

nother resource not mentioned in the training materials is GTFOBins. This is a fantastic resource. It isn’t just about getting root, but it’s also bypassing a variety of local security restrictions. It comes in especially handy if you find yourself in a restricted shell (rbash).

The report

When you have rooted a machine and have completed your happy root dance, take 10 to 15 minutes of your time to write a preliminary report before moving on to the next machine. I’m not talking about the word document and all the screenshots, but just the text portion of all the commands, exploits used, etc., that you will eventually need for your final report.

Have a checklist. Do you have the screenshots you need? The nmap output? The links to the exploits you used? The edits you made to those exploits? Do you need more screenshots? Did you forget the proof.txt file? It will be far easier to go through this process now than the next day when you must write your formal report. Many OSCP guides, including the formal course itself, recommend using a note-taking tool like cherrytree. Personally, I didn’t find these tools useful at all. I just needed a good text editor.

For me, the journey to OSCP was a very rewarding experience. I enjoy solving clever puzzles, and I actually enjoy hacking. I may be done with OSCP, but I’m still a member of Hack The Box, and I watch each and every video published by ippsec that demonstrates walkthroughs of retired boxes. It is an excellent teacher. I cannot recommend this enough.

It is no longer just about passing the OSCP exam; I’ve now adopted it as part of my overall lifestyle. I want to encourage anybody who has this interest to pursue this—even if, and especially if, you expect to fail. Good luck, and “Try Harder!”