I started with the PWK course to go for my OSCP. This series documents my progress. I hope to give some insight into the brutal proces and examn that goes into obtaining the coveted certificate.
In this post
- How do I keep organized with so much information coming in?
- Learn how to capture great screenshots using Shutter.
- What did I do this last week?
A good workflow is key
I am almost at the halfway mark of my OSCP journey. On twitter this series is getting quite some love, so that makes me a happy camper! Hello twitterverse!
Each week I try to highlight something that fits in the boundaries of the OSCP academic policy. So pretty much no details on the exercises and labs. I guess the first rule of PWK is that we do not talk about PWK.
So what else is there? I previously talked about my documentation efforts. I have created a completely text based system using pandoc that renders into beautiful PDF documents. I have the flexibility and friendliness of text based editing and the beautiful result of Latex generated PDF documents. I am quite happy with it as you might notice.
During the labs I have created a workflow that helps me process the large amount of information coming my way and to keep me centered on my methodology. Lets go through this process and see what it consists of.
As I am an avid Emacs user it might not be a big surprise that I do most of my work in org-mode. It allows for easy note taking and todo tracking. It is awesome for everything every day.
So, the first thing I have open is my document with all my notes on commands to run, notes on special services and details on the various exploits I have used so far. I call this file
Methodology.org. This file changes while working on the labs as I learn more and more tips and tricks. In this file I, for instance, have a reference of all the ways I have spawned some form of interactive shell, be it through
Next is my file, per network, that has my notes per machine. For the Public network this file is called
public.org. Each machine is a top level heading and I create subheadings for each phase of my process (
post exploitation) and I put the output of all commands in literal blocks. This way, if I want to check how I did something on another machine all I need to do is to search in my document.
Screenshots form an important part of the documentation process. Offensive Security actually has a screenshot heavy reporting process so that non-native speakers like myself have the ability to completely show what was done. For screenshotting I use a tool called Shutter.
Shutter allows you to take screenshots, edit them (boxes, pointers, lines, etc) and manage them (throw them away, rename them). I store all my screenshots while working in the
~/Pictures directory. There is nothing else in here. I have set Shutter to store all screenshots it makes into this folder automatically. When I take a screenshot I immediately rename it to something that makes sense in the documentation proces,
|ID||A unique ID for the machine in the document, currently I just use the last octet of the IP address|
|PHASE||The phase of the test, such as
|DESCRIPTION||An easy to identify description of the screenshot, for instance
When you follow this guidance you will end up with nicely grouped screenshots that can easily be included into the markdown files used by pandoc.
But making screenshots by default is a little bit of a hassle, as there are no default keybindings for it. So I configured my desktop to use
Ctrl-Shift-P to invoke
shutter and to take a screenshot of a window of my selection. There is also the possibility to make a screenshot of the active window, but my experience is that it sometimes misses the mark completely, so I chose to just select the screen myself.
I also configured Shutter to wait 1 second to take a screenshot, because it sometimes would make a screenshot with the window selection still active (the green overlay it uses to select a window).
When the screenshots are in Shutter I will go and highlight specific areas using the
Edit functionality. You can add boxes, lines and arrows. Take a look at the screenshots below to get a sense of the thing.
I actually got to spend some time Saturday night as well, so a few more hours were added.
- Actually owned the machine I was working on, so now 8 machines, 5 owned
- Times below have been updated from 22 and 1/2 hours to 24 and 1/2 hours
This week I spent 24 and 1/2 hours on the course. It has been a massive week! In total I have spent 5636 minutes, or 93.9 hours working through the exercises and the lab.
This week I worked on 8 machines, of which I owned 5 completely and 3 are a work in progress. Sometimes you start working on a machine and then you pivot to another part of the lab. I am very happy with my progress, seeing that this list might contain one of the more difficult machines, if I read the forums right.
I should note that this time includes the time needed to fully document my findings. So the 8:30 hours on that one machine includes 1:30 hours documenting and trying different approaches.
|Machine 2 [O]||2:15|
|Machine 10 [O]||2:00|
|Machine 13 [O]||3:10|
|Machine 14 [O]||8:30|
|Machine 15 [O]||2:30|
In my weekly graph you can see that the time spent this week exceeds any of the previous weeks. This might also be because I not once was able to go to bed before midnight. The labs are so addicting!
I am planning on revisiting some of the old machines to get them into my report correctly. Other then that I am just sniping away at the host list.