This is part 2 of a 2-part post. The previous post was more about me, while this post is more about advice for others. (There’s also a part 3.)

Success in this course comes from two things: experience and knowledge brought to the course up front, and how much quality time is put into the course while taking it. This makes it extremely difficult to gauge what someone needs to do to prepare or how one should approach and study. Some students will fly through the labs due to their large amount of free time or pre-existing skillsets, while others will take a few months to get the ball rolling up their steep learning curve. Every step of the course and the lab discovery and pwnage is a separate journey; even researching things that turn out to be false leads takes time and energy. The goal is to get the most out of the course, and that is often about putting the time into it.

Some Basic Foundation

Try to become familiar with the Kali Linux and the tools it has and the layout. This will be your home base for the course, and has pretty much everything you’ll need.

For those newer to Linux, start using a distro on a day-to-day system and find some online courses on Linux security and administration and shell scripting/commands. Linux+ level skills are good, anything beyond is great.

For those newer to Windows, find some courses on Windows security and OS administration. This includes hosting server-type applications (e.g. web platforms).

Learn some Metasploit. It’s worth it and it’ll get used, whether in the course or beyond as a pen tester. Off Sec has a free Metasploit Unleashed course.

Learn some basic, free, staple tools and get comfortable with working various switches: nmap, unicornscan, curl. Google the top 100 security tools.

To get familiar with some of the big issues over the past 15 years, grab a copy of Hacking Exposed (McClure, Scambray, Kurtz).

For pen testing theory, check Penetration Testing: A Hands-On Introduction to Hacking (Weidman) or the slightly more up-to-date The Hacker’s Playbook 2 (Kim).

Have a decent enough grasp of networking to know how TCP/IP works in general, use and read some Wireshark/tcpdump output, and understand IP addressing, firewalls, and ports.

Have a decent grasp of our web technology works, from configuring web servers, looking at simple HTML/PHP/ASP code, and how browsers interact with the web server.

Install some security-related browser add-ons and poke around the Developer tools in place in every major browser these days (F12).

Dive into Python or Perl enough to get into Socket programming. Very useful to start swimming in the ocean of editing or making exploit code or enumeration scripts. Having had a course of class in basic programming is great, as you can start to consume any language if you know the logic.

Start thinking like an attacker. This often comes with experience, but start thinking of ways you can get to Goal X or Access Y. What mistakes do you look for? What isn’t default?

Lastly, know that OSCP/PWK comes with course materials and videos that teach you everything you need. So don’t think you are going into this being tested from day 1. You’re going to be learning from day 1 until day X.

To Be a Successful Student…

For most students, this will be the very first taste of anything to do with pen testing beyond reading a pen testing report someone else produced. As such, think about what pen testers do with their jobs: scan and attack systems, keep and organize and protect notes, create client reports, research, and learn. Students should be going into this course looking to hone and taste and practice every piece of that job role.

This is an entry level course and certification for an IT discipline that is not itself entry level. Security combines everything and a little more from other IT disciplines. Pen testing touches them all, and is certainly not an entry level route into general IT. That said, the PWK/OSCP is, by necessity, still only a small taste. As such, students should have some exposure to Linux, Windows, networking, coding, web technologies, Metasploit, shell scripting, and Python, among other more specific experience. In general, the more enterprise level troubleshooting done in these topics, the better.

Find a support group somewhere to turn to, even if it’s the spoiler-free IRC channel. Be ready to put some time into this as well, from a social standpoint. Help others out and befriend a few peers. Don’t be that person who just wants to leech answers. Give something back and grow your network. Plan on this taking several hours out of each week to maintain relations. To be fair, this is the biggest difference in the course today from my previous experience; the social opportunities and other learning services are amazing today. Don’t ask for answers; don’t give answers away; help yourself and others learn by doing and figuring things out.

The course isn’t teaching anything brand new to the world. Be ready to consume resource material quickly, efficiently, and effectively. Sometimes there is the need to read manuals for tools or apps, or even find them first! Be good about using Google and analyzing search hits efficiently and effectively.

Rely on Metasploit exploits as little as possible. When source code is found, try to run the attacks manually. This is largely to help understanding, but also test prep since Metasploit use is explicitly limited. When time is available, put in some research and effort into manual attacks, even up to porting Metasploit ruby modules into standalone Python/Perl/Shell exploits.

It’s ok to find something obvious and focus on just that thing, but the better bang for the buck involves taking notes on ideas, but moving on and making sure to at least lightly touch everything available. There might be something even easier to exploit, especially since so many lab machines have multiple routes to root. This means going fast isn’t a great measure; it’s about being thorough and finding all the lessons offsec has prepared in the labs. When looking at the whole lab, it is known that every system has an issue. But it is not known if every system has more than 1 route to root. This adds realistic uncertainty to methods and time spend.

