Report Writing

As a pen tester the most important part of our job is the report. This is really what the client is paying for. This can also be the hardest part of the job, trying to explain technical stuff to non-techies is a skill on its own and does take time to learn. I first want to make a disclaimer, I am not an expert at writing reports I just want to share my view and when I have done reports the small things I try to include, is to make it readable and presentable to a client.

When writing reports I think it’s extremely important to have consistence. I think this gives it a professional look and it’s really annoying when you read something and it’s not the same thought-out it looks untidy and unprofessional. I have seen inconsistence happen in reports and it’s mainly happens when more than one pen tester will be working on the same job. A really good idea is to have a set of rules that every pen tester uses when writing reports, this will reduce inconsistency within the report.
The headings I tend to use for all my reports are as follows, again I’m not saying this is 100% right but fill free to use it.

Title Page
Document Information
Document Control
Executive Summary
Testing and Scope
Vulnerability Findings
Final Conclusion

The Executive summary is the hardest part of the report, in this I try explaining the highest vulnerabilities in non-technical so no SQL injection or any other jargon, I also try not to use acronyms just because you know what a XSS mean does not mean anyone else does. I try keeping it down to what I done and how it can affect their business and I also like to have little info about who we are and why we are here.

The Team were asked by fake company to do a pen test on their internal network. The network range we will be testing is The aim of this test was to make sure no authorised people could gain accesses and cause damage to the companies business and reputation.
A cool tip I picked up was, it is always nice to give the client a compliment before you tell them all the bad stuff. As no one likes to be told they are not doing as well as they expected. By paying them a compliment I just think it easies the pain, therefore it does not sounds like they are doing everything wrong. This can be anything like ‘you have implemented really good security here’ or ‘we found your network was robust and didn’t crash’

Bad Example: I found SQL injection that allowed me to use SQLmap to dump your MYSQL database and that’s bad.

Good Example: I was able to get your entire customer details, this has a high impact on your business as the information could be leaked and customers will lose faith in your company.
You can also add some charts to the Executive Summary to show vulnerabilities by ratings or any other information you think the executive may find useful.
The testing and scope section is where you write what has been agreed with the client, what IPs you can test and what IPs you should you avoid so on. The details from this will usually come from the TOR (Terms or Reference) this will be like a contract the client has signed saying what you can test, what types test you can’t run like DOS (Denial of service).

The next section is all about the issues you have found, this is usually read by the person or people fixing them which means it’s okay for you to talk techie here. The way I write the issue is to try and have a main heading that contains, type of vulnerability description again I try to have a pattern for each vulnerability heading. I then have HOST, URL, PORT and rating under the heading, I then have three sub headings which are findings, impact and recommendations. As well as that I try to keep each vulnerability on its own page, if I have lots of information for certain vulnerability then I tent to add this to the appendix and reference, it is so the client can view the appendix to find out more information. When writing the vulnerabilities it’s also good to add pictures as proof again, formatting of the picture is important to make sure it’s a good clean picture of what you are trying to show and not just a screen dump that has your desktop and all sorts of other stuff in it.
Finally I finish the report with a nice conclusion on my findings. Once I have written the report I then proof read it making sure everything looks good and makes sense with no spelling mistakes. Then I get someone else to read it, my last company had a department that just sat and read reports all day not the best job in the world but the reports at the end were perfect. I also recommend turning the report into PDF or any other file format and making sure it looks good, if you go to all this effort to convert the file to PDF send it to the client only to find the PDF didn’t convert it and your reports are unreadable.

The main reason behind this post is that I have recently see some reports that well to be honest if I was given them, I would never user that company again. I have covered the basic but obvious tips and hope that this might be useful for anyone who has never written a report before.

Leave a Reply