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

  • rowser 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!

Leave a Reply

Comments

LadyBug

I’m sorry, but any web app pen tester who does not give OWASP testing guide or OWASP ASVS as references, doesn’t seem to be very knowledgeable.

mitchell

Thank you for your comment. If you do not have the time to read the post, you can hit Control-F and enter OWASP. You might be surprised. And I don’t pretend to be knowledgeable.

Cristóbal

Hi, I’m a student who wants to learn about security procedures, I’m interested in the sample testing plan. Please, can you give me more information??

Thanks a lot.

    mitchell

    Sent. :-)

james

@Ladybug – A monkey can criticize! Your true colors are showing. But I suspect your coworkers have seem them many many times. Mitchell is only trying to provide some insight and help. Your provide nothing.

Nazim

Great write-up Mitchell! I think it would be a good idea to give risk scores as well as most of the customers are interested in numbers, rather than limiting it to critical/high/medium/low classification alone. It would look even better with risk scores mapped onto a fancy chart. :)

rBg

I think that for starting it is pretty good, but you need to remember that you are preparing this for a “suit” to read, so it needs to be not really dumbed down to maybe prepared a bit differently. If you would like to send me your email or contact me somehow, I could send you some reports I have written up or even some scopes of work I have done with networks.

sateesh

Hi,
Very Intresting Report Template. Could you please share samplpe testing plan? I would like to learn.

Manoj Singh

One section should be there to emphasis on legal ownership of the report
CONFIDENTIALITY AND Legal INFORMATION : This section should cover legal ownership who and document report is sole property of ABCD

mitchell

Thank you, guys for your comments. I’ve sent a sample report to whomever requested it. @Manoj, you are absolutely right.

Yaakov

I’d also be very grateful for a copy of your sample testing plan.

    mitchell

    Sent.

Peter

Thanks for your article, always nice to read how fellow pentesters report their findings.

“if it doesn’t have a pie chart, I would not bother looking at it.”. Hmm. my company never uses charts in pentesting reports. Never. I think that a good, clean layout with sparse use of colors can do wonders.
1 vulnerability having a high impact versus 100 vulnerabilities having low impact. I would like the client to focus on the high impact vulnerability, and a pie chart might not convey this the right way.

Would it be possible for me to get a sample report ? Thanks!

Joost Heggen

nice report i’d say, im still studying information security. is it possible to receive a sample as well? thanks

danielsingh

Awesome article Micthell, thanks and hope to receive a sample report. Looking forward to more good stuff. :) CHEERS!

Gabriel

Hi Mitchell,

I came across this article looking for relevant info about the very same topic. I would appreciate if you can provide me too a sample testing plan and a sample report.

Thanks a lot,
Gabriel

    mitchell

    Sent :-)

Kris

Hi Mitchell, Am quite new to pen testing and just on a learning curve at uni level. your report has given me very good insights. Are you please able to share with me some more resources or a sample plan. your efforts are much appreciated.

    mitchell

    Hi, Kris. I sent you a sample plan and some more resources. I am glad, that you liked the post :-)

invictus

I have subscribed on your RSS feed. Great article Mitchell! These really complement your another article http://www.websecuritywatch.com/why-a-pentest/ .

May I request for your security testing procedures/sample testing plans? Cheers!

    mitchell

    Hi, invictus.

    I’ve sent you the penetration testing docs.

    Cheers!

Maverick

Hi Mitchell,

Great write-up! I would appreciate if you could email me as well the sample testing plan, the report and other related resources. Thanks.

    mitchell

    Sent :-)

Simone

Hi Mitchell! Great, great post.

I would like very much to receive your sample report to my email.

Thanks in advance!

    mitchell

    Sent.

Fernando Perez Casas

Very good article, it’s not difficult to find tons of information about Ethical Hacking, Exploting, Reverse Engineering…and start playing ctfs but it’s hartd to find good professional pentest reports samples/templates, or at least a few good ones to get a general idea for beginners in professional pentesting. I’ve done lots of technical docs/reports on system integration projects but not for pentesting… Could you please send me a sample testing plan and a sample report of a web pentesting please? If you do you also have one of non web pentestings could you also send me it? Thanks in advance.

    mitchell

    Thanks, Fernando. I’ve sent you the docs.

Joseph

Thank you for writing this up. I too have searched near and far for samples and have come up with only a few. Would be still be able to send over the sample testing plan and report? Thanks in advance.

    mitchell

    Sent.

Barry

Hi, Mitchell,

My organization, iNetwork, Inc. is a DOD services contractor located in San Diego. We are looking to diversity in 2014 and considering penetration testing as one potential market which might provide a more commercial focus to our business.

I would greatly appreciate a copy of the sample test plan and report you reference above.

Thanks in advance for your assistance

BB

    mitchell

    Sent.

CyberNemo

Nice approach to present the pen test finding and Report….You have covered almost everything to be reported to various tiers of Management and Technology. I think its upto the individual testers to pick and choose the sections they would like to report on according to the tier they are putting a report for. I would be interested to see your sample report so if you could send that to me that would be really helpful.

    mitchell

    Thank you for your comment. I sent you a sample report.

pranita

Very helpful information….

pau

Thank you for sharing and taking care of a usually neglected subject, nice post :)

May I have a copy of your sample documents?

Thanks a lot!

    mitchell

    Sent.

Doug

Nice write up. I stumbled across this post and it was just what I was looking for.

Please send the sample docs when you get a chance.

Thanks

    mitchell

    Thanks, I sent you the docs.

LearnSec

Hi Mitchell,

Thank you for a great article, I’m busy with Information Security and can’t find any great documentation / reports. Will it be possible to send me sample documentation on pre-engagement etc?

Kind Regards

    mitchell

    Thanks for the comment. Just sent you the documents.

Carlos Salgado

thanks for this interesting post, right now I’m doing a research on my company to implement pentesting as a service. could send the documentation: Test Plan and report to get an idea about this?
 
thank you very much

    mitchell

    Sent :-)

Ob

Mitchell, great post! Could you please send me the sample report as well?

Thanks for the great info.

    mitchell

    Thanks for the comment. Docs are on the way.

Scott

Hi Mitchell, thanks for the great info. It will be useful for a class I am taking for my graduate degree. If you have a minute could you send me the sample report? I would greatly appreciate it.

    mitchell

    Sent. Good luck with the class :-).

JOS

Hi Mitchell, great post – thanks for the info. May I have a copy of your sample documents please.

Many thanks.

    mitchell

    Sent.

Reva

Clean and precise writing…appreciate the efforts…I am a student and quite the beginner at Pen testing… I have a question for you, when you think of web application security assessment reports, people (exec/suits) expect to see some sort of numbers on the issues identified..so that they can plan on implementing the recommendations written in the report…hence the charts, graphs , tables and the works….now, is there a better way of representing this data in a concise form? Thoughts are welcome……and oh yeah, I’d love a sample of your tests and guide to pen testing :) Thanks !!!

    mitchell

    Hi, Reva.

    I sent you the documents. I don’t think that there is any other way to represent the data in concise form. Tables and graphs are becoming the standard.

Tomas

Hi. I think this is a great article, with a good coverage of all report sections. Could i have a sample of the reports you mention?

Thank you in advance!

    mitchell

    Thank you Tomas. I sent you the sample.

Verónica

Great articleI would appreciate if you could email me as well the sample testing plan, the report and other related resources. Thanks.

    mitchell

    Sent :-).