#!/bin/bash
This is not your average golden story. In fact I want to avoid writing yet another OSCP experience post about yet another first attempt victory because there are so many of those already. Instead, this blog post will focus firstly on what I believe it means to “Try Harder” and secondly how I discovered the subtle but important difference between being able to follow ones own methodology, and actually understanding why the methodology ended up the way it did. Before we begin I would of course like to mention that I rooted 4/5 boxes within the first 12 hours, finished my report and got the congratulating email about three weeks later. It just wouldn’t be an OSCP experience blog post without this note now would it? :)
Without further ado, welcome to the thoughts of a crazy parrot.
“Work on your methodology”, they said…
When going through the course and hacking my way through the lab, I often chatted with fellow students and current OSCP certificate holders about this and that. One of the questions which I frequently asked them is which topics I should focus on learning first and how I was able to tell what I needed to know. More often than not, the recommendation was to “work on your methodology”. I asked how I should go about working on it, and what a “pentest methodology” was exactly, but I usually received mixed replies. The common denominator however was to hack more machines and learn by doing. I was left feeling confused because to me it felt like I had asked how I learned to swim, but had then been told that the way to learn how to swim, is to try to get across as many lakes as possible with less and less help.
So I swam. I swam for hours and hours every night. In the weekend I swam even more and my goodness what a tough experience it was in the beginning. After a while - a month or so - I started becoming more independent. Another month went by and my notebook had grown with a lot of exploitation notes, useful commands and code snippets. I finally started feeling prepared for the exam, although I knew I still had to practice a few things (more BOFs, writing a report and such). A few days before my 90 days lab time ended I believe I had cracked the code of what it means to “work on your methodology”. What it meant to swim. In principle it is actually fairly simple once you realise what it is you’re doing. Simply put a “pentest methodology” is the ability to approach known as well as unknown problems with some idea(s) on how to either tackle or further explore the given situation. This perhaps sounds a little generic, but think of it as a set of options you have for each know and unknown part of the problem. If you recognise a part of the problem you may be able to apply the same (or similar) actions that you did in the past. If you do not recognise it, you may be able to futher explore the ins and outs of the problem at hand, potentially leading to new options. Visually speaking this can be seen as paths on the ground which you could walk down and potentially gain some reward at the end. Let me explain.
Picking the right path
Imagine that ahead of you lie n paths that you can explore. Each path represent an action that you are able to perform, for example using a tool, running a script or performing technique. In addition, each of these paths have some score indicating their likelihood to get you a reward of some kind. For simplicity, let’s suppose the path score is a function f(p) = L(p)/T(p), that is a function f of some path p, where L(p) is the varying likelihood that the particular action (path) will lead somewhere helpful, and T(p) is the usual time it takes to perform this action. For example, even if the www-data user is typically not likely to have sudo privileges, in a CTF setting it may be a very good idea to run sudo -l very early on to quickly either rule out that path for now or get an easy win. The path “execute sudo -l” therefore has a high path score because it is really fast to run (T(p)is low), despite the chance of success (L(p)) also being low-ish.
Let’s look at another example. Suppose that you have just finished an nmap scan of a target machine, and the following interesting ports were identified: 80 (HTTP), 139 + 445 (SMB) and 3306 (MySQL). Discovering these services automatically rules out a large amount of potential paths to explore, such as anything related to FTP as this does not seem to be present at all. Not yet, anyway. Experience has furthermore told me that MySQL is often never the first path to explore, but likely useful later on, giving it a low path score early on in the attack.
Now “building the methodology” essentially means paving a new path for you to explore, given some circumstance. As you may have guessed, these paths are not linear paths but rather tree-like data structures (like a family tree, starting at you). With experience you start remembering what you can try in different scenarios by heart, and you get a feel for which tests you should perform first, even if they are typically not the way to go. Take a samba share vs. a website as an example: often the way into the machine - especially in a CTF-like environment - is through the website either with or without help from SMB. However, since it is relatively easy to explore or rule out a samba share as being a good first step - compared to finding vulnerabilities on a website that is - this is not a bad path to start with. Who knows, enum4linux may reveal user information that is useful on the website or the share may even grant full access to some interesting directory for the world to explore.
As you can imagine, preparation and information gathering are important steps in the process of breaking into a machine or network. Often what appeared to be the optimal path to follow may turn out to be a fluke once more information is discovered and added to the grand equation. Remember that these path scores “update” themselves as more information is discovered either ruling some paths out entirely or pushing other paths into the spotlight. With this in mind, notice how I failed to apply my methodology efficiently in the first part of my exam, and how I slowly realised what my mistake was and what happened as soon as I applied “Trying Harder” correctly. One thing is building a methodology, another - as I discovered - is to follow it.
At last, the exam
The very first machine in the exam network that I attempted taught me a valuable lesson about my methodology: trust it, but don’t follow it blindly. I decided to use the buffer overflow machine to warm up for the rest of the exam, and I happily followed my well-prepared steps and made progress. Until I didn’t. I was confused and wondered if I had done something wrong. Was it stage fright? It wasn’t until I sat down and thought about why I was performing the steps I performed, that I realised that there was a twist. This wasn’t an examination in whether or not I could blindly follow some memorised steps required to successfully perform a buffer overflow, but a test in whether or not I understood why I was performing these steps in the first place. Once I did - once I trusted my methodology and didn’t follow it blindly - I made all the progress I needed and secured my first handful of points.
I guess at this point I completely wiped my mind and forgot all about about trusting but not blindly following my methodology, because I did the complete opposite. To my luck however, I soon after successfully compromised the “lesser” machine in the pool. I decided on a next target - the one I knew the most about (i.e. I had the most plausible paths to explore) - and quite quickly figured out what I had to do. I just couldn’t do it. Nothing seemed to be working, and even when I found a walkthrough of the vulnerable service that I could follow very closely and step-by-step, I wasn’t getting any shells thrown in my general direction. Nothing at all in fact. All I got was more emptiness for my empty feeling.
Thankfully, things were starting to click at this point about 4 hours into the exam. I knew from my methodology that I should try to replicate the steps in the proof of concepts, and that if they didn’t work I should try something else. I decided to take a few steps back and tried to gather my thoughts and what I knew about the machine and vulnerability. I tried to compare the “path scores” of the paths I had laid out in front of me, and realised two things. First of all, I was on the right path, I knew that much, but secondly things were not working because as with the other machines there was a twist. Of course there was a twist! Say it with me this time: Trust your methodology but don’t follow it blindly.
One would think that after three machines which were all compromised in the end because I trusted my methodology and didn’t follow it blindly, the final and fourth machine would be a walk in the park. Heh. I was stuck for another four hours doing initial information gathering about the two remaining machines. Why? Well, my methodology that I had build up over time said that if active discovery scripts like wfuzz and gobuster and the like don’t yield any results from the first two thirds of the directory-2.3-medium.txt wordlist (thank you, IppSec) then it’s likely not going to yield anything useful at all. That had been the case almost always in the past (I rooted ~35 machines in the lab, by the way), so it was likely not the case here either. Trust your methodo… you get where I’m going with this.
Eventually I got the first lead and from that point the remaining attack wasn’t all that complicated. I quickly identified what I needed to identify, I finally had learned how to use my methodology efficiently and I immediately knew how to overcome all the hurdles that I encountered during the final compromisation. I had finally rooted 4/5 machines and finally obtained (in theory) 80 points and could finally either get some well-deserved sleep or prepare my penetration testing report. I wasn’t going to get any sleep at that point that was for sure - quite honestly I was shaking all over my body and my heart was racing like mad, from pure exhilaration - so I spend a few hours on preparing my report and then went to bed when my nerves had calmed down again.
Trust your methodology, but don’t follow it blindly
If you’re still with me you have my deepest thanks. To wrap all of this up I hope that I have succeeded at least a little bit in expressing my thoughts about what my methodology and also biggest take-away from the course and exam. It has taken me a while to even be able to put words to what this new-grown “feeling” of mine even is. The feeling of weighing up the different paths with one another and exploring the most likely paths little by little.
Please feel free to reach out to me on Discord at @Birb#0001 with anything you might want to share. I will happily listen to your thought and feedback or further discuss anything you’ve read in here today. Once again, thank you for staying with me this far.
May the winds guide you.
- birb