CHAPTER 9

Writing and Communicating the Pentest Report

In this chapter, you will learn how to

•  Describe a process-oriented approach to writing a pentest report

•  Find open source guidance regarding pentest report criteria

•  Identify methods for communicating the pentest report to your customer

In the previous chapters, you have learned about various attack techniques and methodologies that you can use during a pentest. However, the technical assessment is only a portion of the overall pentesting process. Client communication is an important factor of pentesting, and even more so when the pentest is conducted with limited or no face-to-face interaction with the customer. The pentest report documents the results of the pentest and is provided to the client, typically as the final deliverable for the pentesting engagement. The information contained in the pentest report is intended to help senior management make informed risk decisions regarding how to prioritize and mitigate security deficiencies that you have discovered in the organization’s networks during pentesting.

The GPEN objectives state that exam candidates should be able to take a process-orientated approach to penetration testing and reporting. This chapter discusses open source guidance for how to develop a pentest report and the criteria that you should include in the report to effectively communicate the results of the pentest to your customer. This chapter also explains how to deliver the sensitive pentest report securely to your client.

The Pentest Report

When journalists travel to remote locations throughout the world, they document important aspects of their journeys in many ways, such as taking notes, taking pictures, or even through video recording. Pentesters follow similar practices during a pentest and summarize their discoveries in a pentest report. The pentest report is an important artifact that documents the experiences and observations the pentesters encountered on their journey through the target organization’s networks during the pentesting engagement. There is no universal standard for how to create a pentest report or which information it should contain. However, some of the organizations discussed in Chapter 1, such as the Penetration Testing Execution Standard (PTES) project and the Open Web Application Security Project (OWASP), provide guidance on report writing best practices and report criteria that you should consider when drafting a pentest report. This section covers some of those best practices and some of the criteria you may want to include in your pentest report.

EXAM TIP The GPEN objectives offer little guidance for a specific process-oriented approach the pentester should follow when writing a pentest report. However, by following open source guidance, industry best practices, and the recommendations in this chapter, you should have sufficient report writing knowledge both to pass the exam and to prepare professional pentest reports for your customers.

Report Writing Best Practices

Writing a pentest report is a type of informative writing or expository writing that provides and explains information to readers using observations, ideas, facts, and various forms of technical data. The goal of informative or expository writing is to educate your readers on a specific topic. In the context of pentesting, the specific topic is what you determined from the pentest about the security posture of organizational assets and the effectiveness of installed security countermeasures to protect against relevant attack vectors.

Here are some important considerations when drafting a pentest report:

•  Know your intended audience

•  Use an appropriate tone

•  Include only relevant information

•  Crop and annotate screenshots

•  Use good grammar and write clear, concise, and correct sentences

When writing any type of document, you should know who is included in your intended audience so that you can write your report in a way that appeals to, and is understandable by, all of your readers. The intended audience for a pentest report includes the executive management and technical staff of the organization that was the target of the pentest. As discussed later in this chapter, the pentest report should include an Executive Summary section intended for management and a Technical Report section intended for technical staff.

The tone of the pentest report should be formal and impersonal and avoid the use of accusatory language. For example, a report shouldn’t say, “Your users should be better trained in password security because they all like to use easily guessable passwords.” Instead, a better way of saying this would be, “The pentest team discovered easily guessable passwords on the network. The pentest team recommends using stronger password security policies for your network and training your users on good password security hygiene.” There is no room for gloating or pointing fingers in the pentest report; instead, it should be written such that each technical concept is phrased clearly by explaining how an attack works.

It is important to only include relevant information in the pentest report that presents facts, ideas, and observations that can be verified. For instance, your customer may want to reproduce the results from the pentest using the same procedures or tools documented in the pentest report to ensure vulnerabilities have been successfully mitigated on their network. If the test procedures you documented in the report cannot be verified, the pentest report will be inconsistent and have less of an effect with improving the security posture of the customer’s network. Throughout this chapter, we will discuss relevant information that should be included in the pentest report.

