**Update (11/4/2016) – added a few bits back in from this post

A few weeks ago, I “tried harder” and was awarded the Offensive Security Certified Professional (OSCP) certification.

I tried harder #oscp pic.twitter.com/oL0nDOd6mK

— Dan Helton (@ch1kpee) September 19, 2016

As many people before me have done, I decided I’d post a little writeup of my experience with the Pentesting With Kali (PWK) online training and taking the OSCP exam (twice).

As you probably know by now, the OSCP is Offensive Security’s certification for penetration testing using the Linux distribution they maintain, Kali Linux.   The accompanying course, Pentesting With Kali (PWK), gets you a PDF lab guide and a series of instruction videos covering the different topics of the guide, from basic network enumeration to writing buffer overflow exploits.  You’re also purchasing VPN access to their hands-on lab environment of dozens of different vulnerable hosts for you to probe and exploit.  To attain the OSCP certification, you take a hands-on exam in which you’re given VPN access to a special exam network and are alotted 24 hours to compromise as many systems as possible, plus an additional 24 hours to write up and submit your exam penetration test report.

I signed up for the 90-day course, bought a one-month extension after I ran out of time (mostly for going back over machines to write the huge lab report…more on that later), I bombed my first attempt at the exam, purchased a two-week extension in order to bone up on some stuff and get a retest attempt, then passed it on my second try.

The Cost, Signing Up, and Getting your Employer to Pay For It

I’ve wanted to take OffSec’s training for a long time and I should’ve just sucked it up, ponied up the money, and took it years ago.  I fought for over a year at my previous employer to get them to finance it.  I was ready to give up arguing with them and buy it myself before I landed in my current job.  Thankfully, where I work now has a healthy training budget for its pentesters and all I had to do was put it on the corporate card.

If you’re already on a pentest or vulnerability assessment team, the value of the OSCP is pretty obvious.  If you’re of the blue team persuasion, there’s a case to be made also.  You’re probably used to telling developers that they should fix that SQL injection vuln in their web app because attackers could use it to get access to internal systems; or telling a sysadmin he needs to update bash on his Linux server because attackers could use Shellshock to get into it…but how?  Learning pentesting (via a course such as the OSCP) gives you an understanding of just how attackers leverage vulnerabilities and exploit systems.  It can give you a much deeper understanding of how attacks really work and prepare you to explain to more resistant customers just how this or that vuln can be exploited and how far an attacker can take it.

$1150 USD for three months of lab time and an exam attempt sounds like a lot, but if you think about it, it’s still a lot cheaper than SANS courses, a college course on pentesting, or most other cert’s boot camps.  If you can get your employer on board to pay for it, awesome!  If not, but you have the money to spend, I think it’s some of the best training you can get.

You’ll need a non-free email account to sign up (so no Gmail or Yahoo).  If you use your work email, I recommend specifically adding orders@offensive-security.com to your contacts and/or whitelisting any email from the offensive-security.com domain.  The spam filter where I work is very aggressive and doesn’t like Offsec’s domain, for some reason.  You wouldn’t want to be late for your exam because some shitty spam filter blocked the email with the VPN info and password from coming in.

PWK is in high demand, so expect to not be able to start your lab time immediately.  When I signed up, I picked a start date and had to wait a month or two before I could connect over the VPN and start.  When purchasing additional lab time, however, you’ll get access back instantly.

Lastly, PWK is a self-directed course. There’s no instructor there who’s going to hold your hand and show you all the answers.  It’s up to you to motivate yourself, study up on different tools and exploits outside of the course cirriculum, and work through problems on your own in order to pwn all the hosts on the lab network.  If you’re the right sort of person to get into pentesting and infosec, this probably isn’t a problem for you.

Prerequisites and Preparation

You could sign up for PWK as a total Linux and security newb…but you’d probably waste weeks of your lab time self-studying on remedial subjects.

Your lab time is precious (and costs money), so you definitely want to get the most out of it that you can by studying up beforehand on some important subjects.  My own goal was to try to do as much self-studying beforehand as possible and maximize the amount of lab time I could devote to owning boxes and having fun in the lab.

Linux

First and foremost, you need to be a competent Linux user.  When I taught my CNS320 class, I used to set up Linux Mint VMs and run my students through this tutorial from the University of Surrey in the UK.