Figure out how to keep notes. Think about how to document vulnerabilities and exploits enough that allow a client or future pen tester to recreate the steps and validate the results or the fixes. Test the notes in a few weeks by re-rooting boxes from the notes.

Do the course exercises and lab report, and be aware these two items will eat up 2-3 weeks of time (that’s what it took for me with a full time job and other responsibilities).

Words to My Younger Self (of 3 months)
Clearly, what I brought to the labs and what I did in them helped me pass the exam, but I feel like I could have done even better had I changed some things. I had more than several takeaways from my lab and exam experience that I would pass on to my own self of 3 months ago:

Rely on the forums less. This is really a balance that is going to be very personal and difference for everyone. For me, I think I relied upon the forums too much for hints that lead to answers. I’m very good with puzzles like that, but I think I should have found more things on my own. It’s a balance between money spent for time on the course, against one’s own knowledge, against one’s own background and familiarity with the OS versions, against being able to troubleshoot the clear issues. I think I used the forums too much on my quest to get x roots in y days. The quality of the learning, methodology, and accuracy is more important than speeding through and tallying up pwned systems. I learned this way too late.

Just to reiterate: Do not put so much emphasis on the quest to get x roots in y days!

Even when rooting a box with hints, troubleshoot and fully understand the opening used. Do all payloads work? Do other characters work? What limitations are there or requirements? Can I leave off the null character or does it need it? Can I play around with various sqli bypasses or does only one work? This sort of curiosity helps go faster and more confidently on subsequent similar boxes. Don’t just get root, loot the box, and move on. Absorb and analyze the holes for full understanding.

Get better at knowing what is normal on a linux system for various distros. What are the default services and their runlevel? What are the default SGID and SUID files? What are the default cron jobs?

Once comfortable doing these manually, script out the very basics of the initial enumeration scanning. Unicornscan->nmap-> maybe a nikto or dirb or enum4linux scan immediately. Those are time consuming to wait through. I may as well throw in a few curl gets since I do those every time I see a web server/port. Taking this too far snowballs into huge scripts that steals away learning from doing things manually, though. The real goal: to be able to kick off a scan of x boxes while working on a different one without interruptions. This will help on the exam, but also in the field. But don’t take this so far that manual tests and results are missed.

The methodology is king, but the vulnerability trivia and experience in the labs is a close runner-up. But still, make the methodology the main key. I’m a big believer in checklists, and I have enumeration checklists that I continued to update and maintain from even my early lab wins. Learn from others and continue to build what works for me.

With every rooting look back at my process and ask: What can I do to find things like this quicker? Am I missing steps? What clues lead me to this answer and how do I make sure not to miss them? Always review your process after each box and update your process/checklist. I did this, but not enough for my taste.

Make a list of lessons learned from each box. Try to keep them in one location so you can review later and make sure you do know those things. incorporate every experience into your full body of knowledge and skill. I also did this, but again I should have slowed down and done it more.

Train a bit for the exam. 5 boxes, 24 hours. Sit down some day and tell yourself “I will spend 3-4 hours on this box and be done.” See how that goes. See how your work space and notes look when you hit your cutoff. Move to another box and spend 4-5 hours again. Any success? Weaknesses? Fatigue? Did the break from the first box spark some ideas? During my time in the labs, I sat down on a box and stuck with that one box until rooted (30 minutes to 16 hours) with only 2 exceptions where I had to walk away for a while. This didn’t prepare me for the exam.

Do not be afraid of the exam! For me, I learned almost as much about myself and my knowledge during 48 hours of exam time and cooldown as I did in about a month of lab time. Failure is not embarrassing on this exam! It’s a chance to figure out what needs to be done to succeed further. I should have been ready for the basics of it and taken a crack earlier. If I had failed my first attempt when I took it at 90+ days, I would have had to look elsewhere beyond the labs to improve myself for subsequent attempts.

Figure out a way to stay organized on the desktop. After the exam, I had about 30 terminal windows, 4 firefox windows (with several tabs each), and 10 unsaved text files hanging out. Doing 3-4 systems at one time means being organized, not just inside your mind, but also on the desktop. Get better at tmux or other terminal helpers like screen or get dual screens going. I did fine when doing one box at a time, which is how I tackled the labs, but this got out of hand during the exam with 5 boxes at once.

Figure out a way to automatically record commands issued and/or terminal output. It’s a waste of time to do this manually. asciicinema and screen.

Get better at DLL sideloading and windows executable payloads. I just didn’t find as many opportunities in the labs to do this as I thought I would, but that likely means I just missed them.

I still have lab time this month, and I plan to tackle a few of the last items on this list while I have that time available.