A long time ago in a more civilised age

I’ve been working on the technology industry for the last 17 years, planning, designing, building and operating solutions since I was able to access the internet. I’ve been working the last 10 years as a consultant architect (across a number of domains) working with clients to understand their businesses, their technology needs, current deployments, gaps, road map and create solutions to enable their businesses, but you can’t do that if you introduce risks to businesses by creating unnecessary and unwanted security risks.

I’ve delivered services directly for and as part of a supply chain for a large range of organisation verticals from global media organisations, logistic firms, retail, telecommunications, media & entertainment through to local authorities, central government agencies, armed forces and the metropolitan police.

My first entry into the cyber security real was when I was a fair bit younger than I am today, I helped clean a local printing companies PC’s from a virus (this was back in the day of specific cleaning tools held on floppy drives!). I started networking and learning HTML (and other web protocols and languages) and all the things that went along with discovering the internet back in the day which included learning how to protect (and some limited attack) endpoints and servers. I’m not going to regale every project I’ve worked on but since my early internet days and the start of my career but suffice to say in my support and operations roles through to my architecture and consulting roles, secure service has been a constant. Around 5 years ago I started getting heavier into offensive capabilities from a professional point of view and started to improve my skills (mainly driven by the requirement to demonstrate services were secure and my personal interest in the offensive world). After gaining the pro hacker badge on hack the box and not faring too badly at the 2018 Cyber UK CTF, I decided to sign up to take on the OSCP challenge. This blog series documents my experiences going through the OSCP labs and hopefully succeeding at gaining the certification.

Starting the OSCP journey

My PWK lab access and course material access arrived on a Sunday, I had family commitments and just happened that I was feeling under the weather, but I pushed on and downloaded the materials (you only get 72 hours to get your stuff or it gets deleted!). I decided I was going to try and not jump straight into the practical side and watch the videos and start reading the course and exam guides so that I knew what I was going up against as I knew there were some restrictions on what you can and can’t do (for example you are allowed to use Metasploit and Nessus (read commercial automated tools) in the lab but are forbidden in the exam (you can use msf to launch an exploit once, but can use the multi handler!). For more info check out this link on OCSP exam restrictions:

https://support.offensive-security.com/#!oscp-exam-guide.md#Metasploit_Restrictions

The videos are easy to follow and well presented, I’ve not yet gone through every video but there’s seems to be about 8 hours of content. I’ve been juggling finance, marketing and sales activities alongside holiday planning, blogging and doing the learning thing so my OSCP time has been quite limited so far. After doing a fair bit of prep on the theoretical side I decided late on the Thursday evening to log into the labs and start enumerating all the things!

The OSCP PWK Lab Objective

Aside from learning penetration testing skills, the main objective of the labs is to work through from the public/student network through to the administrative network as shown in the diagram below.

It’s important to bear in the mind while this may seem similar to a CTF the concept is to deliver security outcomes (i.e. find vulnerabilities and report them in clear and understandable manner). This bought a smile to my face as that’s just how consulting works in the real world, whilst you need to be able to explain the technological wizardry, it needs to be delivered in a way which enables a business (i.e. reduces risk, increases market attractiveness etc.)

Going manual

So, my first view in the labs was that I need to make sure I don’t break the exam rules (I know you are allowed to in the labs but running a Nessus scan would make the learning experience a bit shallow for me, I’m here to get my ass kicked and try harder not have an easy ride). I started writing a load of enumeration scripts to search for low hanging fruit. Here I mainly used some bash scripts combined with NMAP scans (much like the vids and course material advise). I started to search for targets that I would look for in real life and drawing a Visio diagram of the target network and endpoints. I’ve already started to find some potential targets which look like they may have entry points to other network segments.

Whilst I was mapping out the network and devices, I decided to tackle a box head on. I’m not going to be able to go into much detail here however but I’ll to give an overview on the approach I took to not only pwn the box but also get more than just the proof.txt (flag) file.

• Document
  • Keep a record of what you do, how you do it, the commands you run and the output
  • I often use OneNote (web version through Kali) but for the PWK labs I’m following the recommendation from Offensive Security to use KeepNote
• Enumerate
  • Scan all the common ports and do version detection
  • Do a full scan in parallel in the background (but start working through services from a quick scan)
  • Use nmap script engine (NSE) to search for vulnerabilities
  • Use searchsploit to locate potential vulnerability exploits
• Weaponize
  • Remember you need to go manual on most things so look for exploit code that is written in Python or other languages such as C etc.
  • Github is your friend here
  • If you need to create shellcode use MSFVENOM (this is unrestricted in the exam)
  • It can help to spin up a replica of the target on a VM if you have the time and resources to do so. This enables you to confirm the attack path and exploit before you live fire
• Exploitation
  • Run the exploit against the target, it’s a good idea to run Wireshark before this so you can see traffic in both directions
• Privilege escalation
  • If you haven’t got a privileges shell first (most likely you won’t but on the first box I hit I got SYSTEM straight away), it’s a good idea to use enumeration scripts to hunt for privilege escalation routes
• Post Exploitation
  • The OSCP lab machines have a proof.txt file which is required to prove you have owned the system however don’t forget to hunt for more loot. You may find sensitive files which will help you write your report but also may help gain a deeper foothold (e.g. password re-use etc.)
  • Search for potential pivot points
  • Remember you need to be able to transfer files to and from the target
  • Some files may be encrypted so get your JOHN the ripper and other cracking tools fired up!
• Reporting
  • Keeping a clear record of what you found is important (as above) but once you are complete remember you need to write up the findings and recommendations in a formal report document

This list isn’t exhaustive but hopefully gives an indication as to the steps that are required. I’m going to build a cheat sheet to help with common commands etc. (there’s already a ton of these online but I’ll be creating my own as it helps in the learning/remembering process)

Trying Harder

So, there’s my first week (In reality I’ve spent about 3 days active time) studying for the OSCP. Hopefully this has given people a decent insight into what the OSCP course looks like. If you were expecting a penetration testing by the numbers course this isn’t what Offensive Security have created. In the real world you don’t get flags or hints, so this is far more realistic with that regard. Right I better stop writing at get back to trying harder!

See the journey continue in week 2! – My OSCP Diary – Week 1