The Penetration Testing Report

So, the fun you had hacking a web application is over, and you need to start writing the final report. You start wondering where to start, how to structure it, format it, and how to make it look good.

We will try to answer all that in this post. For this purpose, we will see how to write a Final Report on a Web application penetration test.

If you had ever searched the Internet for sample penetration testing reports, then you have already found that, for some reason that is still unknown to me, security companies does not have sample penetration reports on their sites. As weird as it is, it is extremely hard to even find a decent how-to on the structure of the final report.

I mean, really! Are the security companies so ashamed of their reports that they would not show them to the public?

So, I’ve been meaning to write a post about this for a long time. Now, I have the time to really do it.

Before I start, I would like to underline that our company, too, does not have a report on our site. To be honest, instead of writing this post, I would just post a link to the report and be done with it. But I have to justify my time in front of the management, and this is a good way to do it :-). What is more, people would just use it as a template and will never learn how to write it themselves. The sample texts I will use below are from our sample report. So, let’s start.

The key to a good report is that you should have already started with it before you begin with the test. That is why, we will talk a lot about what you need to do before you even start the assessment.

When a client contacts you about a pentest, you do several things before the start of the test. Let’s call these

Pre-Engagement Activities

In this stage, you will ask questions about the system.

The most important question is why the client is doing the assessment. The answer to this will help you set the test goal and objectives. You will also need to know if you will test just the application or the server will also be included, will you test all parts of the application or just the front-end or the administration back-end, what tests you will make and how intrusive they will be, what time of the day you will do the testing. You will also ask for a single point of contact you can reach in case of emergencies, and so on.

Based on this information, you will have to create a

Penetration Testing Plan

The PTP has to have several sections. If you want to make it good looking, include your company

Cover Page

Usually, we put a short paragraph at the end of the cover page to tag it as confidential. The following is a pretty standard text:

This document is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this disclaimer is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this document is strictly prohibited. If you received this document in error, please notify us immediately by telephone and return the original document to us at the address below. If you have received an electronic copy of the document, please remove it immediately after reading this disclaimer.

Then, of course, you include a Table of Contents. It is a known fact that C-level executives and decision makers don’t do well with plain text. You need to start with the table of contents, so that they know exactly where to skip to.

Not that it is not obvious from the title of the document, but to be thorough, you would also want to include a

Purpose of This Document

section. It should clearly state what this document is about. For example, something like this:

The purpose of this document is to describe the details of the penetration test that will be conducted by MTR Design against the <Name of application> application for <Client>.

It defines the goal of the test and lists its objectives; it also summarizes the scope of the test, and outlines the scenarios and the tests that will be performed by the testing team.

The next section you need to include would be the

Distribution List

This is simply a table with the people that can read this document. The table can have three columns: Name, Role, and Contact Details. Anyone that should have access to the document should be listed here.

You will also have to include a

Revision History

This is another section that details the changes made on the document by the people that have contributed to it. The columns here are Version, Date, Author, and Comments/Notes.

Then, you have to have a

Project Definition

section. This is another short paragraph, for example:

The MTR Design team was engaged to test <Name of application> for security issues. The purpose of the test is to determine the level of security of the web application interface.

Now has come the time to secure yourself. Every pentester knows how quickly things change in the security industry, so it is a good idea to include a section about the

Test Limitations

Something like the following should do:

The penetration test provides a snapshot of the current security problems of the system, and it is limited in terms of time and personnel. Therefore, they cannot provide a 100% guarantee that every attack vector has been included, and that the system will stay secure over time.

After you add this ‘limited liability’ section, it is time to list the

Test Goal and Objectives

In this section, you should define the goal of the test (remember those talks you had with the client?) and ‘bullet’ the test objectives. Here is a sample:

The goal of the test is to find possible vulnerabilities, related to the Web application and verify if they are exploitable, provided that a permission to exploit the vulnerability is granted by the client.

To complete this goal, the following objectives are defined:

* MTR Design will create a threat model for the application. The model will include the assets and the threat agents.

* MTR Design will inspect the application and map its functionality.

* Based on the application map, MTR design will create a detailed test plan with scenarios and test cases, which will be executed against the target application (this document).

* MTR will submit the test plan to <Client> by the <DATE>.

* The security team will test the Web application defined in the test scope for the OWASP top 10 vulnerabilities as described in this test plan.

* The security team will report the progress of the testing to the <Client> SPoC periodically.

* If vulnerability is found, the security team will verify it after they receive approval from the client SPoC.

* The security team will produce a conclusion report, which will contain assessment of the security of the Web application, description of the vulnerabilities and recommendations on how to remediate the issues that may be detected during the test. The Conclusion Report will be submitted by <DATE>.

* The security team will present the conclusion report on <DATE>.

All information obtained during the test will be processed, analyzed and stored in accordance with the MTR Design security practices and data handling policy.

Good, we finally get to the real stuff. Next you have to define the

Test Scope

It should include several things. First, you have to describe the

Target System

Here, you can use a table with two columns. In the first column, you should have (at least) the following:

• Target System Name
• Target System URL(s)
• Test Type
• Production Environment
• Intrusive Tests
• Client Awareness
• Technology
• Development Framework
• Functionalities
• Login Credentials

The second column should contain the details.

Then, you list the

Tests

You can use bullets to list the test you will perform against the application. The OWASP Top 10 are a good start. Of course, here you will need to have in mind the specifics of the assessment you are doing.

After that, you describe the