The Linux Command Line is a good starter book, available in a free electronic version or as a book from No Starch Press.  The author’s website also has some good material on learning Linux and shell scripting.

Another dead tree option is How Linux Works, which is a great book on using Linux and understanding the nuts and bolts of the OS.

Obviously, there are a ton of online tutorials and books to choose from.  You might also look for O’Reilley books or study guides for the CompTIA Linux+ certification too.

The best way to accelerate your learning is to do it, whether accompanied with an instruction website, book, or totally on your own.  Specifically, force yourself to use the Linux command-line shell.  Make a Kali VM in VMware or Virtualbox and start practicing moving files, piping input and output, using command-line text editors, and other tasks.  Get comfortable with it.

You don’t have to have sysadmin-level knowledge or be LPIC certified in order to do well on the OSCP…but it probably doesn’t hurt.  I’m a bad gauge for how much Linux you should know for PWK because I’d been using it at work and at home for almost a decade.

Despite having taught a course on it, the CEH isn’t terribly helpful.  I taught my CNS320 course way more like it was PWK than the truly awful training material that EC-Council provided.

Scripting

Another subject that will help immensely is to be comfortable in a scripting language.  I would recommend learning some Python and some bash scripting.

I originally learned Python using Codecademy‘s free course.  This was before they started charging for the Pro version, so I’m not sure if all the same stuff is available for free anymore or not.  Much as with Linux, there are thousands of websites and books to choose from if you want to learn Python.  I like it because it’s very simple and quick to learn, yet offers lots of powerful modules and options.  Plus, it’s popularity means that answers to any of your questions, erorr messages you might get, etc., are easily found on Google.  Lots of the exploits you’ll see in the labs and all over Exploit-DB are written in Python.

If you already know some Python and want to take your pentesting skills with it to the next level, check out this presentation and accompanying series from Primal Security.

Another handy scripting language to pick up, and which is covered a little in the lab guide, is bash scripting.  Bash (short for Bourne Again Shell…old Unix joke, long story) is the default command-line shell on most Linux distributions and has it’s own built-in scripting language for automating commands.  The bash scripting language isn’t the most intuitive in the world and I’m not really all that fond of it…but I kinda force myself to use it because it’s so ubiquitous in the Linux world and can come in handy if you’re on a system that doesn’t have Python or some other more modern scripting language.  The aforementioned Linux books usually have some good info on bash scripting and the Linux Documentation Project also has a bash beginner’s guide that I read through when preparing.

Other than that, just some basic code literacy is helpful.  PWK doesn’t expect you to write a lot of code, but you need to know how to read it and have a basic understanding of what some exploit written in C or C++ is doing.

VulnHub and CTFs

The best way to learn anything is to do it, which is a philosophy that PWK and the OSCP embrace whole-heartedly.  A great way to start doing is to try your hand at some different capture-the-flag (CTF) challenges.  CTFs are very popular in the pentesting and hacker community as a challenging and entertaining way to test out your skills.

Big security conferences like DEFCON, Derbycon, and Shmoocon have in-person CTFs, if you’re lucky enough to be able to attend such events.  You can also find plenty of online CTF events that you can register for and compete.  Of the ones I’ve done, I especially like Derbycon’s CTF, as it is put on pentest-style with a network of vulnerable machines to exploit, much like PWK.  Most CTFS are in the “Jeopardy-style” format, with little individual challenges in different categories, such as crypto or web app hacking.  These are fun, but not terribly relevant to PWK/OSCP.  CTFTime.org is a good source for finding current and upcoming CTF events, both in-person and online.

My recommendation for getting some hands-on practice before PWK is to download some specially-made challenge VMs and practice attacking them on your own time.  VulnHub is the definitive source for challenge VMs that you can download, run in VMware of Virtualbox, and practice attacking.  The De-ICE and Kioptrix series are great for beginners and I used them to teach my classes with.

If you get stumped (and you will), each entry on VulnHub also lists links to walkthroughs where you can learn how others were able to successfully exploit them.  This is great for building your initial knowledge and getting you ready for PWK.  I’d even recommend that after you exploit one, go back and ready multiple people’s walkthroughs for it and see how their methodologies and techniques may have differed.

Pre-Gaming

