Exactly 100 days ago from my writing this, my lab access for Penetration Testing With Kali (PWK) began. PWK is a course offered by Offensive Security intended to prepare you for the OSCP certification exam, a grueling 24 hour endeavor where you must hack roughly 4 out of 5 computers assigned to you for this purpose. Should you do so, and write a satisfactory exam report, you will become an Offensive Security Certified Professional.
I took this course because I, like many who are reading this, love security. I want to make a career out of it, and my research indicated that this was the hardest, most well respected certification within my grasp. I will briefly explain my experience prior to embarking on this journey. This has been the summer before my senior year in college as a computer science major. I hadn’t covered much related directly to pentesting, just a bit of nmap, Metasploit, and Wireshark. But I felt my background in CS would support me, and I chose my courses the prior semester with this in mind. Two in particular: One on networking fundamentals, and one that was supposed to be an introductory network security course. I found the former exceedingly valuable, and the latter mostly a waste of time (we used the tools I mentioned earlier once or twice each, but it was mainly vocab that I’ve had no use for).
My 90-day lab access period began on May 12th. It took me 16 days to complete the course exercises and videos, which while a little dated, does cover everything in the syllabus here. At the time it was hard work, but that was before I knew what I was getting into in the labs. Every day I went through material outlined in the syllabus above, learning about the listed topic, and completed assigned exercises in the ~400 page pdf and associated video series. Most days I put in between 6 and 10 hours, working shortly after waking up until 5-8pm when I would run errands, play games, and then go to sleep. The hardest section I encountered was on buffer overflows, which took me 2 workdays and a couple hours of a third. I found it to be quite useful later in the course.
Some people ignore the exercises and go straight for the lab environment. I didn’t feel knowledgeable enough to do so, and was enticed by the 5 bonus points I might receive on the exam for turning in a lab report. Unless you’re already an experienced hacker, you’re likely doomed to fail if you ignore the coursework. Many times someone would ask in the super special secret Offsec IRC channel “How do I solve X lab machine, I’m stuck on Y problem”. The responses were either “It’s in the PDF” or “Try Harder!”. Often, it can be dangerous to ask for help or look for hints on the forums. As a noob, there was much I would not have thought to look for had I not been made aware of some fundamental step in the penetration testing process by another. But there were very likely other times where it was less fundamental, and detrimental to my development to seek aid. For by doing so I deprived myself of the opportunity to grow. So I caution any prospective student: do not ask lightly. And when you do, prove that you’ve tried. Hard.
On to the lab. This is where the bulk of my time, and ultimately effort, ended up being spent. Completing the coursework gave me a few starting points, some easy machines to tackle. Originally I wanted to take the network in chronological order by IP address. This is technically impossible due to dependencies, at least on my subnet, but it gave me some structure and helped me work. Some machines are easy. Others are hard. My best day I got 3 I did not work a 12 hour day until I found myself emotionally unwilling to put a machine down. On my best day I got 3 machines, and my worst dry streak was roughly a week. I mentioned earlier that many machines in the lab network can be solved via methods in the pdf. It is also true that many or not, and you will be learning as you go in the lab network. Find enumeration tools, and learn them, use them, and love them. All in all in my 73 days of lab time I got 38 machines in the lab, some of which in the segregated development and IT networks (I never made it into the admin network). During this time I had a total of roughly 2 weeks where I couldn’t work, due to various life obligations.
Every machine in the lab network can be completed without Metasploit. I used it for a little under one third of the machines I completed. In a few of those cases, that is because I would have had to convert a Metasploit module to a standalone exploit to do so. In the rest, it is usually because I was lazy. Sometimes, there is appropriate laziness (I know how to do X but want to move on). Other times, there is inappropriate laziness (I don’t know how to do X without Metasploit, but I want to move on). I have been guilty of both. As a general rule, use this as little as possible, for you are only allowed to use Metasploit against one target in the labs.
As for the actual vulnerabilities encountered in the labs, I will not comment overmuch. What makes these labs machines so special is that it’s a network. More than that, it’s modeled to simulate an actual corporation’s network. The lab machines, of which there are roughly 70, talk to each other. Scripts simulate user activity, enabling client-side attacks to be a valid approach. Firewalls separate groups of machines from one another, requiring good pivoting skills to advance. Every machine can be solved in a unique way, and is intended to teach a particular skill or methodology. And a select few are challenging puzzles, designed to frustrate and entice even the most skilled veterans. I am proud to have merely done one of these, perhaps the first or second most difficult machine in the labs, referred to as “gh0st”, and of which I will speak no more.
It has not escaped me that I have yet to cover documentation, which is a most crucial component of this certification. I have mentioned lab and exam reports previously, the lab report being optional and the exam report being mandatory. The lab report consists of turning in the exercises from the coursework, and write-ups of 10 machines you’ve hacked in the lab(using different methods). I attempted to adequately document everything from the beginning, but looking back from the end of the course it’s easy to see how awful I was at it. Painfully so, as I often had to redo older exercises to properly document them, and much time was wasted trying to remember what I did at a certain time 2 months ago. I was given great advice on this by a “Tony St4rk”, who told me to document anything I did that had output, and then delete what’s unnecessary later. This advice, however, was for the exam where it’s much higher stakes. Our own Cry0l1t3 has excellent advice for general life and lab purposes. If I could change only one thing about my work this summer, it’d be to have been more rigorous in my documentation.
My exam was scheduled 5 days after my lab time ended. I spent them doing light preparation, nothing too intensive like my work in the labs. Mainly going over my lab report and reviewing how I had hacked various lab machines. I had it start at 10AM. In 5 and a half hours, I had 55 points. 2 complete machines and one local root. 7 hours later, I rooted a third machine, and had a total of 65 points. I earned no more points. I needed 70 to pass, which means that if they liked my lab report I was in. However, when compiling my documentation for the exam report, I realized I had made a fatal mistake. I forgot to include an ifconfig command output in the screenshot of a local.txt flag, costing me 10 points, and consequently my chance at the certification. Another mistake I made was assuming an exploit failed because I didn’t read it properly. This caused me to waste time, and my usage of Metasploit, as the exploit did indeed work. Ultimately, I had failed.
So, what have I learned? A hell of a lot, really. Too much to condense into a write-up or review. I attribute my failure to my lack of sleep during the exam. When I take it again come October, I plan on sleeping for 4 or even 6 hours. I also learned that I’m capable of passing the exam, which is greatly encouraging to me. Although I would be lying if I said I were not intensely frustrated, as passing has been the sole object of my labor this summer. But that in of itself is a valuable opportunity to overcome my own pride, and so I plan to Try Harder.
FAQ: Ask me something in the comments if you have any questions about PWK, and I’ll add your question and my reply here.
Q: How far into exploit development does the course go?
A: It’s mainly modifying existing exploits, but in the course you’ll create a buffer overflow partly from scratch, being given only a bit of code that sends a command to a vulnerable service and crashes it. From there you play with the debugger to create code that results in a reverse shell. Later in the coursework, you turn this code into a Metasploit module.
Q: Are there client side attacks in the labs or exam?
A: I can’t speak for the exam, but there are multiple client-side machines in the lab network.
Q: How similar are HTB boxes to PWK boxes?
A: I am just now experimenting with HTB, so I cannot say for sure. However, I have it on good authority that many HTB machines are similar in difficulty to a lab machine, and possibly exam machines as well. One thing I do not know if HTB replicates well are a few things PWK does especially well, such as client side attacks, and using post-exploitation skills to traverse a network of computers.
I’d like to extend a special thanks to the following people, ordered as they appeared to me in the users section of the forum: @skidd0, @Pyhscript, @pry0cc, @anon79434934, @Cry0l1t3, @egy, @Leeky, and @fraq. All of whom actively supported me and gave me advice in these past three months. Additionally I want to thank Dyntra and T0ny St4rk from the Offsec IRC, as well as my parents for supporting me and my girlfriend for putting up with me.
- Rain