Tools

you will use to perform the tests. Don’t forget to add ‘custom scripts’ to the list, in case you need to code some script for the task.

The final section of the ‘administrative’ part of the PTP is a list of the

IP Addresses

Yet another table with two or three columns: Tester, IP Address, Zone (External/Internet, Internal/VPN).

Now, we are getting to the ‘technical’ part of the testing plan. I would start it with an

Application Map

section. Remember how the CEOs cannot read plain text? Include a picture of the application, describing the process flow and the functions of the application. You may also include a list of the dynamic and static URLs.

To create the application map, you can use Burp Pro, or manually browse through the application and take notes. It is important to include everything that you plan to attack during the test.

When you have a good understanding of the application and the client, you can document the

Threat Models

In this section, you need to describe the reasons an attacker would have to attack the application. You will be putting their shoes on after all. So you will have to have a good understanding of both the client and the application. Of course, you will include hactivism, and skids, but you also need to have specifics — for example, is the application storing sensitive data that could be the target of a hacker, and so on.

The next section that should be included is about the

Scenarios

you will replay. Each scenario should have a short description and a list of the actions a possible attacker would make to take over the application: passively gather information, browse through the application, search for attack vectors, attack as unauthenticated user, brute-force login forms, try as authenticated user, etc.

Then, you have to describe the specific

Tasks

you will have to complete during the test. Each task should have a

• Title: this is the specific test you will do.
• Task Description: a short description of the test.
• Sub-tasks: the specific actions you will take.
• Task Goal: what you are trying to achieve.
• Task Tools: what you will use.Task Risks: how the task can affect the application.

Here is a short example:

Data Validation Testing

Task Description

Test the application for data validation flaws such as XSS, SQL Injection, overflows, format string issues, and HTTP Splitting.

Task Goal

Identify any potential entry point and test user input for injections.

Subtasks

• Manipulate HTTP requests and observe HTTP responses.
• Tamper with user input.
• Test for SQL injections.
• Test for XSS.
• Test for code injections.
• Test for command injections.

Task Tools

• Browser and browser extensions
• Local proxies
• SQL Injection tools (sqlmap)
• w3af

Task Risks

• Application crash.
• Server overload.

And this is the end of the Penetration Testing Plan. As promised, we talked alot about it, but this plan will be the basis of your

Final Report

Actually, most of the PTP goes into the conclusion report. Again, you have the Purpose of This Document, Revision History, Project Definition, Test Goals and Objectives, and Test Scope sections. You can also include a Terminology section, because while the PTP may have been approved by a more technical person, the people that will get the final report may not be that technical.

Then you will have to place a

Summary of Findings

section. Decision makers do not have the time to go through the entire report, so it is important that this one comes first. Here, you will summarize all your findings in a language that a non-technical person can understand. It is always a good idea to include a colored table with the vulnerabilities and the risks they are posing to the application and the company. If you are good at charts, don’t hesitate and include one. A friend of mine, who is a really good manager says that “if it doesn’t have a pie chart, I would not bother looking at it.” As sad as this is, this is the truth. When you are managing a big company, everything becomes a table or a chart to you, so don’t spare them to the readers of your reports.

If you include a table with the vulnerabilities and the risks, take your time and describe them in short paragraphs one by one. You can include a couple of screenshots here to make your point.

When you are done with this, it is time for the

Recommendations

section. After this section, most decision makers would stop reading, so do your best. Take each individual issue and make a recommendation on how to fix it. Be concise and to the point. This section should be pretty straightforward.

Now, you can start writing for the technical staff. The next section is the

Details on the Findings and the Recommendations

Here, you should include all technical details on how to recreate each issue and how to fix it. Go through the entire process of the test, starting from the information gathering. Go through your actions, describe the findings and issue technical recommendations.

For each test, described in the PTP, provide the details of the tasks and the results of the tests. You can include other documents with the results from the automated tools to keep the report short.

After that, you need to include a

Conclusion

section. It can be one to three paragraphs, summarizing the results of the entire assessment. Basically, in this section, you need to answer to the question that was set as a test goal previously.

If there is data that is short and important enough to go in the report, you can include an

Appendices

section.

And that is it!

Finally

I have to say that I wrote this post in a heart-beat, in a very nice tavern, and my phone is screaming for low battery, so my Internet time for the night is coming to an end. I am not really tracking my time (all the time). I hack things, and I am good at it.

The report I was writing about is not a vulnerability report from an automated tool. What we do is not what some companies sell as penetration testing. We do most of the things manually. When we use automated tools (mostly fuzzers), we verify every finding by hand. I have yet to meet the hacker that would use IBM AppScan to hack a site…

And we would give a sample testing plan and a sample report to anyone who asks for it. I am proud of the work we do, and I firmly believe that information has to be shared. I would also welcome suggestions on how to improve it, so don’t be shy and share your thoughts!

If you liked this article, then please subscribe to our newsletter. Every month we’ll send out an email with a few articles written by our team about the business, web development, UX design and startups. We hope they will be useful to you and will help you solve some of your digital-related problems.

Originally published on the MTR Design company website.

MTR Design is a small Bulgarian web development company with expertise in a wide range of technologies (PHP, Python, Golang, Lua, Salesforce, Node, React and React Native, Angular, VueJS, iOS and Android development). We are currently open for new projects and cooperations, so if there are any projects we can help with, please react out (use the contact form on our website, or email us at office@mtr-design.com) and we will be happy to discuss them.