Now that the dust has settled and I’ve had a moment to catch back up on work and personal life, I wanted to write an article detailing how I prepared for the OSCP exam and share some helpful tips and tricks on how to get the most value out of the course and prepare for the exam. I’ve also received a lot of questions via LinkedIn on how to best prepare for the exam, so I think this can also be helpful to those individuals as well. For some background, the Penetration Testing with Kali Linux (PWK) course is meant to prepare you for the Offensive Security Certified Professional (OSCP) exam. I’ll elaborate more on the course below, but for now, the general path to passing the exam is PWK -> OSCP. It took me about 5 months of study time with about 13-18 hours of study time each week on average. There were some weeks where I spent the entire week tucked away in my home office studying (3+ hours each weekday, 12+ hours on the weekend), and there were some weeks that, due to school or traveling for work, I didn’t even look at the material.
Preparing for the PWK Course
Everyone has heard just how difficult the OSCP exam is and how it is one of the hardest cyber security certifications, and possibly IT certifications, to pass. In my particular case, this the difficulty made the certification a little more enticing to obtain but more importantly, it made me want to ensure that I would pass by over preparing. In doing my research of what other people had to say of the course and exam, I read countless stories of people who failed multiple times or ran out of lab time due to life and needed to extend the lab time multiple times, etc. I also came across success stories, and noticed that many of those who passed the exam recommended that if you are pressed for cash and/or time to spend on the labs, do as much preparation as possible before enrolling for the course. This is a sentiment that I will echo as well, as I prepared before the course and STILL ran out of lab time after having started with 90 days initially. Given that I was going to pay for the PWK course 100% out of pocket, I wanted to make sure that I prepared as much as possible to reduce my time in the PWK labs. I won’t re-invent the wheel by creating a prep guide, but instead will link (and give credit where it’s due) to the prep guide that I followed before starting the PWK course – Tulpa’s Preparation Guide. The Cybrary videos referenced in the prep guide cover the same content as in the book, so you can either read or watch videos – whatever you prefer. The videos are free but you would have to buy the book, which runs ~$16 used on Amazon.
To complement this guide, I also recommend that you setup a home pentest lab. This doesn’t have to be anything too crazy, but just setup a Kali Linux system as well as an unpatched Windows 7 or XP system and test out what you are learning. Microsoft has Windows 7 VMs that you can download and test here. For Windows XP, you may have to reach in your closet for an old disc or after going through the Google-FU section of the preparation guide, use your newfound skills to see if anyone has left any XP ISOs hanging out on their public webserver that may have *cough* “Index Of /” in the title of the page…*cough* (sorry I gotta get that cough checked out). [As an aside, I’m about 80% done with writing a guide on how to build your own full-blown pentest lab with the oVirt hypervisor. I was writing the guide prior to starting the PWK course and got caught up with that. Now that I’m done, I should be finishing up that article soon.] You can choose to deploy these VMs on your local system using VirtualBox/VMware (type 2 hypervisor) or if you want to be fancy, you can use ESXi/Proxmox/Hyper-V/etc (type 1 hypervisor). My recommendation would be to use a type 2 hypervisor for now, since you’ll probably want to be able to easily access the desktop/GUI of the Kali machine to run tools. Setting up the lab is essential because the OSCP is a 100% practical exam – there are no multiple choice/fill-in-the-blank/short answer questions. It is a 100% evaluation of applied skill by way of demonstrating that you know which tools and methodologies to employ to hack a system. Simply reading about all of these tools and techniques and jotting down notes won’t cut it, so make sure that you’re getting the full value of your time.
Another major benefit to setting up a lab and going through this guide is that it will quickly let you know where your gaps lie and what you’re already good at. While preparing, I found out that I don’t know Metasploit as well as I thought I did. I’ve spent my entire security career being a defender. As such, I’ve only used Metasploit three or four times in the past 5 years and the prep revealed that I didn’t remember much about how to use it (though I do know how to detect its use on a network). That was definitely a skill I sharpened before starting the PWK course, whereas Google dorks, scripting (both bash and Python), and traffic capture were all skills that I am more than decent in. In my preparation (and in the PWK course as well), those were all sections that I skimmed over.
The last point I’ll make about going through this prep is that you also get to gauge how much time you can spend studying. Think of this prep guide like a trial run – if you find that you can spend a solid 10-15 hours a week going through this guide, watching the videos, and testing out what you’re learning in the lab, you should be good to continue on with the PWK course.
The best part of this prep is that up until now, everything is 100% free (minus the $16 for a used copy of the book should you choose to buy it – which I recommend) and can be done at your own pace.
TL; DR: Follow Tupla’s prep guide, setup a home pentest lab with Kali and a Windows system, and sit up before you crawl (take the PWK course).
Taking the PWK Course
After making it through the preparation guide, I signed up for the PWK course with 90 days of lab time. The course teaches you the pentest life-cycle and tools in a hands-on way by giving you access to a virtual lab where you can (legally) use the tools and exploits you learn about to hack the systems in the lab environment. The lab is meant to simulate a corporate environment (thinc.local), where you can optionally make your way all the way to the admin network by leveraging lateral movement techniques. Below is a quick picture from Offensive Security showing the layout of the lab:
From the picture, you can see that there are some machines that may be linked to the Dev network, and some machines that are linked to the IT network, and some IT assets that are also connected to the admin network. This setup is no different than what you’d find in a corporate environment – some users have more access than others and can reach more network segments than others. Your job then, is to find these systems and use them to pivot to the other more trusted systems. The discussion about pivoting is getting a little ahead of myself, but I wanted to point it out since its hard to ignore when looking at the picture. Before worrying about pivoting into different networks, you’ll be dropped into the Public network first, which has about 39 machines.
The course comes with a PDF and accompanying videos to help guide you through the course material. Each chapter comes with exercises at the middle and/or end that help you reinforce a topic and apply what you’re learning. If you went through the prep guide I discussed above, the first 4 chapters should be a breeze and easy to comprehend. The following 13 chapters go over more hacking techniques and tools, and the last chapter of the guide and video gives a simulated walk through of how a pentester can traverse a multi-segmented network and eventually make their way to the admin network and compromise an Active Directory Domain Controller. Before jumping into trying to hack lab machines, I strongly recommend that you finish all of the course material, do the exercises, and take notes. I understand that everyone is different and there’s no one-size-fits-all approach to this, but there are a lot of benefits to completing the course material before jumping into the labs:
- This course is unlike most traditional certifications in that you aren’t hand-held or guided (too much), which is by design because this is not how hacking or pentests in the real world are conducted. You won’t learn a hacking technique/tool and immediately know what server to practice it on. As mentioned earlier, you’re dropped into the public network with 39 machines and you’re not given any context as to what techniques or tools can and/or will work against that machine, however most of what you need to know to hack the lab machines can be found in the course material somewhere.
- This is more of a personal preference, but I like to over prepare, or in this case, be prepared. Continuing the point above, as you come to new systems in the lab, you want to make sure you have a toolbox of exploits and techniques that you can draw from to hack the machines. If all you’ve learned so far is buffer overflow exploits but the system can only be compromised via a SQL injection, you’ll spend your time banging your head against a wall wondering how to gain access to the machine when simply reading through that one lesson in the course material would have you immediately know what to do or try next.
Note Taking & Keeping Organized
To take notes, I used OneNote on my actual Windows computer for the cloud syncing functionality. Others have reported using CherryTree or KeepNote inside their actual Kali VM, but I haven’t used those tools and can’t comment on how well they work or don’t work. The most important thing though, is that you are taking notes and that they are organized. The utility of CherryTree/KeepNote/OneNote is that you get to create tabs and pages to help you keep organized. You should be taking notes for each of the chapters in the course, and also taking notes when you hack machines so that you know how to get back in. Below is a screenshot showing how I took notes for each machine (the [+] represents machines that I’ve hacked):
For any files containing exploits or enumeration script outputs, I stored them directly on my Kali machine. I created a folder called “machines” on my Kali VM, and then created a folder for each lab machine and stored the scripts in there:
It also worth noting that you can earn an extra 5 bonus points on your OSCP exam attempt if you write a pentest report for 10 lab machines, as well as provide screenshots/documentation of completing the course exercises. For this reason, it may be worth it to write your lab notes in a semi-pentest report format instead of just dumping in a bunch of screenshots (see my screenshot above). This way when it comes time to do your lab report and you pick 10 machines for your report, you don’t have to do too much extra writing. They do provide you with a Pentest Report Template, so you won’t have to worry about creating your own format and style (but you are more than welcome to).
Building a Pentest Methodology
This is technically part of note taking, but I believe it should be called out in its own section. You should build a pentest methodology to help you enumerate, and ultimately, hack lab machines. Your pentest methodology should be built in a if-this-then-that format, to where you know what commands/tools/techniques you should try as you hack each lab machine. As you successfully compromise each system in the lab, you should be making sure that all steps that you took are captured in the pentest methodology so if those same conditions re-appear on another system, you immediately know what to do. I’ve provided a screenshot example of what mine looks like:
Now you may have noticed that I fuzzed out most of my methodology doc…and that’s because I don’t recommend that you use someone else’s methodology document – it’s more worthwhile to build your own. The pentest methodology is more valuable to you and, in my opinion, makes more sense if you’ve gone through the manual processes to build the techniques, tactics, and procedures (TTPs) captured in the methodology. Some of the value from learning is lost if just following a pre-made script that someone else made. To clarify, there are Windows privilege escalation guides as well as those for Linux, and those are fine to reference.
There are awesome tools such as Reconoitre that can automate a lot of the enumeration processes for you. I would recommend avoiding these scripts in the beginning of your lab time so that you can learn the tools individually and gain an intimate understanding to their strengths, limitations, and purpose. Once you know how the enumeration tools work, and you don’t feel like re-inventing the wheel, feel free to go ahead and use scripts made by others. For a more engaging/valuable experience and if you have the time to spare, I’d recommend that you create your own automated enumeration scripts, especially if you are new to scripting and programming. Either way, as you compromise more systems, you should make sure you’re automating the enumeration process to make yourself more efficient.
One thing that I enjoyed about the labs is that certain machines contain interesting, and sometimes hilarious, text documents and email exchanges between the fictitious co-workers at “thinc.local”. After successfully gaining root/Admin privileges on each system, I recommend that that you dig around and see what you can find. This is your chance to be as nosy as you want to be and often times, you’ll be rewarded for doing so. Sometimes you may find a text file that a user saved to “remember to replace X Anti-Virus software on Y’s computer next week”, instantly telling you what AV software one system is using, or you may find a script that has a plaintext password saved in it. While we’re on the topic of passwords, make sure that you are dumping and saving passwords when and where possible. Remember, this lab environment is made to simulate the real world. Just like how users (unfortunately) re-use passwords, you may come across some instances where a user’s password found on one system is the key to compromising another. Below are some examples of how I kept my dumped passwords organized:
If you get to a system that requires a password and you already know the username, immediately jump to your password store and see if you have a password for that user.
Now to the question I’m sure most people are hoping to have answered after reading this post – How many machines should I hack before I should consider myself ready for the exam? Are you ready for an underwhelming answer? No? Well that’s all I have unfortunately, heh. The answer is, I don’t know. I REALLY wish I had a more concrete answer to give you, but the truth is, I don’t know and anyone giving an answer is, at best, guesstimating. There are some people who hacked 25 machines and passed, and there are some that hacked 35 lab machines and failed. Being the over preparer that I am, I wanted to make sure that I hacked all of the machines in the public network and at least make it to the admin network before attempting the exam. I ended up being able to hack 48 machines – all of the systems in the Dev and Admin Networks, all of the systems in the public network except for one, and only two systems in the IT network and technically passed the exam in 10 hours (I’ll get into that in my exam experience). Here’s where and why things become a tossup in regards to how many machines you need to hack in order to pass:
- Having passed the exam, I can say there is one technique in particular that I learned from a lab machine that I used to help me hack an exam machine. I feel very confident that if I had not hacked that specific machine in the lab and learned that technique, I probably wouldn’t have quickly recognized that I needed to use that technique on the exam. It may have been possible that I would have (eventually) hacked the machine, but keeping in mind that the exam is timed to 23 hours and 45 minutes, you’ll want to make sure you get through the machines as quickly as possible. It’s possible that someone can hack just the right machines in the lab and learn everything they need to pass, and someone can hack all the machines in the lab BUT the one(s) that would help them on the exam and fail.
- Experience also plays a huge factor in how ready someone is. Someone who is green to pentesting or offensive skills may need to hack more lab machines than someone else who has more experience in that arena. I probably could have passed having hacked less machines, but I don’t think that, being as green as I was, I could have gotten away with hacking only 25 machines and taking home the prize.
- How much you absorb in the course also plays a huge role. There are times where I could have simply blindly download someone else’s exploit script and ran it, or even worse, just use a Metasploit module to hack into a system, get root/Admin privileges, take my screenshots, and just call it a day. But if I did that, I wouldn’t really have learned much. There are subtle things you learn by looking at someone else’s exploit scripts and trying to figure out why they did what they did, and you wouldn’t learn these subtleties if you just blindly ran something that automatically gave you access to the system. Of all the 48 machines I compromised, I only used Metasploit for 4 of them. This gave me lots of opportunity to experiment with scripts and manually exploiting systems. More importantly, on the exam you can only use Metasploit once, so I did not want to get hooked on it. Ultimately, if you really want to learn, keep in mind that this is a process – a long distance goal and not a sprint.
For the reasons given above, I would recommend that you try to hack as many lab machines possible before taking the exam and build a solid pentest methodology.
Before taking the exam:
- Make sure that you have a pentest methodology of some sort (I know what you’re thinking, “If this guy says pentest methodology one more time…”). This can bail you out if you get stuck in a rabbit hole or don’t know where to go once you reach a certain point. There’s many times where I relied on “muscle memory” to hack systems and then get stuck for 40+ minutes, trying things that I think should work and failing when the next step was already written down in my pentest methodology. Just to hammer that point home, the pentest methodology should be a checklist of things to look out for as you gain access to a system and as you elevate your access to a system, you should be enumerating and consulting your methodology to help guide you if you get stuck. Also go back through your lab machine documentation and make sure that each enumeration/exploit tactic is captured in the pentest methodology.
- Have some automated enumeration scripts, either self-authored or something like Reconoitre
- Plan to take the exam when you will be most awake and alert. I’m a mid-morning person and feel best when I wake up at 8AM, so I scheduled my exam for 9AM
- Secure a quiet, distraction-free zone for you to take the exam. If you have a significant other, let them know that you’ll be M.I.A for 24 hours and may have some odd nap/sleeping patterns that day
- Study/review what you feel you are weak on up until the day before your exam. The day before your exam should be spent relaxing and doing something else other than trying to cram last minute information in your head. You want to make sure that you approach the exam with a fresh set of eyes that haven’t already been exhausted because they’ve been staring at the computer screen all day prior.
- Become familiar with the exam requirements. On the day of the exam, you will be given a set of instructions to follow for how to document your exploits on the various hosts. It helps to know the expectations before the exam, so you don’t waste exam time reading it and getting familiar with it for the first time.
TL;DR: Do all course modules before jumping into the lab machines, take great notes, build a pentest methodology, write your own scripts if you have time to spare/want to learn more scripting, loot machines, and make sure you do plenty of crawling (hacking systems) before you attempt to walk (take the exam).
Taking the OSCP Exam
My exam was scheduled for 5/21 and I made sure to take that day off, as well as the day afterward so that I could write my pentest report and catch up on any sleep I lost on the exam day. The day of the exam, the Offensive Security team will send you an email package containing an OpenVPN file for connecting to the exam environment, instructions on which IP addresses are targets for the exam, and a link to the exam control panel. I won’t go into too much detail on how the exam works, as the Offensive Security team has already done a good job detailing exam guidelines here. Instead, I’ll highlight my experience with the exam and give some of my tips at the bottom. If you read the earlier portions of this post, you may remember that I mentioned that I technically passed the exam in 10 hours. I’ll go more into detail on that….This is quite a bit embarrassing and a huge facepalm moment, but in the spirit of full transparency I’ll share my not so hot moment: I was using my my lab IP address (10.11.0.x) instead of the exam IP address (192.x.x.x) for the shellcode that I was generating, so none of my exploits were working. Sigh…I quite literally smacked my forehead once I figured out why none of my exploits were working. For some reason, it didn’t even click to me even after noticing that the exam IPs were in a Class C subnet. I guess I was so focused on making sure that I passed the exam in time that I missed that (not so little) detail. With that said, I wasted ~12 hours of exam time trying to get exploits working, partially because I’m stubborn, but mostly because I KNEW I was doing everything 100% correctly but I just couldn’t get a reverse shell back. What made this the perfect storm was that I almost expected the exam to be non-straight forward and difficult, so the fact that I was having issues getting a reverse shell only further played into my feeling that the exam was difficult and that I needed to try harder. I have more of my experience detailed below with a time-frame breakdown:
9:00 AM CST
I received the email with the exam connection information exactly at 9 AM. I immediately connect to the exam VPN, and start creating my folders for each exam IP and start my enumeration scans. While the scans are going, I’m reading through the exam guidelines on how I should capture my proofs and record my exploit steps. One of the first exam systems that caught my eye was a machine that had a vulnerability that I had practiced exploiting two days prior, so I knew that would probably be the easiest machine to go after. I then go through the motions of compiling the exploit, generating the relevant shellcode, and then tried to run it and…nothing. “Ok, maybe I screwed up on one of my steps,” I thought. I went through the steps pretty quickly and took a shortcut for a few of them, so I figured that I must have accidentally skipped a crucial step that was causing it not to work. I then went through the process again, making sure that I followed each step correctly in my abbreviated notes. I ran the exploit again and…nothing. “Ok, maybe I screwed up my abbreviated notes,” I thought, so I went back to the course material and followed the steps again, making sure that I followed each step again, and ran the exploit….again. Still no dice. I even went back and watched the course videos on that section, ran through all the steps again, and had no luck still.
2:00 PM CST
They say the definition of insanity is doing the same thing over and over again, and expecting different results. Well, that day I was insane. I continued trying to manually go through the exploit steps from start to finish for ~5 hours for that one system. I persisted out of stubbornness and partially because I was desperately hoping that in one of my attempts, I’d have a wonderful breakthrough (despite doing the same thing over and over again). At this point, I decided that I was going to move on to another machine and come back to this one later. I moved on to another machine and it was more of the same – I tried generating shellcode and was (unknowingly) using the wrong IP address, so it didn’t work. Again, I felt confident that I was doing the right thing, but tried many different ways to replicate the exploit but no dice. I even spent a fair amount of time trying different exploit scripts found from different sources – still nothing.
4:00 PM CST
That whole insanity thing? Yea…apparently I couldn’t get enough of it. I tried the previous machine for a few hours while also trying to research what I could be doing wrong. At this point, I started to feel defeated, but still felt like maybe I just needed to find my footing. I moved onto another machine and…you guessed it – still no dice. I started feeling dejected and pissed off, and took my first break of the day. I would take microbreaks here and there to check social media and Reddit, but this is the first time that I got up from my workstation and walked away.
6:45 PM CST
After my break, I came back determined to figure out what I was doing wrong and immediately jumped back to it. I also turned on the Cavaliers vs Celtics game and was lightly watching that in the background while I worked. I decided to move onto a third server and ran into the same issue as before – I just couldn’t get a reverse shell no matter what I tried. I repeatedly tried going about exploiting the vulnerability and fell flat on my face.
9:00 PM CST
At this point, I accepted that I was probably going to fail the exam. I wasn’t having any luck on the past 3 machines that I was targeting and was getting nowhere fast. Just about 12 hours had passed and I spent them stubbornly trying to force myself to hack those three servers. I seriously contemplated giving up and just turning off my computer out of frustration and watching the game instead. I was angry and confused at how I could exploit so many lab machines but couldn’t get at least one machine on the exam. It wasn’t until I switched to a 4th machine and finally found something interesting that everything began to turn around for me.
9:12 PM CST
Switching to the 4th system gave me the breath of fresh air that I needed. I gained an initial foothold on the system and eventually made my way to get a low privilege shell. While in the shell, I ran the netstat command and was looking for my lab IP address (10.11.0.x) but didn’t see it. “Wait, what the…” I thought. “Where’s my IP?” I re-ran the command to make sure what I was seeing was correct, and then I saw the port I knew I was connecting to on the remote machine and an IP I’ve never seen before. I immediately ran ifconfig on my Kali machine and saw that the exam VPN added the tap1 interface (tap0 was still connected to the lab network) and I had a different IP address for the exam. I felt like I was trying to play golf for hours and someone walked up to me and told me that I’ve been holding the club upside down the entire time. After literally smacking my forehead and yelling some obscenities, I continued working on the fourth machine, taking note that I have a different IP address.
11:30 PM CST
After getting pretty far with the 4th system and hitting a wall, I tried my hand at the 5th system. Based on point value, I assume that it was the hardest. I wanted to see if I could immediately find anything exploitable on the machine but quickly lost interest as I was more anxious to see if my IP address issue would resolve the problem I was having with the exploits on the other systems.
12:00 AM CST
I went back to the very first system I attempted to exploit and made sure to use the right IP address for the shellcode I was using. After swapping in the relevant shellcode and running the script, my terminal window showed me something that I was all too relieved to see – my netcat listener received a connection back from the victim. While grinning ear to ear, I made sure to take all the relevant screenshots and capture the contents of the proof.txt file. I still remember thinking at this point, “Well, at least you’re going down with somewhat of a fight. You’ll get the exam next time.”
1:18 AM CST
Immediately after hacking the first machine, I went back to the second one I was poking at. In a similar fashion, I made sure to update my exploit with the proper shellcode and tried it, but it didn’t work. It turned out that I was using the wrong exploit, but after finding the right one and making sure to use the correct IP address, I was able to hack this machine as well in about 1 hour and 45 minutes. With a slight bit more confidence, I decided to continue trudging on to see if I could add any more machines to my victim list before I failed the exam.
2:21 AM CST
While working on the second machine, I thought of something that I could try on the 4th one to help gain additional access. I re-read through my pentest methodology and found an enumeration command that helped me find something interesting. From there, I was able to exploit the interesting thing I found and compromise the machine to get full admin privileges. All of the tactics and techniques used to exploit that system made me feel right at home, like I was in the lab network all over again. “Don’t get too excited now,” I thought to myself. Even though I had 3 machines at this point, I still hadn’t scored enough points to pass, and time was still ticking.
3:18 AM CST
I switched to back to machine 3, updated my shellcode with the new IP, and then used the same exploit that I had been trying before. Much to my surprise, the exploit immediately worked and I gained low privilege access to the system. I felt myself getting a little happier, but for whatever reason, I had it burned into my mind that I was going to fail so I didn’t allow myself to get too much hope.
4:09 AM CST
After about 50 minutes on this host, I was able to gain full admin privileges on this system as well, making it the 4th machine that I compromised. After typing in “whoami” and seeing the terminal say I had admin privileges, I got out of my chair in disbelief. My mind was both confused and happy at the same time. I was happy obviously because I just hacked this machine, but at the same time oddly confused because I wasn’t sure if this meant I passed or not. I immediately opened up my exam panel and started adding up the points for all of the systems I had hacked so far. My caffeine had been wearing off so I wasn’t entirely sure my mind wasn’t playing tricks on me. I pulled out a sheet of paper and manually wrote down the IP addresses of the systems I compromised along with their associated point values. After adding up all the points, I checked the exam guidelines and it showed that I had passed. More confusion washed over me because just a few hours ago, I was moments away from turning off my computer and walking away from this exam and now I’m calculating my points and finding out that I’ve passed. A few minutes passed by and it finally sunk in that I passed. As excited as I was at that point, the only thing I could feel was sleepiness – I woke up at 7:30 AM the morning prior and it was creeping up on 4:30 AM. I set an alarm for 7 AM so I could take a quick nap and then try my hand at the last exam machine.
7:55 AM CST
After hitting my phone’s snooze button 3-4 times and laying in bed for a few minutes to mentally wake up, I finally crawled back to my desk. I tried to give the 5th machine a good college try but I knew that I was strapped for time (my exam was ending at 8:45 AM) and that I had already passed – there was no need to exert myself too much on this one. In the last 20 minutes of my exam, I found something interesting that I wish I had more time to poke at since I think that may have been a way into the machine. Either way, at 8:45 AM sharp, my VPN connection dropped and I was immediately kicked out of the exam network.
I then spent the next day taking naps to get my sleep schedule back on track, organizing my screenshots, and writing the pentest report. I submitted the report at 3:41 AM 5/23 (I had until 9AM to submit it) and received my “You’ve passed” email back at 5:34 AM 5/24, so there was about a 26 hour turnaround time for my report to be graded.
My Thoughts on the Exam:
Like I mentioned a bit above, after reflecting on my exam experience I realized that I effectively passed the exam in 10 hours due to an oversight on my behalf. However even though I spent a fair amount of time being stubborn and not moving on to other machines, I’d like to believe the most important takeaway is that because I gained a lot of experience from exploiting many lab machines and I actually knew what I was doing, once I fixed my oversight, I hit the ground running. With that aside, I felt that the exam was pretty fair and that if you are doing the labs, absorbing all the little details, and building a good pentest methodology (okay, okay, last time I’ll mention it!), you should be prepared to pass the exam or at least come 10-15 points shy of passing. Again, there’s no magic number of lab systems to hack before you’re ready for the exam or before you can pass, but if I absolutely had to make a recommendation, I would suggest no less than 23 machines in the public network, and try your best to work your way to the IT network, and get one or two systems in the admin network.
Exam Day Tips:
- Your IP address for the exam will be different from the IP you use in the lab environment, so keep that in mind. Yea…I shouldn’t need to say this one but there could be more people like me running around out there, so fair warning :)
- Before exam day, be familiar with the exam requirements. The requirements are open for you to read and get familiar with how the exam is conducted and what is expected of you during and after the exam. Don’t spend too much time reading the rules on the day of the exam – every minute is precious!
- Don’t spend more than 2 1/2 hours on a machine. If you are poking at a machine and getting nowhere, make sure you’ve documented what you’ve done so far, and come back to it later. This keeps you from stubbornly trying to force something to work when it’s not supposed to or if there’s another avenue you should be pursuing. In my case, I would have found out about the IP address issue sooner rather than later. It’s very possible that when you eventually make it back to the machine, you’ll realize that you didn’t enumerate it as well as you thought you did, or missed something in your enumeration tools’ output.
Hopefully sharing my experience has been insightful or enlightening for someone who’s trying to prepare for the OSCP. I hope you enjoyed reading as much as I enjoyed sharing.