EH - Module 4

MODULE 4

Report Writing

Report writing is a comprehensive task that includes methodology, procedures, proper
explanation of report content and design, detailed example of testing report, and tester’s
personal experience. Once prepared, the report is shared with the senior management staff
and technical team of target organizations.

Report Writing Stages

Due to the comprehensive writing work involved, penetration report writing is classified into
the following stages :

• Report Planning
• Information Collection
• Writing the First Draft
• Review and Finalization

Report Planning

Report planning begins with the objectives, which help readers understand the main purposeof
the penetration testing. It describes why the testing is conducted, what are the benefits and so
on. Report planning also includes the time taken for the testing.

The major elements of report writing are:

• Objectives − It describes the overall purpose and benefits of pen testing.
• Time − Inclusion of time is very important, as it gives the accurate status of the system.

In case anything wrong happens later, this report will protect the tester, as it will
illustrate the risks and vulnerabilities in the penetration testing scope during the specific
period of time.
• Target Audience − Pen testing report also needs to include target audience, such as
information security manager, information technology manager, chief information
security officer, and technical team.
• Report Classification – Reports need to be classified properly as it is highly confidential
carrying server IP addresses, application information, vulnerability and threats.
However, this classification needs to be done based on the information classification
policy of the target organization.

• Report Distribution – The number of copies and report distribution should be
mentioned in the scope of work. It also needs to mention that the distribution of
hardcopies can be controlled by printing a limited number of copies attached with its
number and the receiver’s name.

Information Collection
Because of the complicated and lengthy processes, pen tester is required to mention every step
to make sure that they collected all the information in all the stages of testing. Along with the
methods, they also need to mention details about the systems and tools, scanning results,
vulnerability assessments, details of the findings, etc.

Writing the First Draft
Once, the tester is ready with all tools and information, now they need to start the first draft.
Primarily, they need to write the first draft in comprehensive detail, mentioning everything i.e.
all activities, processes, and experiences.

Review and Finalization
Once the report is drafted, it has to be reviewed first by the drafter himself and then by his
seniors or colleagues who may have assisted him. While reviewing, it is expected that the
reviewer checks every detail of the report and finds any flaw that needs to be corrected.

REPORT FORMATING
Report formatting is the done in a proper way so that the report is correctly prepared
The format should be follow the following:
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 must have several sections. If you want to make it good looking, include your
company’s cover page.

Usually, you can put 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, you must include a Table of Contents. It is a known fact that C-level executives and
decision makers don’t do well with plain text. The table of contents will let them know exactly
where to skip to.

You would also want to include a section regarding:

Purpose of This Document

It should clearly state what this document is about. For example:

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. Also, it summarizes the scope of the test as
well as outlines the scenarios and the tests that will be performed by the testing team.

The next sections 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.

Revision History

This is another section that details the changes made on the document by the people who have
contributed to it. The columns here are Version, Date, Author, and Comments/Notes.
Project Definition
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 pen tester knows how quickly things change
in the security industry, so it is a good idea to include a section about:
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 clients based on earlier conversations 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.

Test Scope
It should include several things.

a. Target System
Here, you can use a table with two columns. In the first column, you should at least have 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.

b. 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.

c. Tools

These are 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. It 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

Include a picture of the application, describing the process flow and the functions of the
application to make it easier for management to understand. 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

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

It enlists the 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 an example:

Task: 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.

This plan will be the basis of your

Final Report

Most of the PTP goes into the conclusion report. Again, you will 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
familiar with technical jargon.

Then you will have to place a section regarding:

Summary of Findings

It is important that this one comes first as decision makers do not have the time to go through
the entire report. 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. When you are managing a large organization,
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

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
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
Appendix

General Process
1. Planning
2. Footprinting
3. Exploiting
4. Reporting

1. Planning
In this step the security researcher covers the points eg:
a. Test Name.
b. Scope of work.
c. Contract or NDA.
d. Conduct.
e. Type.
f. Team details.

2. Footprinting
a. Scanning.
b. Analyzing.

3. Exploiting

a. Alert Level.
b. Detail information about Alert.

4. Reporting
a. Compiling a report and updating the system.

References:

Penetration Testing Report Writing- Tutorials Point
https://www.tutorialspoint.com/penetration_testing/penetration_testing_report_writing.htm
The Penetration Testing Report- MTR Design
https://medium.com/@mtrdesign/the-penetration-testing-report-38a0a0b25cf2