How to Structure a Pen Test Report

• Executive summary: The executive summary briefly summarizes all of the key details of the report. It will speak to the reader in a way that lets them know what steps were taken, what the report ultimately found, and an overview or highlight of next steps, which might include recommendations.
• Tools, methods, and vectors: This section covers the tools you used and the methods you chose to conduct the pen test. In addition to providing a general outline or narrative of your ethical hacks, also detail the paths you took with detailed step-by-step attack patterns and selected vectors.
• Detailed findings: This is where you will list all security risks, vulnerabilities, penetration points, threats, and concerns. Include the technical aspects of each finding in detail.
• Conclusion: This section of the report reiterates the executive summary but with a focus on the next steps.
• Recommendations: Although your job is ultimately to do the pen test and assess the health of the organization’s overall security posture, you might be additionally responsible for providing guidance on ways to improve the security. If so, put those in a separate section and be as detailed as possible.
• Appendix: Include this section for charts, logs, and any information that falls outside the project scope but which you think could be helpful.

Executive summary

For those of you who work in penetration testing and other technical fields, many times you have very little time to speak with and meet with senior executives so think of the executive summary as an elevator pitch. You need to very quickly and concisely talk to your goals, outcomes, and provide a high-level view of key findings. Keep details for the body of the report, not in the summary.

Overall, the goal of the summary is to let the reader know what steps were taken, what was ultimately found, and next steps. If these are the details of a pen test, an executive summary might look like what’s shown below:

A company-wide issue with all Apache web servers that can be accessed remotely without a required patch (more suited for the body in findings).

You have or had a goal to identify whether your company-wide web architecture was secure for the upcoming holidays because the company relies on the integrity of these systems to be profitable in the fourth quarter.

An example executive summary in a pen test report

This (as noted) is only a suggestion; however, it fits all audiences. I didn’t get into details about patches, vendors, systems names, technical jargon or any other albeit important, but unnecessary information for the executive summary. Those details can be added into other sections and appendices.

Another one of the biggest items to consider for the executive summary is scope. This should read very clearly in the first part of your report. The pen test report covered that a scan was needed and completed. The pen tester didn’t get into what vectors were chosen, tools used, methods and so on. The pen tester had to identify the web architecture because that was in scope. The pen tester didn’t have to scan every part of and pen test the entire enterprise’s technical footprint.

The scope of the pen test was to identify whether security posture was high on the web architecture, and that’s what the pen tester included in the summary.

Tools, methods, and vectors

The following image shows an example. You can either detail or map the specifics of what paths or vectors you took, what tools you used, and any specific methods of attack. This can be considered the attack narrative.

Documenting and reporting attack vectors is part of your narrative

This image shows an example of what this section may look like.

An example of a tools, methods, and vectors section.

Depending on the length and complexity of the pen test, this section can continue on with a step-by-step (or hop-by-hop) layout of the attack narrative and how certain information was found based on the assessment. The specifics here can really help to build a technical map for other teams you might collaborate with to address the risks.

You should always assume other technical teams (with permission of course) may be reading your report to help mitigate the risks. You are the pen tester, but the system administrator will likely be the one who needs to patch the DNS server that’s providing zone transfers. The report findings may need to go to the SQL database administrator (or developers) who can help to fix the DBs to stop injection. These folks work with the risk register to close out the items prior to retest.

Detailed findings

If you were able to penetrate a specific port and IP address combo or thwart a router’s security, all that should go into detailed findings. You can also use the notes created and the tools report and audit output for help building your main report.

Include your main findings in your report.

The biggest difference between this section and the one previous is that this is where you can place the items identified and outcomes from the attack narrative. In this example, you may want to use the Metasploit audit logs to show all the vulnerabilities identified.

You may want to show the specifics of the logs (in minute detail) where you found the zone transfer issue. You should show all details; however, if it seems to be too much information, you can choose to summarize for the sake of brevity. Be cautious so you don’t remove information that is needed for your report.

It’s these details that allows the technical teams to not only fix what you found in the pen test, but also identify any and all other issues that may be (or not) relevant to the conducted pen test. For example, your goal (in scope) may have been to protect web architecture, but the technical teams found that all of the Windows Servers are missing critical patches that help mitigate other issues that the tools may have found.

You don’t want to overwhelm anyone, confuse the report, or stray too wildly from the goal/scope, but you’re beholden to inform those of any and all security infractions you identify along the way. Cover those details that fall outside the project’s scope in the appendices.

Conclusion

An example of a pen test report conclusion

As you can see, the next step is to do a retest to ensure that any documented changes, fixes, risk avoidance, or compliance items were handled and done so correctly. A retest will prove that.

Recommendations

As you will see, the detailed findings, appendices, and recommendations can be repurposed and reorganized based on what you need for your report. You could have a recommendations list in your appendix.

Recommendations should be made if they’re in scope. Not all pen testers are required to recommend how to fix the items they found in the pen test. Should you know how to fix the items you have identified? If you want to learn more about security and how to be a better pen tester than the answer is yes, but it doesn’t mean that it needs to be in the report you submit.

Appendix/appendices

Want to learn more about pen testing? Check out these ten penetration testing sites.