You’ll learn a lot about penetration testing tools and techniques in the labs.  I also recommend you take a look at the PWK syllabus and see if anything on there looks unfamiliar or makes you nervous.  You might want to study up on such topics before you schedule your PWK course.

Two particular tools that I think you’d benefit from pre-studying and getting really comfortable with are the Metasploit framework and netcat.

Metasploit is very handy, not just for the exploits packaged in it, but for it’s awesome Meterpreter shell, msfvenom utility for making shellcode, and it’s packaged scripts for finding and exploiting buffer overflows.  There are two great sources for learning about Metasploit.  One is Offensive Security’s own free online Metasploit Unleashed course.  The other is the Metasploit: the Penetration Tester’s Guide book from No Starch Press, which is co-authored by Mati “muts” Aharoni himself.  The book is a little out-of-date; the biggest changes being msfcli’s functionality being rolled into the msfconsole command and msfpayload and msfencode being combined into the msfvenom tool.  Otherwise, the examples and guides in it are all solid.  Just a little hint: some of the examples the book gives will show up in the PWK lab.

Netcat is another simple, yet extremely versatile tool that it would behoove you to spend some time on and become a ninja with before you start PWK.  Netcat (usually found somewhere in the /bin/ or /usr/bin/ directory on most Linux distros as simple “nc”) is an old Unix tool for setting up TCP and UDP connections.  There are several variants available in Kali, including socat (which supports sockets), cryptcat (which encrypts the connections that netcat makes), and my personal favorite, ncat.  Ncat is an updated version of netcat that comes packaged with nmap and supports new features like IPv6, encryption, etc.  There’s plenty of good tutorials online for getting comfortable with it, like this one and this one.  Many Linux and BSD distros use the OpenBSD version of netcat, which disables the “-e” option.  This doesn’t actually stop you from setting up bind shells and reverse shells, only makes it a little more complicated.  More on that later.

Other Helpful Material

Two more things that I don’t feel are really necessary, but have helped me out as a pentester, are learning to use vi/vim and the Red Team Field Manual.

Vi is short for “visual editor” and is a command-line text editor for Unix/Linux.  Vim stands for “vi improved” and is an updated version.  Just about every Linux or Unix distro has vim installed and “vi” is just a shortcut to it…but you might come across old installs that still use classic vi or specifically symlinks “vi” to a version of “vim” set to mimic the old behavior (which has some annoying quirks, like having to use h,j,k, and l instead of arrow keys for moving around).  When I got into pentesting, I forced myself to learn vi and vim.  The reason why is because: 1.) you aren’t always going to have a GUI session on a box and be able to use gedit or leafpad, and 2.) not every system is going to have “nano” installed on it.  “Vi” is the standard Unix text editor, so you will always find it installed on every Linux or Unix distribution.  Openvim.com has a great online tutorial app for learning it or you can run the “vimtutor” command in the Linux or Mac OS X terminal to get vim’s builtin tutorial.

The Red Team Field Manual is a very handy little quick reference to different OS, database, and hacking tool commands.  It’s great to thumb through when you might not know exactly what to google for and is invaluable if you’re ever pentesting in an environment with no outside internet access.  Like I said, not necessary at all, but it’s small, cheap, and worth keeping in your laptop bag.

Taking the Course

Once you’re in, start watching the videos and working through the lab guide.  Do all the exercises and write the answers done (it’s good for extra credit on your exam).  Once you’ve powered through that, it’s time to start powering through the labs.

The lab guide and videos will show you a lot of the things you need to know to get up and running.  If you feel really lost, the forums have a great official thread walking you through pentesting the “alpha” host and will be adding walkthroughs of “beta” and “gamma” in the future.  The real point of the lab, however, is for you to figure things out yourself and find a way to compromise each host.

During my lab time, I was able to compromise almost all of the hosts on the public network, including Pain and Humble, two of the supposedly “hardest” VMs on the network.  I had footholds into the Dev and IT networks, but didn’t have much lab time left to delve further into them.  Plus, pivoting into these networks is slooooooooooow (as in real-life pivoting) and it’s really frustrating to have your pivot machine reset by some asshole while you’re right in the middle of hacking a host in the deeper network.

