Saturday, 14 October 2017

OSCP as a Digital Forensic/Incident Response Analyst

As a DFIR analyst, I have predominantly worked on the responsive side of cyber security. I have been lucky enough to work for employers that support good quality training and certification - however training for me has usually been geared towards forensics and incident response in line with my role.

With the desire of expanding my offensive knowledge and experience, I decided to take the Penetration Testing with Kali course - a lab based penetration testing course. I initially purchased 2 months access.

Whilst I had read that it is a difficult course (depending on experience), I did not comprehend the learning curve, fun and frustration of what I had signed up for...

A part of this ignorance was derived from the fact that I could not find a write-up of someone with similar experience attempting the OSCP. So here we are.

Experience/Education

I completed an undergraduate in Cyber Forensics and Networking (double major), following which I have worked in cyber security/DFIR for 4 years. My formal training and certifications are all DFIR focused (X-Ways, AccessData, GCFE, GFCA).

I have a good grasp on python/powershell scripting, however would never call myself a programmer.

I had never conducted a penetration test.

Course Preparation

Unlike others, who practice metasploit and vulnhub machines prior to the course - I did not prepare at all. I had heard the quality of the course material is good, so I decided I would learn from there.

I found this approach worked for me, and I would be cautious if you plan on specifically learning some topics prior to OSCP with the intention of bypassing the course material. The course material is well structured, comprehensive enough and many specific methods detailed in the course material are directly applicable to the lab environment.

The Course Material

The course material consist one large PDF file and a series of videos. These complement each other, with some video content referencing the PDF for more details and visa versa.

I spent the first month working through the PDF, video material and lab exercises. If I were to do this again, I would put the effort in to complete this within 20 days to get more time in the lab.

Tip: Read the lab reporting documentation requirements and document your lab exercises as you do them. This will save you time later if you intend on submitting a lab report with your exam for an extra 5 points.

The Labs

The best part about the course. The labs consist of a multi subnet environment which you may work your way through enumerating and exploiting 40+ systems of various operating system, service and application configurations.

Initially I struggled with the concept of enumeration. This surprised me.

When performing forensics, I am very process driven and methodological. If I find an artefact that indicates a particular action or execution, I hypothesise, look for supporting evidence, look for refuting evidence and  'paint the picture' before attempting to draw a conclusion.

When I started the PWK labs, I found myself jumping on the first potentially vulnerable port I identified. I would get excited and skip to the exploitation phase in hope of cat/typing proof.txt (a file only accessible with administrator/root privileges used to prove system compromise in the labs and exam) and crossing the system off my list. It took me a few weeks to realise that this approach was resulting in many nights of zero accomplishment and my time in the lab was quickly running out. I found myself feeling defeated and stressed that I wouldn't complete the course in time. I was right, and ended up extending my lab time for an additional 2 months.

It was only at this point in time when I realised (really realised) that offensive security required a similar methodological approach to DFIR. Rather than identifying the actions performed, vector of infiltration and (sometimes) the adversary- I needed to do the reverse!

I started with this step by step enumeration methodology (written by 'unfo').

After rooting 2-3 machines using this methodology, I found myself slightly adapting it to incorporate some tools for efficiency (e.g. Sparta). I soon found myself writing custom scripts to identify attack vectors (e.g. Linux Poison-able Log Finder). Crikey mate now we are pwning!!!

Things only got better from here, and my success in the labs improved significantly. I began pwning 1 PC most nights I sat down (I generally sat down 2-3 hours at a time). I was feeling good.

Unfortunately I had a holiday booked (I had initially planned to have the course done in 2 months), but was feeling good about my process so I booked my exam. On return from holiday I would have 1 more week in the lab, then 2 weeks before my exam.

On return from holiday, I spent the week re-compromising 10 machines and writing my lab/exercise report to submit with my exam report for the addition 5 points. I would recommend doing this earlier, as I remember thinking I could really use this time to pwn more lab machines.

In the 2 week break before my exam, I took things a lot easier. I worked through the first two lessons of the Corelan buffer overflow tutorials (highly recommended) and pwned some additional Vulnhub machines.

The Exam

The exam consists of 23 hour and 45 minutes of lab access, followed by an additional 24 hours to submit an exam report. My exam commenced at 15:00 on Saturday. I had a good night rest on Friday and spent the morning cooking meals for the next 48 hours and printing cheat sheets.

My plan was:
  • Work for from 15:00 to midnight. If I had pwned 3 machines, go to bed, if not, put in another hour.
  • Wake up at 05:00 and work until the lab cut off or I had 5 rooted machines.
  • Set my alarm every 2 hours (except sleep). Whenever the alarm went off, I would ask myself how long have I spend on this activity? Is it a rabbit hole? Do I need to change direction? Do I need a break? This approach helped me greatly.
  • Have a break (minimum 10 minutes) each time I rooted a machine. Walk around the block and get some fresh air.
Goal:
  • 70/100 points to pass
In the first 2 hours I had an important 25 point box rooted. Within the next hour I was able to exploit an easy 10 point box.

After this, progress slowed. I gained a low privilege shell on one machine and spent too long trying to escalate. I faced some new challenges with the privilege of my user which I hadn't faced in the labs before (likely because I hadn't worked through all the machines) and this slowed me down. I ended up going to sleep at 01:00 feeling uncertain.

At about 03:00 (when attempting to sleep), I had a lightbulb moment and realised what I had missed. I went back to sleep till 05:00. At 05:15 I had root on this machine.

In the following lab time I was able to pwn another machine for the points needed to pass. I slept, wrote my report that night and proof read it in the morning.

I encrypted my exam report with my lab report, decrypted it, checked it wasn't corrupted (offensive security won't tell you or ask for a new report if your submit a corrupted copy) and sent it off to offensive security. In 22 hours I received confirmation of passing the exam!

My 2 cents

I realised that the approach required to be a successful penetration tester is similar to that of a DFIR analyst. I also believe that DFIR and offensive security skills are complimentary, and having experience in both areas can make any DFIR analyst or penetration tester better at their respective role.

I believe that the OSCP is great value for money if you have the time to commit to it. I also believe that it is an effective, yet inefficient way of learning the core concepts offensive security. Through this inefficiency however, you are forced to learn how to troubleshoot your own attack process, get creative and.... try harder (the OSCP mantra). This is arguably just as important (perhaps more so) than understanding what buffer overflow, SQL injection, LFI/RFI etc. attacks are - should you want to be a successful penetration tester/hacker.


2 comments:

  1. Very informative blog... An incident response plan is a systematic and documented method of approaching and managing situations resulting from IT security incidents.

    ReplyDelete