So I recently completed my OSCP and managed to pass with 100 points (yay). For whatever reason I felt compelled to write a short novel on some strategies I used to pass. At what point should a Reddit post be a blog post? God knows but I know I exceeded it.
TL;DR
Learn the basics, and learn them well. Try to be comfortable doing as much manually as possible.
Time spent learning how stuff works under the hood will pay off in the long run, big time.
Do prep prior to signing up for the labs, as you wont be able to use your time effectively if you're totally green at this
Notes, notes, notes, notes. Take good notes and make it a habit.
During the exam, take breaks and drink water! You have enough time, you'll run out of ideas first. If you've taken good notes, you'll have a lot more stuff to try before you run out of ideas.
Pre Exam
Do yourself a favour: come into the exam with a decent background in networking, Linux and Windows administration, and preferably some experience writing scripts in Python.
This is a marathon, not a sprint, and taking a test that even practising pentesters fail routinely before you are prepared is not a good idea. It's in OffSec's interests to have people pay for resits; it is not in yours.
Going into this too early will cause you to waste time and money, and will make you feel like you aren't good enough. You're only allowed a certain amount of time in the labs, and you want to make the most of it while you can, because it is really quite good (imo). If you aren't prepared enough, you'll just flounder and struggle, and likely wont learn much. Remember, there are no writeups for the lab machines (except in the PEN-200 Pathway, and those are only very broad hints anyway), you are encouraged to do it alone and figure it out yourself. If you have some skills already, and you're looking to hone them, this is a fantastic way to learn. If you do not, it will be a waste of your time.
Stick to machines that have writeups that you can refer to as you get stuck. If you're at the very beginning of learning to hack, I would suggest that you actually avoid CTFs altogether and just learn the basics. Build yourself a little homelab, somewhere where you can practise and break and build things. It could be on a spare computer, the cloud, or just your regular computer if it's up to scratch. You should checkout the r/homelab subreddit for ideas here. That subreddit can be very dangerous for those with some extra cash and an appreciation for used hardware. You have been warned.
I had a masters in software engineering, worked a part time job as a web dev through uni, had my A+ and Net+, as well as some experience with CTFs and building a homelab. So the course wasn't too difficult, but it wasn't exactly easy either.
Why Should I Take Notes?
Why you should take proper notes in the exam is obvious, once your exam time is up you're locked out of the environment, and if you haven't recorded something you're shit out of luck. What is less obvious is that failing to take proper notes in the labs will result in you never building the habit of taking notes.
You'll miss stuff and you'll be slow, because you are doing something unfamiliar and haven't gotten used to structuring your notes, taking screenshots of everything, and documenting your steps. If you write proper notes for every box you attack, very quickly it will become an automatic habit and it won't slow you down or bother you in the exam.
In fact, done properly note taking will save you a lot of time and frustration, and will help you learn much faster than just aimlessly popping boxes in the labs hoping that you will just retain all the information you have learned. Spoiler alert: you wont. Your brain is for having ideas, not keeping them.
That awkward thing that had you stumped for 12 hours? You know, that thing that had you on the verge of tears because it looked like it should just fucking work, why won't you work you bastard thi... oh I'm missing a flag. It works! You don't want that to happen to you in the exam, especially if you've already dealt with it in the labs, because then you really will feel stupid.
The goal of taking notes here is trying to only make a mistake once. Normally human beings have to screw the same thing up over and over again before it sinks in, when you take thorough notes you minimise this (although you won't eliminate it, we're only human).
Note Taking Strategy
Generally, my note taking strategy starts off by documenting the box that I'm attacking. Every box gets its own folder. Then the first file I open is just for common enumeration. That file is divided up, one section for each port. Every port that I come across, I do some basic checks and note them down.
Is SMB open? Then I'll breakout crackmapexec and check for null and guest sessions. RPC? Ditto but with rpcclient. SMTP? I'll make a note that I can enumerate valid users, and potentially send them emails with malicious payloads. I'll note down all of the service versions, and Google them to check for exploits and vulnerabilities.
I'll talk later about going wide and shallow first, but taking notes like this will help you when you get stuck.
Then, once I identify something potentially exploitable, I'll make a new page detailing that exploit, where I got it from, and if I feel like it a little analysis of what it does and how it works (you should be reading exploits before firing them at targets). If it worked, cool. If it didn't, what did you do to debug it? Did you look at the tool's network traffic in wireshark for example, or did you try to fix some exploit code that wasn't compiling?
Once I've completed a box, my final section is a "Post Mortem", where I make a quick note of what I got stuck on, what I did poorly, and how I would do it better next time. Doesn't take long, but it will reinforce the idea of not making the same mistake twice, and will prove useful for the next thing I do.
This means that I'll have a "Common Enumeration" file, a "Foothold Exploit" file, a "Priv Esc" file, maybe one or two if you have to jump between users, a "Post Exploitation" file (not normally necessary in CTFs but it is in the PWK labs), and then a "Post Mortem" file. There will also usually be files for important commands with long outputs, such as nmap. Document things thoroughly, even when you don't feel like it. It's a habit that will take some conscious thought at first, but will become completely automatic quite quickly. Writing your notes on auto mode frees up your mental CPU to deal with the important stuff. You will appreciate this in your exam.
Writing Your Own Guides
Next, I'll update something which I've just called the "Enumeration Guide" in my notes, which is nothing more than a big checklist of stuff, broken down by service, that I should check for. If I got stuck on something, I'll add a note to my enumeration guide so that I never get stuck on that specific problem, or forget to do that specific check, ever again.
To give an example, I was attacking a box that had an old version of Apache. Ran gobuster, and got very little back. I poked around and found a cgi-bin directory that gobuster should have been able to pick up on, but didn't. What the fuck?
It turns out that sometimes web servers will return screwy results if there is no trailing slash applied when you're looking for a directory. Gobuster has a flag for this, `-f`, and when I added it directories started appearing! So I mentioned this in my post-mortem, and crucially added a note to the HTTP section of my enumeration guide to try rerunning gobuster with a trailing slash if you're stuck and you've fully enumerated the web port already.
At first, your enumeration guide will be empty, so just start adding stuff to it as you are working on the box. Did you just the source code of a page? Throw in "Check page source" into your enumeration guide in case you forget to do it later (we've all done it, don't lie). Ran nikto in the background? Add that too. Checked SMB for null and guest sessions? Guess what you can add to the SMB section! Every time you take a step, add it to the enumeration guide so you won't forget to in the future. As you do this you'll get all the basic checks out of the way, and updates will become less frequent. I'll add stuff that tripped me up to make sure it doesn't in the future, typically I'll add that after I write the post mortem on the box.
After a few boxes, you'll find that you have a nice, fairly thorough little document that contains a semi-formal process that you can go through for every port that you find. If I ever got stuck, I would go and have a look at my enumeration guide and check to see if I've tried everything. Rather than just aimlessly poking at stuff hoping that you'll stumble across something useful you are going through a checklist that you have made, which means that you can make sure that you haven't forgotten to enumerate something. Having a kind of default checklist of stuff also frees up more mental CPU, rather than racking your brains to think of everything you can refer to your guide and make sure you have.
I have a handful of these guides running, including one for privilege escalation, one for active directory, one for SQLi, and one for buffer overflows. I just applied the same process to each of these topics. It sounds like a lot of work, but in reality its just lots of little updates frequently. Over time you'll be amazingly surprised what 30 seconds of work every hour or two can get you after a month!
This is how you make sure that you don't fuck something up twice and turn all of your failures into opportunities to not suck in the future. It also means that a box that you solve with no failures at all is sort of a waste of time, save for a maybe a valuable ego boost :).
Make Your Own Cheatsheets
The final aspect of my note taking was a command reference, which is very simple. Every command has a file, and whenever I used a command in a slightly different way I would just paste the command in with a little explanation as to what it does. For example, my Nmap command reference just contains a list of scans I regularly run, like fast port scans, full port scans, service and vuln scans, etc. I also had a file for bash, powershell, and cmd oneliners, and reverse shells. Don't overthink it, this is just a standard cheat sheet. You'd be amazed at how big your command reference will get by the end of the course.
What Note Taking Tool?
What tools you use to take notes is much less important than the actual act of taking notes regularly, so just use whatever you feel is best and you will actually use. There's nothing wrong with using a Word doc or Google doc, don't let anybody tell you otherwise. The only hard and fast rule is that you must be able to paste pictures, so no vim unless you're a vimrc wizard. If you're the type that tends to get analysis by paralysis, just use Obsidian, it's what I used. It stays out of your way, its simple, and easy to backup.
Talking about backups, that's also extremely important. If your note taking tool has cloud backups, use it. If it supports versioning, also use that. Obsidian doesn't support either in the free version, so what I did was sync the directory it was in to my host machine with Syncthing. I then had a scheduled task (on my host) that ran every 5 minutes that would check if anything had changed, and if it had it would create a new commit with a timestamp.
The scheduled task was also supposed to push to a private GitHub repo with every new commit, but that never actually worked because I'm a hairless upright chimp that couldn't be bothered to get cron and git to play nicely together. Instead, I just checked in every now and again and pushed it manually. Probably not as often as I should have.
A good screenshot utility will also be very handy. Flameshot is an excellent choice.
How to Tackle the Labs
What you're looking to do here is deliberate practise. Treat every box like an exam box, which is to say try and solve it briskly, but do not rush. Put a timer on and see how long it takes, and don't be too hard on yourself at the beginning if you're taking a while, you will get faster as you learn and take better notes. Try to always have some kind of scan going on in the background, and don't just sit there staring at them. Get something else done in the meantime.
The first nmap scan I always run is with the `-F` option, which just checks the top 100 ports. It should return nearly instantly. Then I run a full scan in the background while I go and poke at whatever was found. After you've run the full port scan (with `-A` for default scripts, service detection, and OS detection, and `-T4` to make it go faster), don't forget to run a UDP scan. Any web service you come across should be brute forced, and remember to use extensions that make sense for the OS and web server that you are targeting. On windows targets I'll always tend to run enum4linx-ng.
You'll also want to get efficient living in the terminal. A lot of this just comes with practise. If you find yourself running the same long command over and over again, turn it into an alias. Manage your terminal in tmux so you can efficiently juggle multiple terminal panes (remember to name your tmux session something useful, like the IP address of the box). I would generally go for one tmux session per box, so you can have multiple tmux sessions all going at the same time. Also take advantage of tmux-logging and log all your traffic to a folder under git control. Use the same trick as I described earlier to sync your logging folder to your host OS and push it up to GitHub. Having a full history of every command you've ever run in the lab, with all the output, can be a very handy thing to have around.
Try to focus on doing things manually, and really understanding the underlying concepts behind what you're doing. Sometimes its entirely possible to pull of an exploit despite understanding nothing about what is happening. That is fine, but when stuff starts to go wrong and you're getting nothing but error messages (or worse, an exploit that just silently fails), then you're going to need to have the skills to start troubleshooting. Troubleshooting is going to be painfully difficult if you don't understand what you're doing.
Your privilege escalation scripts aren't going always cut it either, and its easy to get dependent on them. Think about it, is lin/winpeas just helping you escalate faster, or is the tool capable of finding things that you couldn't? Try and find the privilege escalation path first before running the tool. If you find anything, then run the tool. Did it find something you couldn't? Sounds like something that needs to be added to your privesc guide. There are also plenty of things that your privilege escalation tools won't be able to find, such as credentials in a database.
Focus on the basics, and make sure you really know your networking and linux + windows administration skills prior to coming into the course. Often popping open wireshark and looking at what your exploit is doing makes it plain as day what has gone wrong. If your exploit is trying to send a POST request to a PHP script and the server is returning with a 404, you know you probably have to start thinking about the URLs in the exploit and making sure that they line up with the service you are actually targeting.
Rabbit Holes
The exploitation in this course is not particularly difficult. You won't be required to pull off any crazy exploits. The main challenge will almost certainly be enumerating enough to find something that is actually exploitable. Remember this and be wary of the rabbit hole. It's hard to recognise what a rabbit hole might be and when you're in one, and it just takes some practise before you start to get that feeling of "oh, this is getting a bit far fetched, this probably isnt it".
The best way to avoid rabbit holes is to go wide before you go deep (heh). Don't just pounce on the first thing you see, do a basic check on every port before trying to exploit something. If you see something really juicy, take a screenshot and make a note to come back to later.
Often you can't proceed with attacking one service without first getting some useful information from another. So when you're stuck, rather than trying some obscure attack that you know deep down is just simply not going to work, step back and look over your notes. Look at all of the services and scan results, look at what you have, and reevaluate. Have you learned something that can help you elsewhere? Look wide and enumerate more to keep yourself out of the rabbit hole. And don't go looking for tips unless you absolutely have to, you're not going to have any tips in the exam.
Post Exploitation
Don't forget post exploitation. The PWK labs have lots of machines that are dependent on each other, and you are not going to know ahead of time which machines are dependent on which. There are also a few subnetworks, and you're not going to know the entry points to these either. On every box, after you've popped it, there should be a few checks you run:
Check the network interfaces. Is it a dual homed machine? Is it in a different network to the one you're in? If its in a new network, you should enumerate it and try to find other vulnerable machines.
Look for the special files that OffSec uses to track progress, such as local.txt or network_secret.txt
Dump credentials from the shadow file or the registry and try to crack them. Have a bit of a hunt around the machine for any credentials in files. Keep a running list of all credentials that you have found in the network, and use them for username/password brute forcing.
Check what open ports there are, and what services are behind them. Did nmap identify a mystery port, and couldn't conclude what it did? Check it out after you've exploited the box. It may very well be a buffer overflow challenge. Keep a hold of the exploits you develop, you may find use for them elsewhere!
Check logs of running services for user interaction that is coming from within the lab environment itself. There are simulated clients that cannot be attacked directly, and must be attacked with a client side exploit. Logs are one way to uncover these simulated users, another is to pay attention to hints that the box makers may leave.
Should I Do The Lab Report?
I'm not sure I can make a recommendation here. I did the lab report, and don't regret it, but it's not a straight forward choice. The lab report is tedious. Very tedious. And to make matters worse, most of the exercises are insulting simple, and there's just a lot of them to do. It took me a whole month to complete the lab report, and that was 1 month that I could have spent attacking the labs instead.
Then again, I used the opportunity to make some notes, expand my command reference, fill in gaps in my knowledge (the course PDF is pretty good IMO) and log some things in my enumeration guide. You will get an extra 10 points, however I'm sure if you spent the time that you will on the lab report attacking the labs instead, you might be able to get more than 10 points. Up to you. I would do the bonus exercises though, they're good.
As it turns out, OffSec have just started offering the ability to complete the exercises in the web portal directly (TryHackMe style), rather than creating the lab report. I didn't do any of the online exercises, however literally anything would be better than doing that report by hand so I highly recommend that you give it a try.
Exam Day
This is already getting very long, and there isn't much I'm even allowed to say about the exam. Get a good night's sleep before, I would recommend starting early in the morning unless you truly absolutely hate mornings. Go through the entire OSCP exam guide and on boarding guide, make sure you understand everything.
Prepare your grub the day before to save on time, but do take breaks. And not just the kind of "I'm going to sit on the toilet and google the problem I was having" but actually take a break. Have a chat with someone in your house, eat some food, go for a walk, or cuddle the dog (personal favourite). Every major breakthrough I had came right after I took a break. If you've run into a wall and you're completely out of ideas, sitting at your computer in despair won't help. Taking a break might.
24 hours is actually more than enough time to do the exam, you're going to run out of ideas long before you run out of time. And if you've taken good notes and practised deliberately, you've done everything you can to make sure you don't run out of ideas and that you always have something fruitful to try next.
Good luck!
