Skip to Main Content
January 16, 2024

Level Up Your Reporting

Written by Kurt Muhl
Penetration Testing

As a security consultant, our number one deliverable is a report of findings and recommendations. This is what our clients are ultimately paying for. Making sure the report can be easily read and understood should be high on the priority list. While the examples in this post will have a focus on security assessments, these tools and tips can be applied to a variety of other situations where note taking, and organization of information is key.

Client Perspective

My security career started on an internal security team, consuming reports from third-party vendors. I learned a lot from reading those reports and have tried to carry many of those lessons with me as I transitioned into new roles.

With every assessment that was performed there were three primary objectives:

  1. Understand the finding(s)
  2. Reproduce the findings(s)
  3. Communicate the findings(s) to others

These objectives are needed to ensure an understanding of the exposures to the client. A key detail here is providing enough information so that a client can reproduce the results and communicate the results to other stake holders, such as a development team to implement a fix. From the consultant’s perspective, this all starts with proper note taking. If you do not have proper notes or are going back at the end of an assessment to recapture evidence, it will show in your final deliverable.

Streamline Reporting

A good report starts with good notes. Everyone has a different style of how they take notes and preferences in the features of the tools they use to take those notes. One characteristic that is important when handling client information, is where the notes are being stored. Many note taking applications will automatically synchronize with online portals such as Google and Microsoft. Some clients may not approve of any information related to their assessments being uploaded to these platforms. As a security professional, it is your responsibility to make sure that information is protected from any unauthorized exposures. I have highlighted a few different tools that I have used that might be a good starting point for taking notes on your local system. 

When performing an assessment, it is important to take notes as you go. If you take notes that align with the details needed in the final deliverable, this will greatly reduce the amount of time spent organizing information at the end of the assessment. One key detail to making this approach successful, is having a consistent template for the report structure and the structure of your notes. Below is an example page from my notes.

Figure 1 - Example Page From Notes

Each section of the note are pieces of information that will need to be entered into the final report template. Although the finding name and some of the technical details may change for each finding, a template can be created so each note has the sections ready to be filled out. Below is an example of the finding after it has been entered into the report.

Figure 2 - Example Finding in a Report

Tips for Capturing Evidence

An essential piece of every assessment report is the evidence. This is most often provided as screenshots within the report. The evidence should walk a client through what the tester observed and how the client might reproduce a vulnerability. Here are some things to consider when providing evidence in a report:

  • Make sure the pertinent information is included and legible.
  • Annotate or highlight important information.
  • Crop out blank space or irrelevant information.
  • Create the findings and evidence as though you were the analyst that works with the developer or system administrator that has to fix the issue.
  • Provide commands in a text format along with screenshots.

Below is an example screenshot that was taken when looking for potential SQL injection flaws within a web application. While the pertinent information is included in the screenshot, using this image alone would fall short on nearly all of the suggestions above.

Figure 3 - SQLi in Burp Suite

The above screenshot can be slightly difficult to read, because there is a lot of information being conveyed in a single image. This causes the text to be small and hard to read. Additionally, there is no annotation or highlighting to draw the reader’s attention to the details that actually matter. By splitting the screenshot into two screenshots, request and response, the text becomes much more readable. Adding some annotations to the screenshot will draw the reader’s attention to specific details so they are not having to study the image to identify key information.

Figure 4 – Request to the Web Server
Figure 5 - Server Error Generated by User Input

You may notice in Figure 3 that the server response was cut off to just the first few lines. This was done to focus the reader’s attention to the information that truly matters, which is the server error. Doing this allows for the primary information to be conveyed without overwhelming the reader with a lot of auxiliary information.

One piece that is still missing from the above evidence, is the consideration for the analyst or developer that reads the report. Most of the time, those teams do not have access to tools like Burp Suite Pro, and they are not used to seeing someone interact with a website in this manner. Taking the time to show the same issue with tools that an average user has access to, in this case a web browser, can go a long way to reinforce what is happening.

Figure 6 - User Input in a Web Browser
Figure 7 - Server Error Due to User Input

Below are a few tools that can be used to edit screenshots to add the annotations to evidence and really level up the readability of your report.

 Snagit happens to be a popular tool for adding annotations. Users are able to edit the image after it has been saved. If you make a spelling mistake, it is easy to go back and fix after the fact.

 Lastly, when providing evidence in a report, it is helpful to include longer commands or complex inputs as text alongside a screenshot. This allows for easy copy/paste by anyone who may need to retest the finding. Using the below evidence as an example, having to type the command out by hand could be troublesome.

curl -i -s -k -X $'POST' -b $'session=<REDACTED>' --data-binary $'csrf=<REDACTED>&username=administrator%27&password=test' 'https://<REDACTED>' 
Figure 8 - Curl Command Generating Server Error

By including the text with the screenshot, readers are able to copy and make changes to the command as needed while seeing what the expected output. Taking the time to make these changes to the way evidence is presented in a report can greatly improve the readability and overall user experience.