PWK Tips

Speed up your directory scans by a huge amount with this one simple trick. Remove the word “manual” from your word lists!

What will really slow down a recursive directory search in the labs? The stupid “manual” folder for Apache. Dirbuster will go down that rabbit hole for hours. You won’t find anything useful in the French version of the manual, so why scan it so hard?

If you ever think you’ll find something useful in the manual, then go ahead and go there manually because it’s on EVERY box.

Simple way to speed up gobuster/dirbuster/etc is to just remove the word manual from the wordlists like this:

sudo sed -i -e ‘0,/manual/d’ directory-list-2.3-small.txt

Sed will then remove the first instance of the word manual. Grep the file again to see if you need to remove it again or if you did it right.

modify wordlist for OSCP
Before sed, there’s that nasty word right at the top
use sed to remove first finding of a word in a text file in linux
Success! Use soap! Use sed!

Compiling kernel exploits for OSCP, who needs the PWK image?

The Problem – “PWK is outdated and old”

PWK being old and outdated is certainly one of the criticisms of the lab and certification; however, fundamentals are fundamental. There is no arguing though the operating systems in the labs are indeed outdated. Windows XP and some very old versions of Linux.

For the Linux kernel exploits that were required (I always tried kernel exploits last in the labs) people seem to struggle getting them to compile. After all, these exploits are more than ten years old and everyone is running a current version of Kali and some of us are running 64-bit because we love RAM. Of course these old exploits don’t like to be compiled on a modern version of Linux and especially don’t like to be compiled outside of a 32-bit environment.

Eventually I got tried of looking for the right gcc flags just to get an exploit to compile. I went down a different path.

gcc compile linux kernel exploits

Match your dev environment to the target environment

Instead of trying to get my 2019 Kali to compile an exploit like it’s 2011, I used the magic virtualization to build a few dev servers. That’s a fancy way to say I spun up three VMs of old version of Linux to use to compile. I just picked a few distros that were close to what I was running into in the PWK labs, downloaded the 32-bit ISOs, installed a VM, and set up Samba shares to move the files around.

If you feel bad for not “Penetrating With Kali” and needing to rely on another OS go ahead and read the PDF and it does discuss about matching your test environment to what you’re trying to attack. If I had taken the time to set up a few VMs at the beginning of my lab time I would have saved myself tens of hours in trying to get things to compile.

Ubuntu 11/12/14

I used Ubuntu 12 and 14, but using 11 would also be a solid choice. You can download 11 from here and 12 from here. Ubuntu servers seem to be everywhere in the labs.

CentOS 5

CentOS can be a little tricky to set up with a GUI since installing VMware tools without a disc just wasn’t fun. I used CentOS 5.3 and then I found a great way to fix your repos. This will be useful just in case you actually need to install a header file or something.

FreeBSD 9

Why just Linux, why not BSD too!? Since the FreeBSD FTPs are down and only the newer versions are available I went ahead and downloaded FreeBSD 9 from somewhere sketchy and then just verified the hashes on’s website.

Compiling on Kali and Ubuntu
PC Load Letter? WTF does that mean?
Compiling Linux Kernel 2.6.36-rc8 - 'RDS Protocol' Local Privilege Escalation on Kali for PWK OSCP
It just works

Exam tips

Priv esc

Look for something novel.

OSCP Privilege Escalation secret
The things you own end up owning you. – Tyler Durden

If you haven’t seen something before, then you should probably look closely at it. Certainly take your time and look around, run your enumeration scripts such as PowerUP.ps1 and Powerless.bat but anything that stands out is probably the path forward.

Planning your attack – This is your life, and it’s ending one minute at a time. 

Slow down to go fast. The biggest change I made to my methodology was spending more time looking at my scans before I start my attack. Check all the ports, find all the version, find all the exploits. Then decide what to attack based on what might be fruitful. My approach has always been just to start wasting time on the first thing that looked good (hacking, dating, what’s the difference?).

LFI / RFI – I haven’t been PHPed like that since grade school

By far the thing I struggled the most with during the labs was local and remote file inclusion.

How did I overcome this? No clue. Just kept hitting buttons until it worked most of the time.

Paying attention to see if it needed a file extension or not helped. Sometimes you’ll need to include the .php and sometimes you don’t, sometimes it needs to be .txt instead. Why? Because php hates you, that’s why.

