Reporting might sound like an odd place to start a pentest. When most well-known pentesters say that reporting is one of the most important parts of the test, you tend to sit up and take notice.
I’ll add a disclaimer here: I am no pentesting expert, just a long-time IT and InfoSec veteran with a couple certifications under my belt. But I have been on the receiving end of a few pentests, both good and bad. Two things that made or broke the engagement for me were the quality of the final product and the ability of the pentester to interact with both IT and business folk (i.e. play with the normal kids).
The best reports gave both IT the relevant information required to fix the problem, but it also gave the business a good idea of the true risk to critical business processes. The mediocre ones gave me a wealth of technical information but left me to translate this into business risk. The worst one handed me the basic CSV export from his outdated free copy of Nessus.
In reality, there is work that comes before this step but let’s assume that was already done by our imaginary sales team. The customer has already signed a contract and you’ve scheduled your initial project call with all the relevant folks. This is the perfect time to set up your documentation repository in preparation for the first call.
Like most things, pentest reporting has a few good tools to assist. A pro pentester likely has the resources to throw down on a few good tools like Nessus, Metasploit Pro, etc. to increase efficiency and effectiveness. We can buy a few professional tools once we are ready for prime-time, but the habits can be built using our off-the-shelf Kali provided tools.
There are a couple tools that I will discuss here: Dradis and Faraday.
Dradis is a reporting framework which can cut hours from report creation. Dradis CE also supports task sharing across teams and imports for most of the commonly used tools.
My initial foray into Dradis resulted in frustration. Most of the initial issues I encountered in earlier versions seem to have been corrected. All of the actual testing work takes place outside Dradis, then you import the results and let Dradis do its magic.
The Faraday IDE is much more than a reporting tool. Faraday is an actual IDE-style environment for pentesting. The real power of Faraday is being able to run the exact same commands you always use within the IDE, which automagically pulls the results into the Faraday database for reporting. Faraday also has API and import support for a number of popular tools which don’t really conform to the command line.
Initially, I really loved the idea of running everything in the Faraday IDE. I was able to immediately start seeing results. But the community version has limited reporting (or I haven’t figured it out yet.) So I am not completely sold on the community version yet. Faraday also lacks anything to accommodate steps like scoping or keeping the actual results generated by the tools. If I am determined to go into professional pentesting, I would definitely consider getting a license for Faraday.
In summary, Dradis seems to be the best overall tool for documenting the entire process while Faraday wins for ease of use. Faraday would also excel at running a rolling pentest for tracking how long it takes to get the holes closed after discovery.
My initial process
After playing with both Dradis and Faraday a bit, I’ve narrowed down my initial process:
Create a subfolder on my Kali box with the target/client name and date of the engagement.
Run all of my collection scripts/programs from within that folder, storing all the results there as possible.
Import the results into both Dradis and Faraday after the fact.
Compare the two and see which works better for me.
At the moment, I’m running a couple different scenarios in tandem. One will be a rolling pentest/VA, which is where I think Faraday will shine. The other is a more typical one-off test which Dradis may be better for.
If you are an experienced pentester, I would welcome any advice or commentary you have! Hit me up on twitter!