How to OSCP Labs Part 2: Lab Time & Standards to Meet

So this is my second part of my OSCP Lab series, where I provide hopefully important info on OSCP labs.

By now, you should have already gotten your VPN pack, decided on a strategy, and started studying/hacking. What this article will do is to give some of my (unreliable) advise on what to do when you are deep in the labs.

Nothing here should be a spoiler, everything else can be found online (some even on the official website)

But first, lab report related announcements

One important thing that I almost missed from my report is this:

Each machine's proof.txt must be shown in a screenshot that includes the contents of the file, as well as the IP address of the target by using ipconfig or ifconfig

So yeah, this is the end goal. Don't exploit all the machines in the lab, but forget to screenshot the important things when you are writing.

The lab report is submitted with your exam report, and not at the end of the labs. This can be a good thing. You can write your report after the lab time expires, though I wouldn't recommend it in the event of any mishaps (for example, if something like above happens).

The standards of the lab report needed can be found here

Lab Machines

Let's go through

The Penetration Test

These here are actually some general tips that I learnt from many different platforms, such as TryHackme and HackTheBox.

1. Network Scanning

Autorecon makes life easy. But not that easy. There is a lot of output to filter out. I used autorecon to scan the public network, but I ended up redoing some of the enumeration manually.

For the internal networks, SSH pivoting works well enough most of the time. I mostly did manual enumeration with that. I think you could try autorecon with proxychains, though you would probably need some form of configuration.

2. Service Enumeration

I would highly suggest using some of the penetration testing guidebooks online. They give a decent methodology on how to exploit certain services

1. https://book.hacktricks.xyz/
2. https://sushant747.gitbooks.io/total-oscp-guide/content/

3. Initial Foothold

There are a few kinds of ways to get an initial foothold

Firstly, you should look at TryHackMe/HackTheBox/ Proving Grounds/ Other CTF Platforms, which have these:

1. Service Exploits - Google hard, google wide
2. File Upload Vulnerabilities
3. Local File Inclusion - Can be for a custom web app/
4. SQL Injections - Not as common, but do indeed exist.
5. Weak Credentials - Look at default credentials, rockyou.txt, username and password are the same? etc.

So what more does a lab environment entail?

1. Dependencies. There are indeed reuse of credentials
2. Client Side Exploits. They do happen.

If you have not done a penetration test in a lab environment before, it can be hard to adapt. For me, I did not really pwn any machines with dependencies (except the AD ones).

What I will say though, is that don't over think the dependencies too much (unlike me). Most of the boxes are still relatively standalone. For client side attacks, they will be noticeable (eg. the person in charge will come and view the file? wink). Only if you exhausted all your options for exploiting the services (or if there are no services to exploits) will this play a big part.

4. Privilege Escalation

PWK labs to me isn't the best place to practice privilege escalation. What I mean by this is on too many accounts, I enumerate all the methods & files I can think of... Only for it to be a Kernel exploit, which is supposed to be your last resort. On many machines, privilege escalation is not even necessary, not the best idea for an exam which actively tests it.

However, there are some places where privilege escalation techniques are tested that are NOT in the pdf. Like in the previous part, following the required privesc courses should get you by. Basic enum scripts, looking at special files, processes and services, and more.

5. Post Exploitation

For me, I haven't really done too much post exploitation. However, the basics of post exploitation include

1. Getting Credentials. Mimikatz is your best friend
2. Looking through files. Program Files

There is also pivoting. Even though it may not be tested much in the exam, Don't get lazy on pivoting! Some boxes behind the internal networks are actually gold, and help you learn a lot.

