Writing a Professional Penetration Testing Report

As penetration testers, we can't escape writing penetration test reports, no matter how inexperienced or experienced we are. Each vulnerability should be properly classified, described, and should be friendly to any reader - tech and non-tech person. In this series I will share with you my knowledge about how to write a professional report.

Part 1: Report sections

Let's take a look at this graphic:

The biggest chunk of the report should always be the Technical details where the vulnerabilities are described. The order of the summary, RoE, list of findings and technical details can be flexible, as long as it's rational.

Title page should consist of:

• Name/Logo of company doing the test
• Name/Logo of the Client
• Test period
• Version/ID of the report
• Confidentiality level
• Optional: any disclaimer to the confidentiality classification
• Optional: personal names of the testers
• Optional: screenshot of the test subject

Let's not merge Title page with Table of contents, okay?

General Summary (Executive Summary) is a place for charts and a summary regarding how the found vulnerabilities affect the test subject. This page is dedicated to the people who want to take a quick look and already have a vision what to expect next, and how badly it's messed up. Consequently, when scrolling through the report, the General Summary should attract the most attention.

Here we can present our conclusions after the test to prepare the reader for the next, more technical part of the report. There is no special recipe of what to write, but maybe the following questions can help:

• What is the general impact of Confidentiality, Integrity, and Availability of the test subject?
• What can an attacker achieve?
• What are the most severe vulnerabilities?

Good examples from the publicly available reports:

Demo Report Syslifters

Cobalt pentest report for shiftleft

List of vulnerabilities:

• preferably should in a form of a table 
• should contain impact for each vulnerability
• may have a brief description for each vulnerability 
• if there was a recheck - there should be a vulnerability status (fixed/not fixed/not checked/etc)

Example:

LogicalTrust OPNsense security assessment report

Rules of Engagement vs Technical Details. I want to explain the difference.

RoE (Scope) section, or whatever do you want to name it, should be everything that was agreed on before the actual test with a few exceptions. Everything like:

• scope of the test
• methodology of testing
• read/write/delete/DoS permissions
• timeline
• credentials used
• disclaimers 
• any other agreements
• exceptions that can be here or in Technical Details:
• tools used
• disclaimer
• house cleaning details

Technical Details (findings details) section, on the other hand, describes everything that was done during the test. When looking through publicly shared reports, I've found too many of them where I was a bit lost when reading the details. The border between where the methodology ends and the vulnerabilities description starts was non-existent, which made me confused as to what was the actual result. The absolute worst reports are source code security reviews. The testers write  test details as if it was a punishment for them. Everything is mixed and, of course, walls, walls of text.

walls, walls of text

"But what if I MUST write a lot of text?" Make use of additional chapters, bullet points, lists, tables, colors, charts, etc. You have to keep your reader "entertained", because the fact that they are at work doesn't automatically mean that they will read everything with a full focus. You risk additional meetings, questions, misunderstandings.

More about the Technical Details section

Each vulnerability has its own ID. It can be just a number, an abbreviation related to the Client, or some other custom numbering scheme.

Then we have:

General Information (vulnerability description) is a high-level explaination of the type of vulnerability found. It's written without any technical details and it doesn't need to be customized every time the vulnerability occurs. It's a good practice to add at least a small note of the potential impact of the vulnerability.

General Information must be related to what the reader sees later - a step by step instruction (performed tests). Together, they must create a sufficient manual of the finding. 

How to describe the vulnerability:

Language should be gender-neutral when describing someone's action, for example:

• "if an attacker has access to ..., they may be able to ..."

Don't use overly casual language and avoid too much of a technical jargon. Provide clear explanations of the vulnerability, and at the same time provide all the necessary details needed to replicate the exploitation.

It is important to maintain a formal and objective tone. By writing "It was found that" instead of "We found that", the main focus stays on the vulnerability itself rather that on the testers.

• Passive voice - "It was found" - DEFAULT
• "We found" - RARELY
• "I found" - only in articles, bug bounty reports, etc

Usage of simple sentences is also a good choice:

• "The application is ..."
• "The vulnerability exists ..." 

Other phrases to use in your report:

• "It is sufficient to ..."
• "This allows an attacker to ..."
• "To exploit the vulnerability ..."

I invite you to check out this well-written description of the Command Injection vulnerability in this report: 

Bishop Fox Assessment Report - Winston Privacy

You can see that the "Details" section contains a step-by-step instruction that doesn't have any unnecessary notes. Just a simple how-to divided by screenshots and code samples, while simultaneously providing all technical information. Also, the first paragraph describes everything - what's the vulnerability, how it's exploited, what's the impact, all in only 2 sentences.

By the way, do I need to mention that the vulnerabilities should be ordered from the highest impact to the lowest? Apparently yes, because I've seen some public reports with random order 😰

Affected components is a small section where you want to insert the vulnerable path of the test subject. The idea is to have an organized list of where to look for the vulnerability.

Recommendations in a perfect world are always adjusted to the test subject, however, obviously it can take too much time to do it every time. As penetration testers, we know how the vulnerabilities can be mitigated on high-level, but there are too many programming frameworks, languages, and software, to know all the technical details. For this reason, there is no single way of writing the Recommendations section - you should depend on your knowledge on the specific subject.

CVSS and Impact - CVSS is the easiest way to measure the impact of the vulnerability, because once you start practising calculating it, it becomes very intiuitive. At the time of writing this article, CVSSv3.1 is still the most popular, but CVSSv4.0 is slowly gaining some audience. Except this measurement, impact can be described with words, but let's keep it brief as to not overshadow our ealier descriptions.

If there is anything we would like to add for further reading (and usually yes, we do), it's kept in the References section (or Resources). That is:

• references to the type of vulnerability to back up our description, for example OWASP
• vulnerabilities-related databases - CVE, CWE
• links to the exploits used
• articles on the specific subject

Remember that anything you add here is interpreted as an extension to your report. The resources should be also kept in a professional tone, so adding social media links may not be the best idea (with some exceptions, I guess). 

Thank you for reading! If I add more parts to this series, I will link them at the beginning 😉