Do you know Tib3rius? He’s a great man – everything you would do but you’re too lazy to do it by hand.

Git clone it, use it.

Will it make you a l33t hax0r, nope. Will it just save you a bunch of time? Yes. Before I started PWK I wanted to write a bash script to just pass an IP as an argument and fire off most of my normal recon/enum scripts. Tib3rius (he’s white hat through and through and giving back a lot to the community) wrote AutoRecon. I was fortunate to get my hands on the beta at the very beginning of my PWK lab time. I used the beta version until just a few weeks before my exam. The latest I pulled was even better.

If you’re like me and like certain things to be ran in certain ways, that’s fine just go ahead and edit the toml file.

Exam pro tip: Run AutoRecon on the other four IPs while you’re doing the BOF and it will run most of what you should run to identify services. It even gives you a file of manual commands to run that you probably should run anyhow. It’s a great way to manage time because most of your enum will be running while you’re JMPing to ESP and redoing your badchar array for the 3rd time.

Is it the secret sauce to tasty success? I can’t say. I will say it ran something that made me look at something in a way I wouldn’t have normally looked at it…..and that leads to points on the exam.

AutoRecon is IMO the best way to collect enumeration data on CTF and PWK targets. Is it a hacking or pentest tool?….only if you want to get caught from all that noise but maybe that’s what you’re into (no judgement).

Useful things that helped me a lot and might help you to some extent and if they don’t I’m not a lawyer, but always use soap.

Buffer Overflows – learn to love assembly and hex.

Before my PWK lab time I started, I spent three weeks working on buffer overflows. Luckily, I learned a little ASM (Turbo ASM!!!!) many a year ago. I learned a little more in college, but that was a hot minute ago.

But for three weeks I decided to jump into the thing that scares a lot of people but is very easy to master at the level required for the exam. The BOF is the “free points” of the exam.

My best advice, grab an evaluation copy of Windows 7 32-bit and/or WinXP or Server 2003 and spin up a VM. Install Immunity Debugger, Mona, some vulnerable software, and start exploiting.

If you’re using a Windows 7 VM you’ll want to disable DEP and ASLR. There’s a few ways to do it including changing some registry keys, but my approach was to use Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). Also be warned that often something vulnerable on XP/2003 won’t work on 7 because the JMP ESP addresses will contain bad characters.

A big help to me, after I watched some videos and started to remember exactly how the stack works was to run through a bunch of the vulnerable programs on Freddie’s skeleton exploits, half done exploits, etc all helped me get through each stage.

But before you jump into half done things, learn the process from start to finish. Highly recommended and for good reason is Georgia Weidman’s course on Cybrary and also her book. A little birdie told me she’s coming out with a new edition of the book and I’ll tots buy it.

Start polishing your skills or just start out doing things well by checking out dostackbufferoverflowgood and going through the PDF. Justinsteven does an excellent job on explaining things and helping you learn some tricks that will make doing a BOF easier.

So what you’ll need to know for the exam – do the buffer overflow in the course materials, do a bunch more. Be able to run through it start to finish in an hour. You’ll hear a lot of “watch out for bad characters” advice, so learn how to identify them and also learn what sort of services have special characters that have a purpose. An FTP server probably has different bad characters than an email address. Read the RFCs for both. But definitely learn how to identify bad characters the old fashioned way and think of some new and creative ways to identify them. If you’re almost all the way through an array and you have 25 bad characters then you’re doing something wrong, start over.

Now, don’t do what Danny Don’t Do does – I got very proficient at BOFs before my PWK lab time started and touched them twice after my lab time started. After three months, I got a little rusty. That easy 25 points in an hour turned into three hours for me and was slightly de-motivating. Stay sharp. Stay frosty.

Stay frosty

And in case you want to see some fine examples of really poor coding and even worse project management check out the exploits I wrote/modified:

OSCP pro tip: Learn to use git. Make a private repository. Part of the reporting for OSCP is showing what changes you made to an exploit, git makes that easy by committing the changes and viewing the differences.

Hello world!

Since I finished PWK and passed OSCP. This is my obligatory blog that I had to start detailing my journey to achieving that sweet sweet entry-level cert.

I popped, I popped, and returned that cert’s initials to behind my name.