Hi! Welcome to my maiden blog post. Given the obligatory “everybody who has completed the OSCP will write their own review about it”, here’s mine.
For anyone who may not be well versed, OSCP is the Offensive Security Certified Professional certification, which, unlike other security certifications like CEH/CISSP, focuses more on practical skills. The certification comprises of the Penetration Testing with Kali Linux (PWK) course, and the final 24-hour practical exam.
Firstly, let me start off with a little self-introduction. I graduated with a Diploma in Network Systems & Security from Ngee Ann Polytechnic. During my time in school, I chose to specialise in advanced networks instead of security, and thus, only had surface-level knowledge on security concepts and practically no penetration testing or practical security knowledge. Though my primary “forte” was in networking, having acquired the CCNA and JNCIA certifications… having run my own hosting company in the past, I was somewhat proficient in Linux and Windows systems administration as well.
Labs and Exercises
I purchased the 90-days Lab access in late February, and the course was scheduled to start on 10th of March. There were many “tactics” that people who have completed the course have documented, so I won’t go into a deep dive about how I did mine personally. However, I did find the course exercises to be somewhat of a chore, which I was not too keen on completing. While a total of 10+ unique lab machine “full root” and full course exercise completion would have given an additional 5 marks on the final OSCP exam, it was also required that the answers to the course exercises would all have to be correct. Given my experience with academia, I instead strove to understand the exercises, what they sought to introduce and how I could use the content in the exercises when the time came up.
In terms of the labs, however, they were somewhat interesting, but also quite dated. Despite having the 90-day Lab access, I did not strive to complete all 50+ machines that were in the Lab, and in fact, took quite a number more “cheat days” than I would have liked (going overseas, life, challenges while in NS) while attempting the labs. Consequently, and surprisingly, I did manage to complete nearly 40 machines, inclusive of the “big four” machines in the lab which I was pleasantly surprised. I was a little bit disappointed that the lab machines were somewhat outdated, and therefore, the exploits for the applications were also a little old. Nevertheless, I think the most important takeaways from the lab were the concepts that they sought to impart. I used Metasploit sparingly during the Labs, given that it’s use in the exam was restricted, and only used it to discover the features and functionalities that it could provide.
The most interesting part of the labs and exercises personally was the introduction to shell code, and buffer overflows. Previously, I had heard about these before but had always been averse to actually try to learn them as it looked somewhat scary and daunting looking at program registers. That said, as it was part of the course content, I went through the syllabus and I do have to commend that the way Offensive Security introduced us to buffer overflows was pretty intuitive and well-explained in the videos and course document.
It is often said that if you fail to plan, you plan to fail. I messed up a little bit on my exam scheduling here, as I did not plan ahead in advance for when I should take it.
After Lab access ended in mid-June at the 90 days mark, I was contemplating and somewhat doubting my ability in taking the exam, having heard “horror” stories about people having taken and failed the exam for 2, 3 or even up to 6 times.
Therefore, I booked the exam on 26 July for midnight on 28th July. Arguably, not the best time to start off a 24-hour exam as you’d be awake through the night solving the challenges. I got some sleep early on the 27th, but was distracted by having to attend a family dinner when I had originally intended to sleep until 11 PM or so.
Given that the OSCP is a proctored exam, this meant having to enable screen casting on the machine that would be taking the exam. Additionally, it was also necessary to provide a live webcam view of yourself throughout the duration of the exams (with the exception when you’re going for breaks, rest, etc.). Personally, I was not impressed with the webcam requirement. When I started 15 minutes early, it appeared that the proctor had some difficulty in accessing my webcam view on their systems, and we had to delay the start of the exam a little. Already not off to a great start. Furthermore, every once in a while, I was notified that the webcam feed had died on their end and I would need to restart the session on my end. Which is something I guess they could take into consideration and improve on. To their credit, the admins remained completely professional during the exchange, and did their best to keep me composed throughout the process, not faulting the student for any issues faced.
Thankfully, I passed the exam on my first attempt.
Trying harder during the exam
I started off performing all scanning and enumeration activities, such as nmap/unicornscan, on the machines. At the same time, I started to challenge the buffer overflow machine. Within the first two hours, I had completed the bulk of first-level scanning and enumeration activities, and managed to get root on the buffer overflow machine.
Next, I decided to tackle one of the lower-point machines (10 points), and managed to get in and establish root within 10 minutes as it was rather straight forward.
From here, it was a little bit of a mess. I was able to get low-level shell access on two of the machines, but was not able to escalate privileges to root/system administrator access. Therefore, I was jumping between these two machines quite a lot, constantly trying to find the way to escalate privileges.
I continued working until about 9am, where I decided to take a short nap and refresh my mind. After waking up at 11, I continued working on escalating the privileges for these two machines, but by 2PM, I was starting to get worried that I was still not able to find the vector to do so. As such, I decided to take another break and went for lunch.
After coming back from lunch, I noticed something simple on one of the machines which I had not noticed before. After making this discovery, I quickly got to work and managed to root one of the machines within 30 minutes. I was still unable to get root access for the other machine, unfortunately.
As such, I decided to focus on the last machine. This machine turned out to be somewhat tricky, as there were red herrings all over, and focused on a protocol that I had not fully immersed myself in during the labs. That being said, after another 2.5 hours of work on this machine, I managed to get full root access to it.
The last few hours was a bit of a blur to me – as I was completely exhausted by this point. Through my calculations, I had known that the amount of points I had gotten so far would likely net me a pass. That said, I was not certain of it and continued working on the last machine – albeit already not thinking straight at this stage. I think I couldn’t keep myself awake during the final few hours of the exam, which I was starting to somewhat nod off (my bad to the administrator who had to watch this).
Ultimately, I decided that I would not be able to solve the final challenge and thus, decided to devote some time to ensuring I had all the proper documentation to write the exam report. Once the lab time cut off at 2345 hours sharp, I decided that I needed some shut eye and got some rest.
In addition to completing the 24-hour exam, it was also mandatory to submit an exam report resembling a penetration test, performed on the machines in the exam. Using the template provided by Offensive Security, I made changes to it to reflect the findings of my penetration testing during the exam. Overall, this was the easier part of it as I had been somewhat used to writing reports. I spent about 3-4 hours on the final exam report and sent it in about two hours before the deadline.
As I took the exam around the Black Hat and DEFCON period, it ended up being an excruciating 6-day wait from the time I submitted the exam report until the time I got the results.
Plan, Plan, Plan.
The most important, perhaps. Your routine should be somewhat systematic down to a nail from the practice you had obtained in the labs – scan, enumerate, discover vulnerabilities, find exploits and then take action. Rinse and repeat. While 24 hours may seem like a lot of time, planning for what I needed to do and staying organised definitely helped me stay focused during the exam instead of having to constantly go around finding notes on how I could go about doing some of these activities. Keeping notes and commands definitely goes a long way.
Definitely, also ensure that there are no technical issues with your Kali VM, that there will be no expected power loss or scheduled maintenance by your ISP. While this may seem somewhat strange to put here, I think it’s an important aspect as the exam takes place on your premises and your equipment. Right before my exam, I realised that my Kali VM was not able to establish internet connection (required for the VPN session to perform the exam), which caused me to panic a little while troubleshooting. Definitely not the kind of thing you want to be worrying about on exam day.
Try Harder. Or Try Smarter.
Know which exploits you should try, and which you should not work too much on. Due to the nature of the exam, there are some red herrings which may seem possible, but in actual fact are not exploitable, or the exploit cannot be re-written in a way to suit your requirements.
Especially while looking for exploits, some of them are way too technical in nature (even for me) that I was having trouble understanding what they did, or what the exploit code even does. It would be good to get a good understanding of the vulnerability (such as through CVE-IDs, or blog/forum posts by security researchers) prior to spending time on an exploit code that may or may not work to your content. Ultimately, again, I think this also goes down to planning. Spending a few minutes on researching exploits is just as important as being able to perform the exploit yourself. Open source intelligence (OSINT) is a part of the OSCP, after all.
With all that’s said, I wish any would-be OSCP takers all the best in their journey. This has been an experience unlike any other. One where I found myself wanting to smash my head against the wall many a times (figuratively). But, it has also been an experience of discovery and a test of perseverance. I definitely learnt a lot throughout the whole process, and would not hesitate to take the other Offensive Security courses which introduce more advanced concepts.
Thank you for your time in reading this somewhat lengthy blog post!