Writer’s Note: My apologies for not getting this out in January, I started writing this blog post and wrote a spaghetti of stuff that wasn’t meant for this topic. I haven’t written in so long that it just sort of came out. It’s a lot of words without substance, so I apologize in advanceThis is a softball topic, if you have any questions or want to add to these feel free to make a comment or email me g3k AT disillusion dot US
So you’ve just finished kicking ass on this pentest. You got shells raining down like cats and dogs and you’ve got domain administrator and all the hashes from the client. Feeling amazing about yourself you crack open a beer and sit back and marvel in what you’ve just accomplished.
The next day you start the process of writing your report and you’re left wondering what kind of monster did all that work and didn’t make it easy for you to write your report. You curse your past self, “Damn him! Damn him to hell!! How did I get that shell? Shit, which exploit did I use?”
Sound familiar? I’ve been there; I’ve been there a lot. If you’re anything like me, you’ve either: blindly kept going in the same haphazard manner or you’ve done something about it to stay organized so that never happens again… No matter what your past self conspires to do.
This post is a beginning look into how to stay organized while conducting a pentest so that when it comes to reporting time you aren’t left deciphering a mess of tool output and half jotted down notes on napkins.
For me, the problem stems from not having a ton of life experience working on projects with a deliverable due at the end. I blame this on my hatred of school growing up and continuing to show that hatred by not going to college.
In previous consulting jobs, my deliverable was always my work, so I never had to work under this type of pressure. I hate reporting and I mean I HATE reporting. Everyone says that, but even when I have everything organized, catalogued and ready to go, I become a bundle of nerves. I usually find something I didn’t properly document and I’ll have to go back and sort of repeat what I did or retrace my steps. I hate doing that more than I hate reporting. Additionally, this isn’t something we are really taught. During my OSCP I was on point with my documentation, but when I got my certification, this didn’t carry oover to my career.
Talking to a few fellow OSCP holders, they experienced the same lack of carry-through. I’m not blaming the OSCP, but I think expectations of what a pentester does, when you are not one, are wrong. Starting my career as a pentester, I had a pretty rigorous onboarding experience, but nothing in the nitty gritty of all this. I had to seek out advice from coworkers and develop my own strategies.
As penetration testers, our work product is ultimately our final report we deliver to our clients. They come in many shapes and sizes, but ultimately every pentest report kind of looks the same. This makes it easy to make sweeping generalizations and assumptions! (My favorite!) This is a topic that I feel isn’t as widely discussed as the technical aspects of this job, but it’s just as important as being a leet haxor. This will be the first post on this topic and you can expect more to come as I learn more. One thing you have to remember reading this article is that this is basically how I feel I work best, if something doesn’t work for you, then don’t do it. The more conversations that occur the more knowledge is shared.
Anyway, lets move on from that and into the details of what we’ll be talking about today.
How to Store Pentest Tool Data
Since every tool we run has some sort of output — whether it’s during discovery, fingerprinting or exploitation — every thing outputs, even if by default it does not. How I organize the output of all my tools is fairly simple: I have a root directory called Engagements and it contains a directory for each engagement. The engagement folders are named in this format “MMYYYY-ClientName-EngagementType” like 012016-AcmeWidgets-Internal and inside there are separate directories for Reports, Data and Supporting Documents (SOW, contact info about client, etc). I store all this on my host machine and utilize one of the features of virtualization software called Shared Folders between my virtual machines and host. All tool output goes into its own directory named for the tool being used under the Data directory. This helps centralize all the tool data into its own space so it’s easy to access what you need, especially when sharing data between coworkers. (So that they can easily understand what you did.) It also helps with problems related to VM storage space and gives flexibility to destroy a virtual machine and recover if you need to. I used to store everything on my virtual machine and drag & drop everything into my host, but this makes everything much easier. With Kali, it takes some setting up to use this feature, but I highly recommend it.
So now we have all our tool output in one place that’s easily accessible and consistent across pentests. Next up is taking notes about what we’re doing; the stuff between that tools can’t capture. I personally use KeepNote and I know I differ from quite a few people in this regard. KeepNote is basically everything I want in a note taking tool for pentesting. If you’ve never used KeepNote before, it’s simply a note taking tool with features built in that make pentesting documentation easy.
KeepNote works by creating an overall Notebook, you can add directories or notes to that Notebook and you can have child/parent relationships for each object. If my explanation makes no sense (quite likely that it doesn’t) just start using the tool and you’ll get it. There are also features that make life easier like integrating a screenshot utility, so that when you are taking notes you can quickly inset a screenshot for whatever it is you are documenting. If you haven’t used KeepNote, I highly recommend trying it out.
What I do when starting a new pentest is to create a new KeepNote Notebook in the Data directory and create a page for scope, contact info and a directory for vulnerabilities. When I find a new vulnerability and exploit it, I create a child page under “Vulnerabilities” with the title of the exploit, write notes and include any evidence. In the notes I often include some sort of risk rating based off our criteria and then I am able to change the background color of the object in the file overview to correspond with that rating for a quick look. Screenshots can be quickly added using the screenshot functionality built in.
I recommend that as soon as you exploit a vulnerability you write it down and as you work your way through your pentesting methodology (escalate, pivot, etc) document those steps as soon as possible with words and screenshots. Having an overabundance of documentation has never hurt anyone before when writing a pentest report!
I like KeepNote for it’s simplicity and ease of use. I can quickly take notes on something related to a pentest and provide evidence such as screenshots. There are other tools out there to accomplish the same tasks, but for me they don’t meet my criteria or I haven’t had time to test them out properly.
Part of the problem with reporting is that while most reports will probably look similar, not every company will utilize the same methodology for generating reports. For instance, a friend of mine’s company has a repository of findings in a wiki that they can easily copy and paste into a report and my company has something similar. Other companies have people writing findings from scratch or very poor documentation.
Keep in mind, if you have all your data organized, this will make your reporting easy. I recommend if you are constantly having to type out new findings, keep them as a separate entity as well as including them in whatever report you are working on at the time. This way you start to build a library of data that can be used to speed up your reporting process. Once you are ready for automation as outlined below, having this library of findings will make semi-automatic report generation so much easier.
Quite a few people think that automation is impossible for pentesting, and I tend to agree especially when it comes to making the ol’ human gut decisions that you simply can’t teach a machine. When I talk about automation (especially in the context of this post) I’m talking about the automation of certain tools, documentation of the output from those tools, and reporting. You can offload a lot of tasks to a computer, leaving the interesting stuff to you. While some of the tools described above sort of achieve that level of automation, they aren’t exactly perfect. Automation in this regard is the future and a lot of big pentesting firms are coming to that same realization. Tools like Canopy, Faraday and Sparta are perfect examples of this market opening up.
As an example, for this article, I’ve written a script to automate the whole manual process documented in the “How to Store Pentest Data” above. You can find that script here. The code isn’t much, but it’s something to automate a trivial task of creating a number of folders to support an engagement. The code I personally use is a little different as I have different needs, but for the most part it works.
There are a handful of tools available that help automate documentation, but we won’t be going into them in this blog post. However, one of my favorite tools for automating testing is Sparta and it has an upcoming review post.
I find that once you’ve got your organizational system set up how you want it, it’s best to keep using it. The most important thing about building habits is sticking with them. Once you get used to documenting and organizing your data properly, you can start to play with how things work and trying new things. Just keep doing it.
Everything I outlined here (except some secret sauce I’m not allowed to reveal due to work) is pretty much how I stay organized when conducting my pentests. It’s not perfect, but nothing is and it works for me. Others I talk to about their organization are either very similar to how I do it, or completely different and baffling to me. What works for one person won’t always work for everyone.
If you liked this blog post, please let me know. I’m going to be working towards publishing more content as time goes on. This post was severely delayed due to my inability to focus/write on just this topic 😛 February will bring the first episode of the Multiplayer Security Podcast as well as two more blog posts. (I’m still counting this one against my January tally retroactively!)
Featured image from http://officesupplygeek.com/levenger-accessories/how-do-i-keep-my-pens-organized/