Having passed my OSCP exam last week, I thought it would be good for me to share my thoughts with OSCP aspirants out there. A little bit on my background first. I have a bachelors degree in computing specialising in information security and have worked as a network pen tester for slightly over a year. I consider myself proficient with both Windows and Linux.

Lab

I bought the 90 day package after reading online reviews from other OSCP candidates. Offensive Security recommends going through the course materials first before starting on the lab. However, after a quick glance at the materials, I realised that I was already familiar with most of it. Hence, I dove straight into the lab, only referring back to the course materials on subjects which I am less familiar with. All in, it took me 57 days to root all 50+ lab machines. I paused for 8 days in the middle to complete the exercises so it actually took 49 days. I spent approximately 4 hours every weekday and the entire day on weekends rooting these machines. I had a few cheat days where I took a break from the OSCP but by and large stuck to my regimen of rooting 1 machine every weekday, or at least obtain a low priv shell. Being disciplined and sticking to a routine is important if you want to root all the machines.

I would recommend:
1. 30 day package - Experienced pen tester interested in certification only. (you wont have time to root all lab machines)
2. 60 day package - Experienced pen tester or working on the course full time.
3. 90 day package - Everyone else.

Exam

I managed to pass the exam on my first try. You will want to book early since the slots get taken up quite quickly. I started my exam at 6am and got the first machine within 30 minutes. With the low hanging fruit done, I then focused on the other machines, alternating between them every hour or so when I get stuck. I managed to get a low priv shell before lunch. After lunch, I worked on the buffer overflow machine and completed it within an hour. By 4pm, I managed to get a second low priv shell on another machine, and escalated that machine within the next 30 minutes since the privesc vector was rather obvious. I then alternated among the other machines but could not get any further. I decided to call it a day at 10pm, after 6 hours with no results. With the 5 bonus points from the lab report, I estimated my score to be 70-80, enough for a pass. I submitted my report the next day at 3pm and received the good news via email at midnight the following day.

Advice

Start small to big

When looking for vulns, start from the smallest possible module. Start looking at the Wordpress plugins, followed by Wordpress Core itself, and end off with apache web server. Wordpress plugins have a userbase of tens to hundreds, Wordpress is used by millions, apache runs 40% of the web. If there were to be a vuln, it is most likely found in code that is rarely deployed with almost nobody auditing it. Popular frameworks and software are likely to have higher code quality.

Understand errors

When running privesc exploits, you need to know which errors are fixable and which are not, so as not to waste time trying to fix unfixable errors. Unfortunately, this is something that comes with general working knowledge of OSes. For example, the error message /lib/libc.so.6 version 'glibc_2.17' not found is a fixable error. It means that you compiled your exploit on a machine with a newer version of glibc as compared to the target. Since glibc is not forward compatible, the binary fails to execute. Check the target's version of glibc using ldd --version and recompile on a machine with an older or equivalent version of glibc.

The error message kernel lacks CAN packet family support is not fixable. The kernel was compiled without certain flags enabled or certain modules were not loaded, hence it is not vulnerable to this exploit. No amount of fiddling will make this exploit work. Beginners will make the mistake of wasting valuable time trawling through the repos finding the exact module, or worse compiling it themselves. After bringing in the module, they will try to insmod it and realise that only root can load kernel modules, then they will go on to google for an exploit to load kernel modules as a low priv user. Therefore, it is important to understand error messages so you do not miss out on escalation vectors which would have worked, or go down a rabbit hole trying to fix something unfixable.

** That said, there are a number of kernel exploit authors who only leave unhelpful comments such as props to so and so, uber, leetz, do the thang and so on. Kernel code is difficult to understand. I will admit that I am not at that level yet and will usually move on if I cannot decipher the error message.

Give up

This seems contrary to Offensive Security's motto of "Try Harder", but learning when to give up is equally important. There are lab machines which are not directly exploitable, no amount of enumeration will help. You will need to give up and move on. Eventually, you will find the key to that machine in another machine. Similarly, some of the exam machines are much harder than the others. You will need to know when to give up and move on to another machine. Spending too much time on that machine may eventually cause you to miss out on valuable points from other machines.

Good Luck!