For me, at least, it’s kinda hard to pick up and put down attacking lab VMs.  I liked to devote several uninterrupted hours to it each day.  While my employer was nice enough to bankroll it, I didn’t get time during the work day to pursue it.  For me, I’m married and have a small child, so my only time to do it was at night from 8 PM on, once my son was in bed.  I’d usually stay up until midnight or 1 AM doing labs every night, maybe a little during the day on weekends, if I didn’t have anything else going on.

So for me, as someone who already had a background in pentesting, getting ~4 hours a day to pursue it, I owned most of the Public network in my initial three months.  As I mentioned before, my extensions were mostly to go back through stuff to make the enormous lab report and then a quick refresher after my first failed attempt at the exam.  Obviously, your mileage is going to vary based on how much self-study you have to end up doing on the side and how much time you have to devote to it.

I know a young kid with no pentesting background who could only afford one month and he was able to power through and get about as much done as I did.  I don’t think he slept much during that month, but hey, if you’re determined, you could do it in a month.

I personally recommend buying the full three-month package, as it’s not that much more than the 30- or 60-day package, and you’ll get more time to have fun hacking the targets in the lab.

Exploiting Targets

One thing that took me a while to get used to is that the PWK lab is very heavily geared towards using software and OS exploits to gain access or escalate privilege.  If you’ve done a lot of CTFs on VulnHub, you might be more used to exploiting bad configurations or shitty sudo settings to get root.  You’ll definitely see that too, but it felt like usually the way forward was either an exploit off of Exploit-DB or simple password brute-forcing.

The one, biggest, most important piece of advice I can give you is:

ENUMERATE, ENUMERATE, ENUMERATE!!

By the time you’re done, “nmap -A -p- <IP address>” should be permanently etched in your brain.  Scan every port on a box, figure out what service is running on every open port, figure out what software they’re using for that service, find out what version of it is running…find out EVERYTHING!  If you start asking for help in the forums or on IRC, that’s probably the most common tip you’ll get (besides “try harder”).  There isn’t any kind of sophisticated security on the network or any of the hosts, so don’t worry about trying to be stealthy or low-and-slow; hit them as hard as you can.

The tools I probably used the most for enumeration were nmap, enum4linux (if you see SMB or Samba ports on a box), nikto, and dirb.  I know a lot of folks like dirbuster, but I prefer dirb as it’s on the command line, runs fast, and has a good default wordlist.  Nmap has a lot of special scripts built into it for further enumerating services you find, under /usr/share/nmap/scripts/, and you can get more info on what they do using the –script-help option or by going to nmap’s documentation site.

One other important note: scan all 65,535 TCP ports on any box you encounter (“-p-” is the shortcut in nmap for that), but for UDP scans, just use the nmap default (ie, “nmap -sU <IP address>”).  It would take you a few weeks to successfully scan all the UDP ports on a given box over a slower VPN link.

I had a friend who spent days running hydra and trying to brute-force every web app, RDP, Telnet, SSH, and FTP instance he could find.  I found that to be entirely unneccessary.  Any time I came across some service requiring a password (usually an admin portal for a web app), I would do three things:

• Google to see if that particular software had any sort of default credentials when you first install it and try those out
• Went through some very simple bruteforcing (like trying root/password, admin/admin, that sort of thing)
• As I compromised more hosts,  I saw there were several recurring characters in the story of the fake company you’re supposed to be hacking in the PWK labs.  So I started trying out their usernames and different simple passwords or passwords I discovered during post-exploitation (like cracked hashes, passwords left in plaintext files, etc.)

This isn’t just something to do in the PWK labs; this is just a good all-around practice to do in any real world pentest you find yourself in.  Your mileage may vary, but I found wide scale, intense brute-forcing to be unnecessary.  Hopefully that’ll save you some time.

Also, remember that you’re sharing the lab environment with a lot of other students.  When you’re in the lab, you have a control panel site where you can revert any of the target VMs back to the original state, in case some attacker has messed up a service or crashed the box.  To minimize stepping on other people’s dicks, I would avoid going after machines that had just been reverted within the last hour or so.  If a VM’s last refresh was hours or days ago, I figured no one else was attacking it and it would be safe for me to go after it.

Before you attack any box, GO REVERT IT.  That way, you know it’s fresh, untampered-with, and you won’t have to wonder if your exploit failed because someone else ruined the service or because you did something incorrectly.