When describing a vulnerability or finding (something that could be advantageous to an attacker when attacking the customer’s network) in the pentest report, be sure to omit or mask sensitive data or screenshots that contain passwords, usernames, sensitive e-mails, and so forth. but make sure that you still provide the same level of impact for your audience. Another consideration to be aware of is how much “landscape” from a screenshot is actually needed. For example, suppose that during the pentest you took a screenshot of your desktop that includes the terminal window showing the hashes that you successfully dumped from the organization’s domain controller using Metasploit. The best way to present this in the pentest report would be to crop the disclosed hashes from the terminal window and blur parts of the hash values to prevent disclosure of sensitive information. You could annotate the cropped image with a circle or square—using image editing software such as Microsoft Paint or GIMP, the GNU Image Manipulation Program (https://www.gimp.org/)—to draw your audience’s attention to specific areas of interest and highlight the elements that provide the most impact for your finding. Figure 9-1 shows an example of an annotated screenshot, with hash values blurred to prevent the disclosure of sensitive information and boxed text to emphasize the administrator and domain admin accounts.

Figure 9-1 Example of annotated screenshot

Version 5 of the Web Security Testing Guide, which is hosted on GitHub (https://github.com/OWASP/wstg), says the following about reporting: “Performing the technical side of the assessment is only half of the overall assessment process. The final product is the production of a well written and informative report.” To ensure that your pentest report is well written and informative, after you have composed the pentest report, it should undergo a thorough edit to ensure that all sentences are accurate and complete, and then it should be proofread to correct spelling and grammar errors. Inaccurate or incomplete sentences in the report may lead the reader to misunderstand the findings or cause the reader to draw incorrect conclusions from the evidence provided in the report. If the report has multiple grammar and spelling errors, the customer may find a lack of professionalism, which could hinder your chances of getting more work from that customer. If possible, it may be a good idea to have another set of eyes review the report before it is finalized.

With the preceding best practices for writing a pentest report in mind, you are ready to learn about some open source guidance and industry best practices for how to draft a pentest report.

NOTE Never underestimate the value of a solid, well-written pentest report. The report should be an accurate representation of the image the pentester is trying to convey. As a pentester, don’t get so caught up in the technical portion of the assessment of trying to break into the customer’s system that you forget to give yourself sufficient time to write a solid report. It is important to follow the pentesting schedule outlined in the rules of engagement (RoE) and strike a balance between testing and reporting. Remember, the final report is the only deliverable the customer has after your pentesting engagement is over.

Preparing to Write the Report

Before you begin drafting the pentest report, you need to determine which information you want to put into the report and which documentation format you want to use when writing the report. For the latter decision, a common choice is to write the report using some type of word processing software (e.g., Microsoft Word, LibreOffice Writer, etc.) and then publish the final version of the report in a read-only Adobe PDF to prevent additional modifications. As far as the content and structure of the report are concerned, the following steps should help you to brainstorm what information to include in the pentest report and how to organize that information:

•  Gather all testing artifacts

•  Analyze the evidence

•  Develop a pentest report template

NOTE The report format is typically specified by the customer in the statement of work (SOW) or other type of contractual agreement, which identifies the specific deliverable format for the pentest report.

Gather All Testing Artifacts

After completing the technical assessment portion of the pentest, you’ll likely have an abundance of testing artifacts produced from the testing methodologies that you executed during the engagement. Gather all the appropriate testing artifacts to support the story and attestation of findings that you are going to present in the report. This means making sure you have all the deliverables for the engagement, such as

•  Scan data Includes data produced by a vulnerability scanning tool in a machine-readable format (such as XML, CSV, or JSON) or a format that provides the greatest amount of information

•  Screenshots Support or show evidence of a finding in the pentest report

•  Testing notes Provide a record of observations witnessed during the pentest

In some cases, the customer may specify the testing artifacts that are required to be included in or with the report (i.e., deliverables). Testing artifacts can be an invaluable asset to the customer, especially when the customer needs to reproduce the results from the pentest to ensure weaknesses have been properly mitigated. If you are unsure as to which artifacts are to be included in the report and which format they should be in, check the SOW, RoE, or ask your customer.

Analyze the Evidence

All of the artifacts that have been gathered in support of the pentest can now be considered your body of evidence. In our case, the body of evidence is a collection of information used to support the facts of the pentest. Analyzing the evidence is important, as it helps to identify findings and false positives produced from your test results to improve the completeness and correctness of the information in the pentest report. There are a few topics you will want to investigate when analyzing your body of evidence to produce the findings in the pentest report:

•  Finding ID A unique identifier given to a finding that can be used to track prioritization efforts and set milestones to close open findings post-report delivery.

•  Testing methodology Describes the specific type of testing methodology identified in the scope of engagement that was used to identify the vulnerability.

•  Vulnerability The title or name given to a finding, which represents a weakness in the customer’s environment that would be advantageous to an attacker (e.g., “Weak password complexity requirements”).

•  Impact This provides the level of severity for a finding. The Common Vulnerability Scoring System (CVSS) calculator (https://www.first.org/cvss/calculator/3.1) is a tool that you can use to help quantify the severity level of findings in the pentest report and categorize them with labels such as Critical, High, Medium, Low, and Informational.

•  Affected targets The host, application, or asset affected by a particular finding or compromised during the pentest.

•  Remediation Provides the recommended solution to fix the weakness (i.e., people, process, technology). If the weakness is related to employees following organizational policy (e.g., identifying spear phishing attacks), it could be a cultural problem that senior management may need to address with administrative sanctions, and the solution could be instituting an annual security training requirement. In some cases, the weakness could be resolved by adding or updating a process and enforcing the process through organizational policy, such as changing password complexity rules and guidelines. A technology or technical solution is something that can be applied to the software or hardware, such as a vendor-supplied patch or configuration change, based on best practices. In the remediation section of the report, it may also be worth discussing how the customer may detect attack or exploitation observed during testing, either using their existing monitoring capabilities or referring to solutions or products the organization could benefit from using.

•  References Provide additional resources that customers can use to get more information on a vulnerability that affects their environment. These are typically web links to common vulnerabilities and exposures (CVE) https://cve.mitre.org, common weakness enumerations (CWE), or common attack pattern enumerations and classifications (CAPEC) https://capc.mitre.org applicable to the specific vulnerability.

TIP Good note taking is an important part of the pentest. Your testing notes can aid in the process of analyzing your body of evidence by confirming test results using observations you witnessed during the pentest.

You may find it beneficial to document the results from your analysis using a findings table, which can be created using a spreadsheet application (e.g., Microsoft Excel or Apache OpenOffice Calc). A findings table can help you organize your thoughts, catalog your findings, and support the development of the Technical Report section of the pentest report. Figure 9-2 provides an example of a findings table.

Figure 9-2 Example findings table

After you have gathered all the required testing artifacts and analyzed the data and findings for accuracy and completeness, it is time to start writing the report.

Writing the Report

The pentest reporting requirements vary based on which type of pentest you conducted. As mentioned in Chapter 1, there are many types of pentests that can be used to conduct the assessment. The PTES website (www.pentest-standard.org/) provides technical guidelines to assist organizations to understand what is required to execute a pentest, identify the type of testing that would provide the most value to the organization, and define executive and technical reporting requirements. Although the standard is a few years old, the PTES website still has a lot of good information to help aid in the report writing process.

A report template will help you structure and organize the information that you want to include in your pentest report. Most pentesting companies have their own customized and branded report format that can be used repeatedly to improve the efficiency of their report writing practices. However, both PTES and OWASP WSTG version 5 provide some general guidance and suggested section headings for pentest reports. In the next section we will cover some of the major elements from their suggested guidance that you should consider when developing your own pentest report outline to include

•  Executive Summary

•  Technical Report

•  Findings and Remediations

•  Post-Engagement Cleanup

•  Appendixes

TIP All the information in the report must illustrate the goals/objectives set out during pre-engagement.

Executive Summary

PTES describes the executive summary of the pentest report as the section that communicates the specific goals of the pentest as well as high-level findings (in layman’s terms) to organizational leadership that affect the organization and the bottom line upfront (BLUF). The text should help provide strategic goals or a roadmap that the organization can follow to better align with industry standards. Per OWASP WSTG v5, organizational leadership wants to have two questions answered in the Executive Summary:

•  What’s wrong?

•  How do I fix it?

You should answer these questions in as few pages as possible in the pentest report. The Executive Summary should plainly state the problems (vulnerabilities) and indicate that their severity is an input to the organization’s risk management process, not an outcome or remediation. You should include graphs or other charts that show accumulated risk (or severity) levels and rankings, which help quantify the significance of findings in the report. Figure 9-3 shows an example risk rating scale that explains how vulnerabilities can be quantified and categorized based on the significance of loss if a vulnerability were exploited. Figure 9-4 shows an example of a pie chart that represents a general synopsis of the issues found during the pentest. Both of these examples can be found on the PTES website.

Figure 9-3 Example risk rating scale (Source: www.pentest-standard.org)

Figure 9-4 Example pie chart (Source: www.pentest-standard.org)

CAUTION Sometimes “risks” or “risk levels” are identified as “severity” or “severity levels” in a pentest report. Pentesters who are not affiliated with the organization do not understand the threats faced by the organization or the true consequences that an organization would face if the vulnerabilities were exploited. Therefore, the pentester may not be best suited to assess risk. This is the job of the risk professional who understands the business of the organization and is responsible for calculating risk levels for the organization. Ultimately the pentest report is an input into the organization’s risk management process.

Technical Report

PTES and the OWASP WSTG v5 suggest that the Technical Report section should be used to communicate a more comprehensive and in-depth look at the findings, the methodology that was used for the assessment, testing objectives, scope, test cases, screenshots, and any exploitation paths and their recommended remediations. The following six criteria should be addressed in this section:

NOTE “Test Parameters” is the alternative name referenced by OWASP WSTG v5, which is the equivalent of the “Technical Report” section found in PTES.

•  Objective Outlines the project objectives and the expected outcomes of the pentest

•  Methodology Describes the techniques used to execute the pentest

•  Scope Defines what was actually tested, based on the agreed-upon scope of the pentest

•  Schedule Specifies the timeline of when the assessment started and when it was completed

•  Targets Lists the number of hosts or applications that were within the scope of the assessment

•  Limitations Documents restrictions (e.g., hours during which the pentest was conducted) imposed on the pentest

Findings and Remediations

The Findings and Remediations section of the pentest report should provide detailed information regarding approved attack vectors from the RoE that the pentest team leveraged to attempt access to the target system. This section elaborates on the outcome of the techniques used during testing and the findings the team was able to discover. Sometimes this section is titled “Attack Narrative” or “Testing Narrative.” As introduced earlier in the chapter, a finding is something that could be advantageous to an attacker when attacking the customer’s network. Findings should only include actionable items from the exploitation and post-exploitation activities and carry some type of risk/severity rating. In some cases, the findings in a pentest report are a direct result of an implementation weakness, poor development practices, lack of input validation, or other shortcoming. Each finding should provide supporting evidence (e.g., screenshots, notes, proof-of-concept [PoC] examples, etc.) in a technical description that explains how the vulnerability was exploited. This enables the customer to duplicate the finding as part of remediation validation. For each finding discovered during the pentest, this section should offer a proposed remediation, which is the solution or action plan for fixing the finding.

Post-Engagement Cleanup

Neither PTES nor the OWASP WSTG v5 provide report writing guidance on post-engagement cleanup. However, this section is recommended to be included in the report so you can describe the actions that you have taken to safely remove or uninstall tools and exploits utilized during the pentest. Depending on how long the pentest lasted and the size of the organization’s network, the post-engagement cleanup could require a coordinated effort between the organization’s IT support personnel and the pentesting team. In some cases, the customer may need to reboot target hosts in order to clear the contents of memory, even if nothing was written to disk. Metasploit modules follow a pretty constant practice of removing anything added to the disk that was not already there. This makes things a little easier and provides some level of assurance when you execute the sessions -K command to kill all sessions through the Metasploit console. However, documenting your post-engagement cleanup actions shows professionalism and instills confidence with your customer that their network was returned to a known good state.

TIP A good rule of thumb: Always leave the network in the same condition as you found it.

Appendixes

This section is often used to describe the commercial and open source tools that were used to conduct the pentest, such as Nessus, Burp, or Nmap. Customers may also want to have scan data that originated from the pentest tools. These testing artifacts can be saved in an archive format, such as a zip file, and included as an appendix in the report. If the pentest team developed a custom script or code and used it to assist with the pentest, that should be disclosed in an appendix or noted as an attachment. Customers appreciate when the methodology used by the consultants is included. It gives them an idea of the thoroughness of the assessment and can help aid with validating findings in the report.

TIP You can download a sample penetration testing report from the Offensive Security website: https://www.offensive-security.com/reports/sample-penetration-testing-report.pdf. The structure of the sample report is a little different than what we have described in this chapter, but it does cover a lot of the same details and should give you an idea of what a pentest report would look like.

Report Handling

An important part of the reporting process is communicating the pentest report to the customer. When the report is finalized and ready to be submitted to the customer, it will include a great deal of sensitive information, which means you need to give proper care and consideration to the secure handling and disposition of the pentest report. The delivery should be an agreed-upon method between all parties identified in the RoE. One example would be to encrypt the report and use a secure transport mechanism such as HTTPS, SFTP, or SMIME (secure e-mail) to deliver it.

The size of the report can grow exponentially depending on different factors, such as the size of the objects (test artifacts) inserted into the report and the number of illustrations used to provide evidence of testing activities. For a report that has a very large file size, considering using a file compression tool to reduce the size of the file for transmission. For example, 7-Zip (https://www.7-zip.org) is a tool that you can use to compress the size of the report, as well as apply AES 256-bit encryption, using a strong password. After you have used 7-Zip to compress and encrypt the pentest report, you could upload it securely to a file service or deliver it through encrypted e-mail.

The pentest team should consider storing a single digital copy of the encrypted report and enforce strict access controls to prevent against unauthorized disclosure. Once the customer has acknowledged receipt of the pentest report, all remaining digital or written copies of the report should be marked for proper disposal and deletion. Depending on the risk appetite of the customer, they may ask the pentest team to hold onto a digital copy until after final review and acceptance of the report and then have all remaining copies be properly disposed of. Every organization has its own level of risk appetite, which is how much risk the organization is willing to tolerate to achieve its goals. Regardless, the storage time for the report is inclusive of the terms outlined in the RoE. There are no other reasons to keep multiple copies of all the customer’s most confidential data for an indeterminate period of time.

TIP You should not use the same delivery mechanism for the decryption password as you use to deliver the encrypted report. This way, you maximize continuity and reduce the risk of unauthorized disclosure should one path become compromised.

Chapter Review

Writing the pentest report can be very time consuming. However, following pentest reporting best practices can help you better prepare for the report writing process. The report should include an Executive Summary (targeted to executive management) and a Technical Report section (targeted to technical staff), the latter of which includes coverage of all the approved attack vectors and testing activities documented in the RoE. When drafting the report, be sure to know your audience and write the report in such a way that appeals to all of your readers. Pentest report templates are a good way to help organize and structure the information you put in the report.

Once the report is completed, it will contain a great deal of sensitive information and thus you need to use an agreed-upon secure method for delivering the final product. One of the most important things you can do as a pentester is to maintain good communication with your customer. Remember, the customer has given you authorization to evaluate the security of their systems. As a pentester, you are responsible not only for identifying security weaknesses of the target organization but also for helping to safeguard and preserve the confidentiality and integrity of your customer’s most sensitive data.

Questions

1.  Which of the following are pentest report writing best practices? (Select all that apply.)

A.  Know your intended audience

B.  Include only relevant information

C.  Use good grammar and write clear, concise, and correct sentences

D.  Crop and annotate screenshots

E.  Use an appropriate tone

F.  All of the above

2.  Before drafting a pentest report, other than gathering all testing artifacts, what are two additional steps you can take to help you brainstorm which information to include in the report?

A.  Analyze the evidence

B.  Preserve confidentiality of customer-sensitive data

C.  Develop a pentest report template

D.  Use a report format such as Microsoft Word

3.  Which two questions are often asked by organizational leadership and should be addressed in the Executive Summary section of the pentest report?

A.  How do I fix it?

B.  What’s wrong?

C.  How should we pay you?

D.  Did you remove all of your tools?

4.  Which of the following testing parameters describes the techniques used to execute the pentest?

A.  Limitations

B.  Scope

C.  Objectives

D.  Methodology

E.  Schedule

F.  Targets

5.  Which of the following protocols can offer a secure transport mechanism for delivering the report to the customer? (Select all that apply.)

A.  HTTP

B.  SFTP

C.  FTP

D.  HTTPS

Answers

1.  F. All of the answers are pentest report writing best practices.

2.  A, C. Analyzing the evidence, developing a pentest report template, and gathering all the testing artifacts are all ways to help you brainstorm which information should go into the pentest report.

3.  A, B. Organizational leadership will want to know “What’s wrong?” and “How do I fix it?” Answers to those questions, addressed in the Executive Summary, will help leadership properly address areas of concerns and steps that can be taken to mitigate the problem(s).

4.  D. The methodology describes the techniques that were used to execute the pentest.

5.  B, D. Secure File Transfer Protocol (SFTP) and Hypertext Transfer Protocol Secure (HTTPS) are two protocols that can encrypt data in transit and help protect the confidentiality and integrity of the customer’s pentest report. File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP) are cleartext protocols that offer no data transport encryption. Thus, if you were to deliver the customer’s pentest report using one of these protocols, it would be sent in the clear and susceptible to compromise.