I also pwned the AD labs (with some help from the forums in getting a foothold). You should definitely revert the boxes before starting them. To me, I felt they were relatively standard (though I'm not experienced enough to say that)

Tools and you

With dated machines comes requiring dated tools.
More than once, I have encountered machines where new tools would just NOT WORK. Only by looking at hints would I figure. This is super annoying, especially when some of the tools are the BEST/ONLY WAY to exploit a machine. Hence I'm going to advice you on what tools you should keep in mind

1. Metasploit 6 no longer supports older versions of Windows. If you are using it for some machines, DOWNGRADE it to MSF5. Here's a free tool to help you do so easily
2. Mimikatz has had some issues working on some versions of Windows. Use version 2.1.0 and below.
3. Kernel Exploits. Learn how to compile kernel exploits for the specific Operating System Version. I won't say that I have mastered it myself, but you won't be able to find binaries online all the time like in here.

Stuck? Try Harder!!!!!!!!

Yeah I'm not that much of a fan of the Try Harder spirit. In an ideal world, you have all the time you need to try harder, and trying harder will indeed result in learning. In reality... OSCP Lab time is expensive, more expensive than VHL, HackTheBox, TryHackMe, Proving Grounds (which I heard is superior for OSCP anyway). I don't think mindlessly trying harder will be a good use of money and time.

That said, instead of just "Trying Harder", this is what I believe in

1. Try everything

In my opinion, this is the biggest takeaway from my lab experience. Have a methodology, stick to it all the way. However, you may not exactly know what everything is. Here is my 3 steps to trying everything

1. Get ALL the services & the versions that are running on the machine. Google ALL the possible exploits.
   • eg. Web Server, Service running on the web server, Python stack, MongoDB Server.
   • You can enumerate the versions from nmap scans, folder names, files, etc.
2. Make a methodology. Even better, a step by step checklist on what to do
   • eg. on web servers, have to read all pages of source code? Directory Enumeration? SQL Injection Testing?
   • The absolute last thing I want is to try everything, look up the hint, only to find that the remaining thing is something so simple and obvious.

2. Try Again

Don't be like me, just look at a machine for 2h, say you have no idea on what to do and give up. Hacking takes a lot of time.

1. Stick with it. Take breaks to work on other machines if needed (though don't just hop between machines)
2. Revise everything you have looked through. When you get back to a machine, chances are you will forget some information which may be useful.
3. Repeat your enumeration/ exploitation steps. Try
   • After you reset your machine
   • With a different enumeration script
   • and more!

These are just some general guides. I believe that what you should do is not just take Try Harder at face value. Instead, break it down, figure out how to do better, put your own twist on it. Offensive security has a post on what trying harder means to them. I've also heard the phrase "Enumerate Harder", which sounds good to me too.

Hints

However, when you have followed your methodology through, and are stuck on a machine for way too long, maybe you can use hints.

If you want writeups, you probably can dig up some online somewhere.

The forum is the closest you can get to actual writeups. However, it is also NOT free writeups. Even after looking at a comprehensive hint, you may still be stuck, you may still spend hours. Some machines (like 1nsider, adam) would still take time for me to exploit, even if the pathway is obvious.

Others

1. Revert when starting a machine
2. For me, since I have to revisit some machines, I made autoexploit scripts, just in case. Most notably, for the double pivoting.

My personal experience

During my 60 days lab time, I pwned 48 machines

1. 24 were pwned without help
2. 4 were spoiled for me due to a google search/ leftover files
3. 5 + 1 were pwned with the help of the Learning Path/ Hints
4. 14 were pwned with the forums help

Others

1. Got the flag for 2 machines, without a shell (so not a pwn)
2. 1 only has a low priv shell

I tracked my progress down in a Google Sheet as such. I feel that this is good to build confidence in the machines you are pwning and keep track of the techniques you have learnt.

Judging from the standards of the labs (with my personal bias), I would say that pwning 20-30 machines is substantial enough, but of course the more the better. Some of the other machines may be too reliant on dependencies/ client side exploits etc.

End

I have just recently finished my OSCP Labs. Right now (as of writing this article) I plan on doing more practice, and taking the exam in about 3 months time. I'll probably take a break, do more VulnHub/TryHackMe/HackTheBox, start Proving Grounds etc.

Maybe the next part I write will be about the alternatives to PWK Labs for OSCP Preparation.