Where I come from, being a tryhard has a lot of negative connotations.
Over the summer, I had the pleasure of taking Offensive Security’s Pentesting with Kali (PWK) course. I tried, tried hard, tried even harder.
Are you ready?
The biggest question leading up to the start of my lab time was “am I ready for this?”. As a young professional who hasn’t even been out of college for a year, I had many doubts regarding my abilities as a penetration tester. I had done some CTFs, some Vulnhub VMs, but had never done a professional penetration test. As you would expect from a recent college graduate, a lot of my knowledge was purely theoretical. I knew how attacks worked, but had only performed a few basic attacks. When I first read about this course a few years ago in college, I thought “maybe I’ll be good enough to take the course in 5 years”. I signed up anyway, and I’m so glad I did!
Offensive Security’s only states the prerequisites as “a solid understanding of TCP/IP, networking and reasonable Linux skills”. Here are some of the topics you should be familiar with:
- You should be good with Linux and Windows command lines. I only got an RDP session with a few machines in the lab. The rest of the machines are interactive via a command line. If you understand these Linux (https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ ) and Windows (http://www.fuzzysecurity.com/tutorials/16.html ) commands, command structures, and command output, you are good (hint: you’re going to be using those two tutorials a lot)
- You should understand the uses, limitations, and differences between popular networking protocols. If know what ICMP does, the differences between TCP and UDP, the differences between the services on TCP port 139 and TCP port 445, you’re OK.
- You should understand the basic structure of packets. If the Wireshark interface is completely foreign to you, you might want to brush up on that.
- You should be able to write basic Bash scripts. If you can write a Bash script that accepts some command line arguments, run some other commands in a loop, use if statements, and parse output with cut/sed/awk/whatever, you’re good
- You should be able to read over Python/Perl/Ruby/C code and have a basic understanding of what it’s trying to do. I’m not saying you need to be able to understand every line of C code, but you should be able to understand what the code is attempting to do. Not every exploit will work unmodified, and the only way to know what’s wrong is to read and understand the code.
- You should be familiar with what a debugger is capable of. In the course, you will be using a debugger to observe how a program crashes, and manipulate that crash to achieve code execution via a simple buffer overflow. If you can follow these two tutorials, you’re golden (http://www.fuzzysecurity.com/tutorials/expDev/1.html http://www.fuzzysecurity.com/tutorials/expDev/2.html
Now obviously, you don’t need to be an expert in any of the above before you start the course. This is, after all, a training. It’s just helpful to have a solid foundation and not be playing catch-up while in the lab. See the syllabus for more detailed information on what is covered in the course https://www.offensive-security.com/documentation/penetration-testing-with-kali.pdf
If you’re unsure, I recommend either buying this book (https://www.nostarch.com/pentesting ) or going over this course (https://www.cybrary.it/course/advanced-penetration-testing/ ). A lot of the material here can be directly applied to the labs.
I think it would also be beneficial to go over Metasploit Unleased (https://www.offensive-security.com/metasploit-unleashed/) prior to your time in the lab.
I signed up for 90 days of lab time. This cost $1150, and included all the course material, and an exam attempt. Lab time starts on Saturdays, so plan your schedule accordingly. I received an email with all the course materials and my VPN connection pack.
Offensive Security provides a non-standard 32-bit Kali VM for the purpose of this course. They said a stock/custom Kali VM is not officially supported. From what I can tell, the only part of the course that absolutely requires the OffSec VM is the Linux buffer overflow section. After I completed the course material on buffer overflows, I moved to a standard 64-bit Kali VM and never had any issues. The reason I moved over was for compatibility issues with the VMware tools. A list of additional tools installed by OffSec on the course VM can be found on the forums, and it is trivial to compile 32-bit exploits on a 64-bit machine (-m32 for gcc)
Ultimately it’s up to you.
Remember to take a snapshot of your machine EVERY DAY. When something inevitably fails, you’ll be glad you did.
The course PDF was 376 pages. There are 148 videos, each ranging anywhere from 1 minute to 10 minutes. Although I was familiar with most of the concepts in the lab, it still took almost 2 weeks of full-time commitment (i.e. I didn’t go to work) to finish all content in the PDF and videos.
I recommend going through the videos and PDF side by side. Each video corresponds with a section in the PDF, and the material covered is not always the same. There might be some instructions in the video that aren’t in the PDF, or vice versa.
Make sure you start documenting the course exercises from the beginning if you plan on submitting this. Completing the course materials will give you up to 5 extra points on your exam score, and you’re definitely going to want this boost.
I started taking notes with Keepnote, but eventually moved over to Evernote. I had a stack of notebooks for each network, one notebook per host. Inside of each notebook, I would have a page for raw scans, a page for personal notes and observations, a page for my report, a page for different exploits I had already tried, a page for commands I already tried, etc. The idea was to not do any work twice. Evernote will sync between computers, which was nice.
I also kept a folder on my Kali VM where I also kept scan results, scripts, successful exploits, etc. I kept this synced by committing to a private Git repository. If you’re only doing the course from a single computer, you should still do this because it’s nice to have a backup.
There are around 55 machines in the lab, split between 4 different networks. To start, you only have access to the public network, but there are 3 other networks that aren’t routable to begin with. You can start with pretty much any machine you want, but my advice would be to leave the big 3 bosses (PAIN, SUFFERANCE, and HUMBLE) for last. Personally, I started with the low hanging fruit: Windows XP/2000 boxes or Linux boxes with old kernels are usually pretty easy to crack.
I set a goal for at least a new low priv shell/root shell every day, it’s really hard to follow goals like this. Sometimes I didn’t get any new shells for a week. Some days I would get 3 or 4 root shells. As you move your way through the network and figure out the dependencies, the shells will start to roll in.
Although there are several public machines with routes to the IT/dev networks, not all of these are ideal for our pivots. OffSec made it easy on us and put some dual-homed machines in there with SSH and nmap already installed. If you find a dual-homed machine without an SSH server already installed, my advice would be to keep note that the machine is dual-homed, but look for a better pivot. I wasted a lot of time trying to set up the required software to pivot. If you’re unfamiliar with the concept of pivoting AND you’re not even sure if you installed the SSH server correctly, it’s not very cohesive for learning.
I also recommend you read OffSec’s write-up of ALPHA. It’s great to read other people’s methodology for scanning, exploiting, and enumeration. Definitely check it out on the forum section for ALPHA
Here are some general hints on how to best spend your lab time:
- It’s no secret that some machines in the lab require some piece of information to crack (i.e. re-used passwords, passwords in a .txt file, or a client-sided attack). Unfortunately, nobody will ever tell you which machines those are. If you’re scanning a machine and doing some good enumeration, but still can’t find a way in, move on and circle back. If you’re doing good post-exploitation on machines you root, you’ll find the hints. They’re not hidden.
- #offsec on freenode and the forums were a great support. If you’re totally lost on a machine or are not sure if you have the correct vector, you can usually gather enough information from censored forum posts to know if you’re going down the right track (although there are usually more ways than one into a machine).
- Don’t pay much attention to !hints in IRC. They hardly ever make sense, even after you’ve rooted the box
- Don’t bother going to OffSec admin support unless you have a lot of work to show them. Going to them saying “help” or “I’m out of ideas” will get you a response of “try harder” or “go back to the enumeration step”. They can tell you if you’re on the right path, if you’re missing something obvious, or if you’re going down a rabbit hole, but only if you have work to show for it.
- Brute force attacks are not as prevalent as I thought they would be. For online password attacks, if you don’t know a username, don’t even bother. If you know a username, don’t spend more than 5 minutes on a brute force attack. This is intentionally designed this way. If this is a route OffSec wanted you to take, the password will be very easy to guess. Don’t forget about Hydra’s -e option 🙂
- Cracking hashes: unlike in a real penetration test, I recommend you try using online services before cracking unsalted hashes yourself. Crackpot, Hashkiller, and Crackstation were the 3 online services I primarily used. If they failed, I had cudaHashcat installed on my host machine. I’m not sure how fast this will be if you’re only using your CPU inside a VM, but with an NVIDIA 960 you can get a pretty good hash rate, depending on the algorithm used. For dictionaries, I definitely recommend you find a good English dictionary. I was very disappointed in rockyou’s performance. I never cracked any of the root passwords for the Linux boxes, but I never really needed to.
- If you find yourself running exploits at the rate of one every few minutes, you need to take a step back and look at your enumeration results. For any exploit that you run, you need to have at least one solid piece of evidence that the exploit will be successful. ALWAYS read over the exploit
- I never had to download a different OS to compile/test exploits. If you’re thinking you need to do this, you need to back up a few steps
- Recursively running Dirbuster is a huge waste of time
Exam attempt 1
I thought I would have to buy an extension for sure. But as the shells kept rolling in, I realized around day 70 that the end was near. At around day 85, I had a proof.txt for every machine in the lab (with the exception of the firewall and the proxy server).
I recommend booking your exam over a month in advance, because weekend slots are usually filled for months out. You can always reschedule later if something comes up. Also note that lab extensions include a free exam attempt, so if you are buying an extension, you might as well take the exam and get that first fail out of the way 🙂
A few notes about the exam: no, you can’t run any tools you want. Vulnerability scanner (Nessus, Nexpose, OpenVAS) are not allowed. SQLmap/SQLninja are not allowed. You are only allowed to use Metasploit auxiliary, exploit, and post modules on a SINGLE machine on the exam. You can use any Metasploit payload you want as many times as you want, and you can use all Meterpreter functions except getsystem.
“But what if I have a time-based blind SQL injection vulnerability on the exam? I can’t do that manually!” Don’t worry about it.
Although I know that most people do not pass on the first attempt, I felt pretty confident about this exam. I had 50+ lab machines under my belt, I could write a basic buffer overflow in a few hours, and I had written quite a few scripts to augment both remote and local enumeration.
I started at noon on Friday. I got my first shell within 20 minutes, but things really started going downhill from there. I didn’t manage my time well, I made some mistakes early on which cost me a lot of time, and I wasted my Metasploit lifeline. My advice here is: do it right and do it thoroughly the first time, or don’t even bother doing it. Also, save your lifeline for as long as you can. If you suspect a host is vulnerable to a Metasploit exploit module, save it for last.
In the exam, each box is given a point value for a total of 100 points. If you submit a lab report and include the answers to the course exercises, you are given 10 extra points. Low privileged shells are worth “some” points (I don’t imagine more than half).
My first attempt got me around 55 points, including my lab report. Although I felt prepared, I obviously had some more work to do. Definitely turn in your lab report and course materials and ask for feedback so you know you’re getting the maximum 10 extra points.
Exam attempt 2
When I initially scheduled my second attempt, there were no slots available for over a month. I checked back a few days later, and saw slots available for the next week. Check back with the schedule often if you are looking for earlier slots.
I made some improvements to my scripts, and practiced on some vulnerable VMs from Vulnhub. I also practiced writing more buffer overflows.
My next attempt was much smoother. I had 1 root and 2 low priv shells after only 2 hours. After 16 hours, I was confident I had enough points to pass, but probably spent a total of 21 hours in the exam, with an hour for dinner and a two hour nap. A lot of people say “take regular breaks”, “sleep”, “eat snacks”, etc. The only time I would go AFK was when I started to feel frustrated. When the frustration sets in, get up for a bit, and move on to a different machine when you come back. I wouldn’t recommend sleeping unless you think you have enough points to pass.
I finished the exam with 3 root shells and 1 low priv shell, for a total of 65 points (including the extra credit from the lab and course exercises). You need 70 points to pass. Since you don’t know how many points low privileged shells are, I wasn’t 100% sure I had enough points to pass. I was hoping a low privileged shell would be at least 5 points.
A few days later I got the best email of my life: “We are happy to inform you that you have successfully completed the Penetration Testing with Kali Linux certification exam and have obtained your Offensive Security Certified Professional (OSCP) certification”
I spent an average of 5 hours in the lab on weekdays, 10 hours in the lab on weekends, for about 12 weeks. In total, I probably spent around 600 hours in the lab over my 90 days. I did this along side a 40 hour work week. Fortunately I had no relationship or familial issues distracting me during this time. Obviously the time required may vary depending on your past penetration testing experience and current living situations, but hopefully this will give you an idea of the time commitment required.
Overall, my experience in the labs was 12/10. I learned more and worked harder in the labs than in all 4 years of college combined. I recommend this course to anyone interested in doing penetration testing as their line of work. I think that having this certification shows employers that you know enough about IT and information security to apply your knowledge to unfamiliar scenarios. Thanks to all the Offensive Security staff for such a fun summer! I look forward to applying the skills and work ethic developed in the course on the job.
For those people who haven’t been doing pentesting for years: The lab and exam are no joke. Many nights, you’ll go to sleep feeling like a failure and think to yourself “penetration testing is too difficult; I must change career paths”. But just try, try hard, and try harder!
I plan on taking the OSCE and OSWP in 2017. Hit me up on the twitter (https://twitter.com/kafkaesqu3) if you have questions about the course.
Happy hacking, and don’t forget to try harder!