While you’re doing the labs, START WRITING THE LAB REPORT.  You can find the format and requirements here.  It isn’t mandatory to write up a lab report, but if you do, it’s good for extra credit on your OSCP exam that might just push you over the edge if you just short of passing.  Writing up the lab report is a huge time drain and I spent weeks writing mine.  Luckily, I didn’t need it, but I would’ve been kicking myself if I’d needed it and couldn’t bust it out in time.  I used KeepNote in Kali to keep a running hack log of every machine I was attacking, scan output associated with it, different web directories I discovered, notes on software versions and possible exploits, commands I ran to generate shellcode for it, etc.  What I tried to do was keep a running log of everything so that someone could read it and repeat my results.  Obviously, if you like Evernote or some other note-keeping software better, go for it; but keep good notes!

Getting Help

Shortly after I started my PWK, they moved from IRC to the new Support site.  The IRC channel is still around, but I never really used it.  There is a bot that will give hints for different boxes, but I never found them terribly useful.  In fact, they usually didn’t make sense until after I’d already compromised the box and only then would I understand the cryptic hint.

I know some people would try to message admins and ask for advice, but that usually just results in being told to “try harder.”  I only ever talked to an admin if I thought something was actually wrong with the box or I was having some sort of issue with the control panel site or my VPN.

The OSCP forums were the best source of hints whenever I found myself stuck on a machine.  Since I signed up, they’ve reorganized them to make it much easier to find and ask for help on a specific machine.

Things I Found Useful

The /usr/share/ directory: I don’t think they really mention in the lab guides just how much useful stuff is buried in the /usr/share/ tree.  For one thing, it’s the standard location for most application’s associated data, like Metasploit’s module files and buffer overflow scripts or nmap’s NSE scripts.  For another, OffSec has put some really useful stuff in here, like a collection of web shell written in different languages, wordlists for several different brute-forcing purposes, a directory with some useful Windows binaries like nc.exe for you to drop on compromised Windows hosts, and more.

Reverse Shell Cheat Sheet: pentestmonkey’s site overall is great, but this page especially.  You aren’t always going to be able to drop Meterpreter or find netcat on a target, so it helps to know multiple ways to get a reverse shell with what’s available to you.

Windows Exploit Suggester: there are a couple of other Windows privesc suggester programs, but I like this because you just have to copy/paste the output of the “systeminfo” command, you don’t have to drop and run any binaries on the target machine.  It’s good for narrowing down which exploits to try out.

Windows Privilege Escalation Fundamentals: this is a guide you’ll often see recommended in the OffSec forums.  When there isn’t some obviously vulnerable version of Windows or software on the box, these steps can help you tease out the path to full Administrator or SYSTEM rights on a box.

Basic Linux Privilege Escalation: g0tmi1k is one of the OffSec forum admins and often does great write-ups of CTF challenges on VulnHub and elsewhere.  This is the definitive checklist of steps to run through when trying to root a Linux box.

Exploit-DB: seeing as how it’s maintained by OffSec, obviously Exploit-DB is going to be a source of a lot of the exploits you end up using in the labs.  Security Focus is probably the #2 site for exploit info, but isn’t as well-organized.  You can also use the “searchsploit” tool inside Kali to query Exploit-DB from the command line.

Google: if you aren’t already, you will be a Google wizard before this course is through.  Whether it’s looking up attack techniques, tutorials for unfamiliar tools, exploit code, documentation for vulnerable software you find, or default passwords for said software, you’ll be doing a lot of self-study and research.

Brosec: shameless plug for my friend Gabe Marshall‘s command-line reference tool.  Very handy for quickly looking up how to use query the Windows registry, how to write a one-line Python reverse shell, or other common hacker tasks.

python -m SimpleHTTPServer 8080: a one-liner I still use on a daily basis.  A lot easier and quicker than turning Apache on and off, in my humble opinion.  Also nice because when you run it in your terminal, it prints all the incoming requests.  So not only is it handy for hosting your malicious script or PHP, it’s also handy for quickly fuzzing for RFI on a web app.  In fact, I got my foothold on one of the target boxes specifically because I was using this one-liner and it allowed me to see the incoming RFI (and troubleshoot that an additional file extension was getting tagged on and keeping my script from running).  I usually use “8080” for the port, but you can change it at the end, in the case where it’s conflicting with another app or you’re trying to get around firewall restrictions.  On every Linux and Mac I use, I keep this in my .bashrc with the alias “pythonwebserver”.  Be aware that it’s “python -m http.server 8000” on Python 3, in case your environment uses it instead of the more common Python 2.x versions.

The Exam

Before you do anything: read the official OSCP Certification Exam Guide!  Then read it again!  Make sure you’re crystal clear on what you need to do in the exam, which is basically document all your steps so it’s repeatable and take screenshots before and after all your exploits.

Like with signing up for the labs, you won’t be able to sign up today and take your exam tomorrow.  The first available times are probably going to be several weeks out, so prepare accordingly.  You’ll get 24 hours of access to a private lab environment with several hosts in it, each of them having different point values for getting root/admin on them, totaling up to 100 points.  You need a minimum of 70 to pass and you can get up to 10 points of extra credit for writing up the lab guide exercises and making the lab report.  After that, you get an addition 24 hours to write up your exam report and email it to OffSec.  You’ll find out within a few business days whether you passed or not.  Once you’ve passed, you get a link to page to fill out where you want your paper certificate mailed, you get access to the OSCP Certified section of the Offensive Security forums, and you can change your forum name from your OSID to one of your choosing.

I scheduled both of mine to start on a Friday at 9AM, as my son’s in daycare that day (and wouldn’t be tempted to come up to my office and want to play).  My first time, I only got about 40 points worth of flags and wasted hours chasing a dead end.  I took stock of what happened, learned some lessons from it, and scheduled to take the exam again two months later.  The second time around, I had 80 points by the evening of that day, so I was actually able to sleep, and spent the remaining time trying to figure out the last box on the network I hadn’t compromised.

Like most exams, time management is key to success.  While all your scans are running, work on another part of the exam.  If you get stuck on one target, just take a break and move on to another one.  Take time to rest and eat during the exam, as you aren’t going to make any progress when it’s 3AM and you’re exhausted and hungry.

You can use Metasploit auxilliary, exploit, and post modules against only one machine of your choosing during the exam.  The first time, I saved it for a machine where it was pretty clear what the exploitable service was, but the code on Exploit-DB for it was nightmarish spaghetti.  I opted to use the Metasploit module for it instead and it worked.  My second time around, I didn’t really need Metasploit for any of the boxes.  I ended up trying it on that last box that eluded me, just for shits and giggles, but it didn’t help.

Something I found useful for keeping focus and blocking any outside noise was some good music while I hacked.  When I’m trying to focus intensely, I found something instrumental is best for a background soundtrack.  I’m sure a lot of you might like classical music of some sort, or maybe techno or retrowave…I’ll confess that I have a thing for video game music covers.  In particular, I was listening to a lot of Minibosses and Bit Brigade to keep me pumped and get through the exam.  If you’re into rock covers of NES music, I highly recommend them.  You can buy all their stuff on Bandcamp, iTunes, and other places.

Another important piece of advice, if you already work in security or pentesting, is don’t let your expertise mislead you.  For instance, the majority of my job is web app pentesting, so obviously I’m pretty well-versed in it.  The OSCP doesn’t expect you to know much beyond very simple XSS, SQL injection, and LFI/RFI.  I wasted hours of my first exam chasing what I thought must be a web app exploit that obviously wasn’t there and felt foolish when I realized it after I failed the first time.  I could see folks who come to this from a development background having a similar overanalysis problem.

Another piece of advice, without giving away too much, is to go through the entire lab guide and all the exercises.  Let’s just say that, on the exam, you might come across something that you had to do in the lab guide that you didn’t really do in the labs.  You wouldn’t want to be surprised by anything.

TL;DR

OSCP is a great, fun experience.  Look at the syllabus and see what sort of things you could be studying up on before you sign up so that you can spend the bulk of your time hacking shit in the lab.  ENUMERATE ENUMERATE ENUMERATE.  Treat the OSCP like any other exam (manage time, move on if you get stuck and come back to it later, rest and eat when you need it).  Don’t let the experiences you bring bias you too much on a particular problem.

I hope these tips can help you make the most of your PWK lab time and pass your exam.  If you “try harder” and keep striving, you’ll conquer all the challenges, learn a lot about pentesting, and have a great time.

If you want to see the shiny new certificate I got, check out this post.