Writing An Effective Pentest Report v1.0 Rev 10022016 by Semi Yulianto

PENETRATI
ONTESTI
NGREPORT
Writing an Effective
PENETRATION TESTING REPORT
AN EXECUTIVE VIEW
By
Semi Yulianto
© 2014
This book is dedicated to my beloved sons who always inspire me
Andryanto Eka Wijaya

Arvin Ellares Yulianto
Also my gratitude to my parents and family

About the Author
Semi Yulianto is a dedicated information security consultant and technical trainer who has
more than 20 years working experience in the IT industry with experience in the area of
Application and Software Development (Database and Management), Operating Systems,
Server Systems, Messaging and Collaboration, Inter-networking, Network Infrastructure,
Desktop Support and Application (Secure Programming & SDL) and Network Security. He
holds several IT professional certifications namely MCT, MCSE, MCTS, MCITP, CCNP, CNE,
CNI, CCA, CEH, CHFI, ECSA, ECSP, EDRP, CEI, SSCP, CISSP, CASP, CSSLP, CISA, and CISM.
Mainly conduct and deliver IT technical training for entry level users and IT professionals.
Instructional scripts includes delivery of Microsoft Windows OS, Novell NetWare and SUSE
Linux OS, Novell GroupWise, Novell ZENworks for Desktop/Server, CCNA (Routing and
Switching), CCNP (Routing, Switching, Remote Access and Troubleshooting), Citrix
MetaFrame or Citrix Presentation Server, CIW Security, EC‐Council (CEH, CHFI, EDRP, ECSA &
ECSP), Network, Systems & Wireless Security, Hacking & Penetration Testing, CISSP, SSCP,
Digital Forensics and other related IT courses.
Has trained IT Professionals from diverse organizations in Asia Pacific & Middle East region
(Indonesia, Malaysia, Singapore, Thailand, Bhutan, Cambodia, Philippines, Kingdom of Saudi
Arabia, Tunisia, and South Korea). Proven track of records in delivering high-quality IT training
with full clients’ satisfaction.
Deep knowledge and excellent skills on Vulnerability Assessment, Ethical Hacking,

Penetration Testing, IT Auditing and Computer Forensics with a combination of Technical and
Management expertise. Interested in Exploit Writing, Malware Analysis, Forensics on Moving
Data, and Cloud Computing Security. Developed and Created: Realistic Ethical Hacking,
Penetration Testing & Computer Forensics Hands-On Lab Exercises (Virtualized Environment)
to improve and enhance the learning experience.
Successfully delivered IT Security Awareness & Practical IT Auditing workshops and seminars
for various private organizations (banking and financial institutions) and government
agencies in Indonesia.
Involved in various projects related to vulnerability assessment and penetration testing

(network infrastructure and application), IT audit based on COBIT, ISO/IEC 27001 and PCI DSS.
Mission: 'To create Awareness and Educate People in Information Systems Security.'
Feel free to contact the author through: semi.yulianto2009@gmail.com
Comments and suggestions are welcome.
Jakarta, November 2014
Semi Yulianto
This page is intentionally left blank
TABLE OF CONTENTS
CHAPTER 1 .............................................................................................................. 1
Introduction............................................................................................................................................. 1
High-Level Security Assessment ........................................................................................................ 2
Tools of the Trade.................................................................................................................................. 3
Business Case ........................................................................................................................................ 4
Planning and Preparation ..................................................................................................................... 5
Risk Management .................................................................................................................................. 6
Gathering and Translating Raw Data .................................................................................................. 8
Analyse and Filter Your Data ............................................................................................................ 8
Converting Data .................................................................................................................................. 8
Secure Data Exchange/Transmission ............................................................................................ 9
Translating Raw Data ........................................................................................................................ 9
Project Proposal............................................................................................................................... 10
Project Activities .................................................................................................................................. 12
Deliverables .......................................................................................................................................... 12
CHAPTER 2 ............................................................................................................14
Technical Report Writing .................................................................................................................... 14
Standards and Templates .................................................................................................................. 15
Report Format ....................................................................................................................................... 17
Content Structure................................................................................................................................. 18
Things to Focus On .............................................................................................................................. 21
Things to Emphasize ........................................................................................................................... 21
Dos and Don’ts...................................................................................................................................... 24
Reporting Best Practices .................................................................................................................... 25
CHAPTER 3 ............................................................................................................26
Document History (Versioning) ......................................................................................................... 26
Error Checking and Revision .............................................................................................................. 29
Additional Things to Remember ........................................................................................................ 32
Writing Your 1st Report ........................................................................................................................ 33
Polishing Your Report ......................................................................................................................... 35
Maintaining Your Report ..................................................................................................................... 36
Converting Your Report Format ......................................................................................................... 38
CHAPTER 4 ............................................................................................................39
Putting Them Together ....................................................................................................................... 39
Enhancing Your Report ....................................................................................................................... 39
Housekeeping ....................................................................................................................................... 40
Summary and Conclusion ................................................................................................................... 40
Appendices ........................................................................................................................................... 41
References ............................................................................................................................................ 41
CHAPTER 1
Introduction
Penetration test or known as pentest or pen-test is a typical security assessment which is the
process to gain access to specific information assets (e.g. computer systems, network
infrastructure, or application). Penetration test simulates the attack performed internally or
externally by the attackers which have the intention to find security weaknesses or vulnerabilities
and validate the potential impacts and risks should those vulnerabilities being exploited.
Security issues found through penetration test are presented to the system’s owner, data owner
or risk owner. An effective penetration test will support this information with an accurate
assessment of the potential impacts to the organization and range of technical and procedural
safeguards should be planned and executed to mitigate risks.
Many penetration testers are in fact very good in technical since they have skills needed to
perform all of the tests, but the lack of report writing methodology and approach which create a
very big gap in penetration testing cycle. A penetration test is useless without something tangible
to give to a client or senior management. Report writing is a crucial part for any service providers
(e.g. IT service/advisory). A report should detail the outcome of the test and, if you are making
recommendations, document the recommendations to secure any high-risk systems.
The target audience of a penetration testing report will vary, the technical report will be read by IT
or any responsible information security people while executive summary will definitely be read by
the senior management.
Writing an effective penetration testing report is an art that needs to be learned and to make sure
that the report will deliver the right information to the targeted audience. Detailed steps will be
covered in the next subsequent modules.
1
High-Level Security Assessment
Security assessment offered by service providers in a variety of ways. Each type of service
provides different levels or degrees of security assurance.
Vulnerability assessment (VA) or vulnerability scanning normally offered with the objective to
identify weaknesses or vulnerabilities. Uses automated systems (such as Nessus, eEye Retina or
QualisysGuard). An inexpensive way to make sure no vulnerability exist. Does not have a clear
strategy to improve organization’s security.
Network security assessment is a combination of automated and hands-on manual vulnerability

identification and testing. The report is created, giving practical advice which can improve
organization’s security.
Penetration testing involves in multiple attack vectors (e.g. wireless testing, social engineering or
client-side testing, or war dialing) to compromise the target environment. Penetration testing can
be done with several accepted methodologies from the internal and external environment with
different approaches such as black-box (with no prior knowledge), white-box (with full knowledge)
or grey-box (with some knowledge) depending on the scope of work agreed with the client.
Onsite auditing probably is the most common type of security assessment done in many
organizations. It provides the clearest picture of network security. Local access is given to the
testers or consultants which allow them to explore and identify anything untoward, including
rootkits, backdoors, Trojans, weak passwords, weak permissions or policies, misconfigurations,
and other issues.
The best practice assessment methodology used by security consultants should involve the
following high-level components:
 Network reconnaissance to identify networks or hosts

 Bulk network scanning and probing to identify potentially vulnerable hosts
 Vulnerability identification and investigation and further probing (manually)
 Exploitation of vulnerabilities and circumvention of security mechanisms
2
Tools of the Trade
Selecting the right and correct penetration testing tools will help us to focus on the information
(data) to be collected from the target environment. Do not directly confused with the variety of
tools available in the market. Knowing the capabilities and features of the tools is the key to
successful security assessment. Start by evaluating Open Source and commercial tools available
on the Internet. Compare the Open Source with the commercial ones in terms of functions,
features, and deliverables. Make sure that the tools you will be choosing can be used through the
entire security assessment process. Do not waste your budget to purchase some commercial
tools which you don’t really want to use due to the lack of capabilities and features. Test the tools
before buying them.
Categorizing security assessment tools will help you to find what you are looking for. The
following are the examples of tools commonly used for security assessment which has been
categorized based on the usage objectives:
Network reconnaissance & scanning
• Nmap or ZenMap (open source)

• Hping (open source)
• NetDiscover (open source)
• NBTStat (open source)
Vulnerability identification & investigation
• Nmap with NSE (open source)

• Nessus (commercial)
• eEye Retina (commercial)
• QualisysGuard (commercial)
• OpenVAS (open source)
3
Exploitation of vulnerabilities
• Metasploit Framework (open source)

• ExploitPack (open source)
• Core Impact (commercial)
• Metasploit Express and Pro (commercial)
• Immunity CANVAS (commercial)
Most of the tools shown above are available on BackTrack/Kali Linux as well as BackBox Linux
penetration testing distributions.
As for the penetration testing methodologies, we can create our own or adopt from several well-
known standards such as:
 NIST SP 800-115, Technical Guide to Information Security Testing and Assessment

 OISSG ISSAF, Information Systems Security Assessment Framework
 ISECOM OSSTMM, Open Source Security Testing Methodology Manual
 OWASP Testing Guide, Open Web Application Security Project
 SANS Institute, Conducting a Penetration Test on an Organization
 PTES, Penetration Testing Execution Standard
Business Case
Why conduct penetration test? What are the objectives of a penetration test? What are the
benefits of penetration test compared to other types of security assessments?
Those are probably the most common questions raised when we talk about the importance of
penetration test to a prospective clients or organizations.
Answers to the above questions are explained as follows:
4
From a business perspective, penetration testing helps safeguard your organization against
failure, through:
 Preventing financial loss through fraud (hackers, extortionists and disgruntled employees)
or through lost revenue due to unreliable business systems and processes.
 Proving due diligence and compliance to your industry regulators, customers, and
shareholders. Non-compliance can result in your organization losing business, receiving
heavy fines, gathering bad PR or ultimately failing. At a personal level, it can also mean
the loss of your job, prosecution and sometimes even imprisonment.
 Protecting your brand by avoiding loss of consumer confidence and business reputation.
From an operational perspective, penetration testing helps shape information security strategy
through:
 Identifying vulnerabilities and quantifying their impact and likelihood so that they can be
managed proactively; budget can be allocated and corrective measures implemented.
Planning and Preparation

Prior to starting a penetration testing project, careful planning and preparation should be done.
Assembling a team is part of the planning itself. A solid team should have members from multiple
knowledge areas based on skills and expertise. The scope of work determines the requirements
to assemble a small or large team. Do not just focus on the penetration testers only, ensure that
you can cover several areas related to project management, quality assurance, network and
infrastructure, applications, risk analysis, etc.
5
Figure 1: Sample Pentest Project Team (Small)
Pentest Project
Team
Senior Security Network

Proiect Manager Quality Assurance Application
Analyst/Lead Infrastructure
(PM) (QA) Specialist
Pentester Specialist
Security Security Technical

Analyst/Pentester Analyst/Pentester Documentation
Figure 2: Sample Project Team Resources (Small)
No. Position/Function Resource Name

1. Project Manager (PM) A
2. Quality Assurance (QA) B
3. Senior Security Analyst/Lead Pentester C
4. Security Analyst/Pentester #1 D
5. Security Analyst/Pentester #2 E
6. Technical Documentation F
7. Network Infrastructure Specialist G
8. Application Specialist H
In the above example, we use 8 (eight) resources to perform several tasks in a small pentest
project. Always remember the successful project factors or components: scope, schedule, budget
and resources.
Risk Management
Risk calculation and analysis are part of the overall risk management. An effective penetration
testing report should include at the minimum, risk calculation, and analysis. Guide to risk
management can be easily found from several resources on the Internet (e.g. NIST SP800-30,
Risk Management Guide for Information Technology Systems).
6
Components of risk analysis explained as follows:
Threat - a possible danger that might exploit a vulnerability to breach security and thus cause
possible harm.
Vulnerability - a weakness which allows an attacker to reduce a system's information assurance.

The vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker
access to the flaw, and attacker capability to exploit the flaw.
Impact - a successful threat exercise of a vulnerability (internal or external).
Risk rating based on this calculation:
Risk = Threat x Vulnerability x Impact
After calculating the risk rating, we start writing the report on each risk and how to mitigate it (risk
mitigation or reduction).
Figure 2: Risk Analysis and Rating Calculation
Risk Analysis
Threat Low Medium High Critical
Vulnerability L M H C L M H C L M H C L M H C
Impact Low 1 2 3 4 2 4 6 8 3 6 9 12 4 8 12 16
Medium 2 4 6 8 4 8 12 16 6 12 18 24 8 18 24 32
High 3 6 9 12 6 12 18 24 9 18 27* 36 12 24 36 48
Critical 4 8 12 16 8 16 24 32 12 24 36 48 16 32 48 64
Rating Calculation
L Low 01 – 16
M Medium 17 – 32
H High 33 – 48
C Critical 49 – 64
7
Figure 3: Sample Risk Analysis (Overall)
Host Type Threat Vulnerability Impact Risk

Network Devices 3.0 2.0 2.0 12.0
Operating 27.0
Systems 3.0 3.0 3.0
Average 3.0 2.5 2.5 19.5
Overall Risk = MEDIUM
Gathering and Translating Raw Data
Analyse and Filter Your Data

Penetration testing team members should collect useful information (data) from the field,
assuming that they are working in client’s environment. Analyse and filter information gathered.
Categorize information based on the adopted pentest methodology so that you can focus on
collecting “good and useful” data and not a bunch of trash. Always document your steps and
provide screenshots or any good evidence (this will be useful in case the clients want to repeat
the same testing processes). Step by step documentation is not really mandatory but they are
really helpful in certain situations. I did this a lot.
Converting Data
Data translation might be needed in certain scenarios. You might want all of your team members
to have a standard in translating collected data. Raw data can be easily translated to multiple type
of file formats such as text, XML, HTML, png, jpg and etc.
8
The following shows you an example of converting data from an XML to an HTML file format:
Run nmap with some options, input file, and output file
nmap <options> –iL <target_list> –A <output_filename>
Examples:
nmap -n –sS –sU –Pn –P0 –iL targets.txt –A output
Or
nmap -n –Pn –P0 –A –iL targets.txt –A output
Now we can convert the output.xml to output.html as shown below:
xsltproc output.xml –o output.html
The above command results three different types of files:
Filename File Type

output.nmap Text file
output.gnmap Grepable text file
output.xml XML file
Secure Data Exchange/Transmission

Raw data collected should be sent regularly or at a specific time period (scheduled), as agreed by
a team leader and members. Any information (data) collected is treated as “confidential” as
stated in the non-disclosure agreements (NDAs). Avoid sending any information through insecure
network or media. If you can’t avoid using the Internet for exchanging or transmitting the
information. Apply the confidentiality, integrity and availability on the data collected by
implementing the out-of-band method of transmitting data, as well as using encryption and
hashing such as MD5 to preserve the integrity of your collected data.
Translating Raw Data

Effective pentest report should include the representation of your collected raw data, translated
to a meaningful information in the different type of formats. The final deliverables should be easily
interpreted by the targeted audience.
9
You can use tools such as Microsoft Excel and Visio to create a meaningful presentation of your
information such as tables (detailed and summary), charts, diagrams, flows, and etc.
Figure 4: Sample Vulnerability by Type
No. Vulnerability Type Total

1. Default or weak password 10
2. Mis-configuration 4
3. Missing patches/updates 6
4. Weak encryption 2
5. Miscellaneous 5
Total 27
Figure 5: Sample Chart - Summary of Vulnerable Hosts
Miscellaneous 5
Weak encryption 2
Missing patches/updates 6
Mis-configuration 4
Default or weak password 10
0 1 2 3 4 5 6 7 8 9 10
Figure 6: Sample Summary of Vulnerable Hosts
No. Host IP Hostname Operating System Vulnerable Exploited? Risk Factor

1. 192.168.1.1 LON-RTR1 Cisco IOS 12.x Yes Yes High
2. 192.168.1.2 LON-RTR2 Cisco IOS 12.x Yes No Medium
3. 192.168.1.3 LON-SW1 Cisco IOS 12.x Yes Yes High
4. 192.168.1.4 LON-SW2 Cisco IOS 12.x Yes Yes High
5. 192.168.1.5 LON-DC1 Windows Server 2003 SP2 Yes Yes High
6. 192.168.1.6 LON-SVR1 Windows Server 2003 SP2 Yes Yes High
7. 192.168.1.7 LON-WEB1 Windows Server 2008 R2 SP0 Yes No Medium
8. 192.168.1.8 LON-APP1 Windows Server 2008 R2 SP0 Yes No Medium
Project Proposal
The proposal should be kept simple and precise. Project proposal is also called “Statement of
Work”, a persuasive document with the objectives to:
10
1. Identify what work is to be done
2. Explain why this work needs to be done
3. Persuade the reader that the proposers (you) are qualified for the work, have a plausible
management plan and technical approach, and have the resources needed to complete
the task within the stated time and cost constraints.
A strong proposal has an attractive, professional, inviting appearance. The information (content)
should be easy to access. A strong proposal has a well-organized plan of attack with clear
technical details because technical depth is needed to sell your project. It should have the “why,
what, how and when” components or aspects.
Project proposal should, at least consist of several sections as shown in the following examples:
1 Introduction
2 Detailed Project Plan
2.1 Scope of Work (SoW)
2.2 Target of Evaluation
2.3 Project Phases
2.4 Project Duration
2.5 Project Schedule/Timeline
3 Project Management
3.1 Project Organization
3.2 Resources
4 Deliverables
5 Tools and Methodology
6 Miscellaneous
7 Project Experience (based on your team’s experience)
8 Contact
9 Appendices
11
Project Activities
Activities related to a penetration testing project should be clearly defined. We can use this
document to track our project progress by placing the percentage of tasks done. Project
management portfolio tools can be used to help us in visualizing the project activities/tasks in a
form of Gantt chart.
Figure 7: Sample Project Activities
No. Activity/Task Estimated Duration Start End Complete (%)

(days) Date Date
1. Planning and preparation 2 <date> <date> <date>
2. Kick-off meeting 1 <date> <date> <date>
3. Initial assessment 2 <date> <date> <date>
4. Information gathering 5 <date> <date> <date>
5. Vulnerability identification 5 <date> <date> <date>
6. Risk assessment 3 <date> <date> <date>
7. Exploitation/penetration 5 <date> <date> <date>
8. Post-exploitation (optional) 3 <date> <date> <date>
9. Housekeeping (cleaning-up) 1 <date> <date> <date>
10. Risk calculation (analysis) 2 <date> <date> <date>
11. Reporting 3 <date> <date> <date>
12. Project Closing 1 <date> <date> <date>
Figure 8: Sample Gantt chart (not related to Figure 7)
Deliverables
Deliverable is a tangible or intangible object produced as a result of the project that is intended
to be delivered to a client or customer.
The result of a security assessment is a form of a deliverable. Deliverables in the form of reports
that will be delivered and reviewed by the client or senior management in several types or formats.
12
Type of deliverables in pentest project are:
 Executive Summary
 Technical Report
Executive summary report consist of the assessment findings include recommendations on how
to remediate risks (risk mitigation strategy) with appropriate security controls (safeguards).
Recommendations should cover the people, process, and the technology aspects.
Technical report consist of detailed information related to the assessment findings include
recommendations on how to remediate risks (risk mitigation strategy) with appropriate security
controls (safeguards).
13
CHAPTER 2
Technical Report Writing
Technical writing is a kind of writing which is done carefully for a specific audience. The
organization is predictable and apparent, the style is concise, and the tone is objective and
business-like. Special features may include visual elements to enhance the message. [1]
Penetration testing report is an example of the document produced as the output of a technical
writing which generally consist of common aspects such as:
 What is the subject?

 For whom was the document written?
 How is the document organized?
 How would you describe the writer’s (or writers’) style?
 What is the tone of the document?
 Does the document include any special features (for example, boldfacing, numbering,
bulleted lists, visual aids, headings, or subheadings)?
Technical report writing is an essential skill needed in the workplace and it allows you to express
the ideas in a formal way and reach the intended reader or audience so that they can read and
understand what we are trying to inform, and of course study at their convenience. When you
write your technical report, you demonstrate your ability to gather information (i.e. raw data from
the field), organize, analyze, solve problems, and understand technical processes.
Technical documents require more visual effort in order to grab the readers’ attention. We would
normally use several special features such as Font size and style, numbered and/or bulleted lists,
columns, color, graphs and tables, letterhead and logo, photos and drawing, sidebars, and clip art.
14
The Executive Summary report which “I can say” is one of the toughest document to write must
represents the high-level view of your work, related to findings, analysis, problems, and solutions.
This document must be carefully written in a specific manner and fully organized. It should
capture the ideas and information that you want to deliver or express. Remember, your intended
audience is the top-level management who do not usually have a good understanding on the
technical aspects, so write your report as accurate and precise as possible. Try to avoid using
many technical terms, or going to deep into technical aspects which in turn forgetting the actual
focus. Give a short and precise explanation, if possible in a Lyman’s term, so that your audience
can relate the information given to something that they know and understand well. You might
need to give a real-life example to emphasize the risk of “doing the right thing” and “not doing the
right thing”, to express the benefits and costs to certain actions such as preventive and corrective
actions. Cost and benefits analysis is an example of a good tool and technique you can use to
prove your concept.
Since the Technical report is intended for the technical audience, you can express the information
“as is”, but don’t forget, your audience might be coming from the different department or
functional areas. Some of them may not fully understand about some information you wrote. The
network and infrastructure group may not understand technical terms related to development
(applications or systems) while the developers group may be able to gain an understanding of
the topics being discussed or informed, and vice versa.
Standards and Templates

A couple of standards and templates are available for you to start writing a good penetration
report. The most important thing is that you need to organize your information to be presented in
your report.
Have a look at some examples here for your references:
1. NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
2. SANS Institute – Writing Penetration Testing Report

http://www.sans.org/reading-room/whitepapers/bestprac/writing-penetration-testing-
report-33343
15
3. Offensive Security – Penetration Testing Report Example
http://www.offensive-security.com/penetration-testing-sample-report.pdf
4. PTES Reporting Standard

http://www.pentest-standard.org/index.php/Reporting
A good example of an organize penetration testing report is a well-structured and organized

report that explains every single aspect which needs to be addressed in a report. Clear sections
for document controls, list of report contents, list of illustrations, the scope of work, project
objectives, assumptions, constraints, timeline, findings (vulnerabilities), recommendations,
methodology, approach, risk analysis, and references (i.e. SANS and PTES reporting).
Narrative report which explains the detailed step-by-step of the activities performed, such as
attacks types and techniques as well as vulnerabilities being identified, conclusion and risk rating
found to be interesting for technical audience but not to the executive level of audience (i.e. top
management), since it does not really capture the ideas and information being presented.
Executive level of audience is more concerned about the “impact” and “risk” of not being able to
put or implement security controls to mitigate or reduce risks associated to threats. By showing
the complete picture of threat, vulnerability, and impact and finally draw a conclusion about the
real risks that they are facing, we expect that the management would be more aware of the
potential impacts, and can provide a clear decision about what actions should be performed to
prevent or mitigate the risk, or whether they accept the risk or mitigate the risk by placing security
controls as well as improving their security posture.
You might want to combine several different standards into one which will then be adopted as
your own organization’s standard and template that will be applied to all penetration testing
project assignments. Start building one, and improve it over the time. Templates are reusable
company’s assets which will help us in keeping standards and speeding-up our project process
and produce good deliverables.
16
Report Format
Penetration testing report may come with different formats. They depend on how you would
express the ideas, opinions, and information captured from the assessments. It doesn’t matter
the type of format you choose, but remember the important points that you need to cover in your
report. Things such as document controls, list of report contents, list of illustrations, scope of
work, project objectives, assumptions, constraints, timeline, findings, recommendations,
methodology, approach, risk analysis, and references as discussed earlier in this module, would
at least give you a clear understanding of what should and must be in your report.
Here are several report formats you may find the market:
1. Narrative – good for the technical audience but not recommended for executive level of
the audience.
2. Well-structured – good for the executive level of the audience but does not really capture
the technical audience’s expectation.
3. Technical in depth – good for the technical audience and definitely not recommended for
executive level of the audience.
4. Hybrid (Mixed) – good for executive level of the audience but not too good for the
technical audience.
Ensure that you create a precise report format specially designed for the executive level of the
audience. This type of report format is also known as “Executive Report” while the technical in-
depth report should be designed with the idea of presenting the report to the technical audience,
this report format is also known as “Technical Report”.
Some organizations combine both report types into a single report, divided into two sections. The
first section covering the summary of the project intended to be for the executive level of readers
and the second section covering the technical details intended for the technical readers, and the
last few sections representing the supporting documents (i.e. step-by-step activities, detailed
evidence, scanning results, etc.), in the form of appendices.
17
Content Structure
Carefully organize your report into sections so that you could elaborate them as soon as you are
on that particular section. Sections help you to better organize the ideas, opinions, and
information you would like to cover and deliver as the results of the given assessment. The
content structure should generally be based on report formats and the intended audience. You
should start with drafting the report based on sections you have defined which normally should
focus on several areas of interests.
Start with creating a content structure based on the report format you choose. Fill out all the
necessary information you want to write in each section, then navigate slowly to the next section
while thinking what you are going to tell your audience.
Have a look at some of the following examples, taken from common report formats:
The Executive Report (Report ID: 001)
1. Executive Summary
1.1 Background
1.2 Scope of Work
1.3 Project Objectives
1.4 Assumption
1.5 Timeline
1.6 Summary of Findings
1.6.1 Overall Posture
1.6.2 Risk Ranking/Profile
1.7 Summary of Recommendation
2. Methodology
2.1 Planning
2.2 Exploitation
2.3 Reporting
3. References
18
3.1 Appendix A
3.2 Appendix B
3.3 Appendix C
The Technical Report (Report ID: 002)
1. Detailed Findings
1.1 Information Gathering
1.2 Vulnerability Assessment
1.3 Privilege Escalation
1.4 Exploitation
1.5 Post-Exploitation
2. Detailed Recommendation
2.1 High Risk
2.2 Medium Risk
2.3 Low Risk
3. References
3.1 Appendix A
3.2 Appendix B
3.3 Appendix C
The Hybrid Report (Report ID: 003)
1.1 Background
1.2 Scope of Work
1.4 Assumption
1.5 Timeline
1.6.1 Overall Posture
1.6.2 Risk Ranking/Profile
19
1.7 Summary of Recommendation
2. Methodology
2.1 Planning
2.2 Exploitation
2.3 Reporting
3.2 Vulnerability Assessment
3.3 Privilege Escalation
3.4 Exploitation
4. Detailed Recommendation
4.1 High Risk
4.2 Medium Risk
4.3 Low Risk
5. References
5.1 Appendix A
5.2 Appendix B
5.3 Appendix C
The above examples represent a well-structured report format. There is no definite way of
choosing “the best” report format. It’s all depend on your preference. Combining separate reports
into one is not a bad idea but again, think about your intended audience or reader. Too much
information in a report might confuse some readers while others would be happy to see as much
information as they expect to see in a report.
20
Things to Focus On
There are many things you probably need to be aware of when writing a penetration testing report
as part of technical writing skills. Having too many information might really be confused you,
especially on what, when, and how to start. So, we need to focus on several things that will help
us in producing a good and effective report.
Here is the summary of things you need to focus on when writing a penetration testing report:
 Type of audience (target audience)

 What the audience want to see (expected result).
 Organizing your report content (content structure).
 Making your report content easy to understand (Lyman’s term).
 Solving problems and not creating problems (problem-solution approach).
 The report should briefly explain the project result (product of a project).
The main idea is “do not make complicated things more complicated, instead, make them easier
to understand, digest/absorb”. Technical related matters would become much easier to
understand by using different approaches or methodologies (i.e. Lyman’s term, narration,
samples, analogy, and etc.), and improve the techniques over the time.
Things to Emphasize
When I started writing my penetration testing report, I have some difficulties of expressing my
ideas and opinion. Translating a bunch of raw data to a meaningful format that is easy to
understand and digest, would be a big challenge for me. Then, I started to find some information
from the Internet, and fortunately, I was able to find some references which allow me to start with
my own customized technical report. I noticed that many of resources or references that I used,
have the same characteristics, after analysing them carefully, I came up with a good methodology
which helps me in writing a more effective deliverables such as penetration testing report.
21
Summarizing my experience, here are some of the things that you need to emphasize on when
writing a good and effective report:
 Think about the audience and what they expect you to deliver. Better understand the types
of audience you want to reach.
 Executive level of management (top-level management, board of directors, senior

managers), like to see figures like profit, productivity, return on investment (ROI), return on
IT investment (ROIT), return on IT security investment (ROITSI), cost reduction, etc. –
anything that will make them satisfy, anything that will benefits the organization, ant not
the opposites.
 The report must be measureable, justifiable, comparable, and most importantly it must
capture the objectives of your penetration testing project. The report is an example of
deliverables which will assist the management on providing a quality decision, and should
improve the organization’s quality of products and services.
 Use tools and techniques to help you on explaining specific subjects (i.e. analogy, chart,
graph, tables, narration, and etc.).
Tools:
Narrative
There were identified:
- 7 vulnerabilities due to easily guessable credentials.

- 4 vulnerabilities due to missing patches.
- 3 vulnerabilities due to lack of OS hardening
22
Table and Chart
Figure 9: Summary of Vulnerability by Category (Table)
No. Vulnerability Category Risk Total #Affected Hosts

1 Default Password High 999 999,999
2 Weak Password High 999 999,999
3 Misconfiguration High 999 999,999
4 Weak Encryption Medium 999 999,999
5 Weak Protocol Medium 999 999,999
6 No Restriction Medium 999 999,999
7 Data Leakage Medium 999 999,999
8 Session Hijacking Medium 999 999,999
9 VLAN Hopping Low 999 999,999
10 Un-expected Error Handling Low 999 999,999
Total 999 999,999
Figure 10: Summary of Vulnerability by Category (Chart)
Vulnerability by Category
70
59
60
50
50
40
30
19
20
9
10 3 2 1 1 1 1
0
1
Default Password Weak Password Mis-Configuration

Weak Encryption Weak Protocol No Restriction
Data Leakage Sesion Hijacking VLAN Hopping
Un-Expected Error Handling
23
Dos and Don’ts
In fact, there are many areas of improvement we can make to produce a good quality of report
that is written effectively to reach the intended audience. Keep in mind that we are not perfect.
We made mistakes, but, of course we can always improve on something. Probably the Dos and
Don’ts would give you a simple guideline of “what should be avoided” and “what should not be
correctly done”.
Let’s check them out:
The Dos …
 Do focus on your audience

 Do focus on your report format
 Do focus on your content structure
 Do focus on your content details (what you are trying to tell/inform)
 Do use standardized templates (for consistency)
 Do avoid conflict of interests (separate report for separate audience)
 Do avoid the use of idioms, abbreviations, or rough words
The Don’ts …
 Don’t underestimate your audience (they might know better, advanced)

 Don’t give too much information (which may confuse the reader)
 Don’t put un-necessary things (garbage-in, garbage-out)
 Don’t use too many visual aids (as little as possible)
 Don’t use too many technical terms (for executive report)
 Don’t use too many abbreviations (explain them, glossary)
24
Reporting Best Practices
Now that you have learned some techniques about technical writing (i.e. penetration testing
report), next we will try to apply some best practices on how to create and improve the quality of
our reports. [2] [3]
 Analyze the audience (knowing your audience)

 Write reader-friendly documentation
 Use active voice (provide clear understanding)
 Get organized (a well-structured document starts with this)
 Break your document into smaller portions (i.e. sections)
 Give extra space or white-space
 Use cross-reference information
 Use visual aids, step/action tables (separate procedural with descriptive information)
 Create a quick reference chapter, section, or guide
 Create glossary of terms and abbreviations (if necessary)
 Create comprehensive indexes
 Fine-tune documentation
 Put complicated steps (step by step activities) as references
25
CHAPTER 3
Document History (Versioning)

To track and record detail of minor or major amendments we use document history and version
control. Document information which is normally placed right after the cover page should contain
a document history. A document history must contain at the minimum: version, date, document
name, and description.
The following is an example of a Document Information that includes document history:
Document Information
Document Details
Organization Name ACME
Document Title Network Infrastructure - Vulnerability Assessment and Penetration Testing
Report (VAPT)
Version <Version #>
Due Date 1 Dec 2013
Author <Author Name>
Pen-testers <Pentester #1>
<Pentester #2>
<Pentester #3>
Reviewed by <Reviewer>
Approved by <Approver>
Classification Confidential
Document Type Deliverable
Recipients
Name Title Department
<Recipient #1> <Title> <Department>
Quality Assurance
Date Name Title Completed
Issue <Date> <Issuer> <Title> <Date>
Review <Date> <Reviewer > <Title> <Date>
QA/Final <Date> <QA/Approver> <Title> <Date>
Approval
26
Document History
Version Date Name Description
<Ver #> <Date> Network Infrastructure - Vulnerability Assessment and Draft Report
Penetration Testing Report (VAPT)
<Ver #> <Date> Network Infrastructure - Vulnerability Assessment and Final Report
Penetration Testing Report (VAPT)
<Ver #> <Date> Network Infrastructure - Vulnerability Assessment and Final Report
Penetration Testing Report (VAPT) (Minor
Revision)
As for the version and revision number, they may be written as follows:
Version 1.0  Final Report Version 1.0

Version 1.0 Rev 0.1  Final Report Version 1.0 Revision 0.1 (minor revision)
Version 1.01  Final Report Version 1.0 Revision 0.1 (minor revision)
Version 1.0 Rev 1.0  Final Report Version 1.0 Revision 1.0 (major revision)
Version 1.1  Final Report Version 1.0 Revision 1.0 (major revision)
Note: It would be a good idea to put a complete date of your revision to reflect the actual date of
your revision (minor or major), as shown below:
Version 1.0 Rev 15122014  Final Report Version 1.0 Revision 15122014 (DDMMYYYY)
Version 1.0 Rev 0.1-151214  Final Report Version 1.0 Revision 0.1 (DDMMYYYY)
There is no specific standard on writing your version and revision number, as long as we can
capture the objectives of having document history to track minor or major changes, any format
would be accepted.
27
With Document Information placed after the cover page, the structure of your cover page should
be similar to the following:
1. Cover Page
1.1 Main Document Title
1.2 Document Title
1.3 Version Number
1.4 Date of Release
1.5 Company Logo
2. Document Information
2.1 Document Details
2.2 Recipients
2.3 Quality Assurance
2.4 Document History
Cover Page Example:
< Main Document Title >

< Document Title >
Version 1.0
< Date >
< Company Logo >
<Company Name>
28
Error Checking and Revision
Prior to releasing the final report, ensure that we have carefully checked any errors related to
spelling, grammar, vocabularies, typo, figures, charts, graphs, and etc. Start by creating a draft
report followed by gradually revising the report (minor or major).
Draft documents should start at (0.1) to reflect their draft status and then progress through
revisions by incrementing the number to the right of the point. It is just as important to keep track
of the different drafts of a document as it is to keep track of the current document once it has
been approved. The number of the draft document would revert to 1.00 upon the document
receiving the required approvals.
Although version control provides a mechanism for knowing where your document is up to, it is
not sufficient in itself to reflect details of minor amendments and reviews. The use of Document
History records the details of amendments.
For minor amendments, details of those amendments are required. For reviews, it is sufficient
to record ‘Major review of the document’.
Each document history and version number shows date each version was issued; who
authorized the amendment; and details the amendments made.
Document History and Version Control Example:
Version Number Date Approved Approved By Brief Description

Start from 1.00 <dd/mm/yy> <Approver> Include any position title changes,
Which approval amendments/additions to document
(minor amendments authority in the and details.
are .01, .02, etc.) organization Give a reason for the amendment.
(major amendments
are .1, .2, .3, etc.)
(reviews are 1.00, 2.00,

3.00, etc.)
Examples:
Version 1.01
Version 1.1
Version 2.0
Version 2.02
29
Of course, you can use any built-in grammar and spelling checker available in your word
processing application such as Microsoft Word, but I would also recommend using automatic
error checking tools related to grammar & spelling check as well as writing suggestions.
http://www.paperrater.com/ Grammar & Spelling Check

http://www.grammarly.com/ Grammar Check
http://spellcheckplus.com/ Grammar Check
We can gradually improve the quality of our reports by adding extra efforts to ensure that the
final release would not contain any significant errors.
Dissecting Report
Now let us check our report structure based on what we have learned before. The following is an
example of a hybrid report type which consists of the executive summary and technical details.
Complete Report Structure:
1. Cover Page
2. Document Information
3. Table of Contents
4. Introduction
5. Document Scope
5.1 Scope of Test
5.2 Limitation
5.3 Purpose of Test
6. Project Details
6.1 Project Description
7.1 Summary
7.2 Approach
7.3 Scope of Work
30
7.5 Timeline
7.6.1 Vulnerability Assessment (VA)
7.6.2 Configuration Security Audit (CSA)
7.7 Summary of Recommendations
8. Methodology
8.1 Planning
8.2 Exploitation
8.3 Reporting
8.3.1 Risk Analysis
9.1 Detailed Systems Information
9.1.1 Vulnerability Assessment (VA)
9.1.2 Configuration Security Audit (CSA)
9.1.3 Overall Risks
9.1.4 Passwords/Keys Found
9.2 Vulnerable Hosts
9.2.1 Host #1
9.2.2 Host #2
9.2.3 Host #3
10. Conclusion
11. References
12. Appendices
Feel free to modify or adjust your report structure based on the report format you have chosen to
be used as your company’s report templates (refer to the previous lesson regarding Report
Formats).
31
Sample Reports
To clearly understand how the final report will look like, we will look at a sample report produced
as a deliverable, based on the actual penetration testing project which covers the executive
summary and technical details (hybrid).
Refer to the attached Sample Penetration Testing Reports.
Note that the report structure may vary from other report formats.
Additional Things to Remember

Do you still remember about what is the main purpose of having a penetration testing project?
Well, let us refresh our mind again. The main purpose of a penetration testing is to measure the
effectiveness of our security controls. It is as simple as telling your client’s organization on what
the attacker can potentially do to their environment. Penetration tests eliminate the guesswork
involved in protecting your network by providing you with the information you need to effectively
prioritize your vulnerabilities. In other words, assessing and measuring your organization’s
security posture. Penetration testing project involves several methods to gain entry to the target
of evaluation (network, infrastructure, application, and etc.), to identify exploitable weaknesses,
and to reveal what systems and data are at risk.
So, why does it matter? A clear understanding of the main purpose of a penetration testing will
give you an idea on how to effectively capture it and put the details in your report. To the executive
audience, threats, impacts, and risks are the main things that they want to know. To the technical
audience, we can freely elaborate all the technical aspects with respect to threats, vulnerabilities,
attack vectors, and exploitation (proof of concept).
Again, focus on what you want to show to your intended audience, be honest on what they are
about to see, whether it is good or bad. Don’t think that if your report shows bad results then the
management will be mad at your or to the responsible person in charge or PIC. A good penetration
testing report should always captures: threat, vulnerability, impact, and risk. Risks will then should
be managed (e.g. avoid, mitigate/reduce, transfer or accept). We could, later on, prioritize risks
based on their severity and place controls to effectively manage risks. Follow-up should be done
32
accordingly by creating a list of prioritize risks also known as a Risk Treatment Plan (RTP), which
will be used by the person in charge to follow-up the risk management activities.
Additionally, if you need to provide more detailed evidence about your findings (e.g. proof of
concept (POC), exploitation, and etc.), place all of your evidence (e.g. screenshots, text, pdf, HTML
outputs, and etc.) in separate documents or as appendices. They will be needed and used by the
technical guys to crosscheck any findings you have stated in your report. The management will
not really care about them since they will definitely ask the technical staff to provide them with
the evidence (if needed).
Writing Your 1st Report

How do I start my own report? My company does not have any report template. What template
should I use?
To answer the above questions, let’s start by creating a draft report which should include all
important sections such as introduction, project details, methodology, findings, and
recommendations.
1st Report Structure:
1. Introduction
2. Project Details
3. Methodology
4. Findings
5. Recommendations
Once you have completed with the first report structure that captures all important sections, then
make some changes by adding extra sections.
33
Modified 1st Report Structure:
1. Cover Page
2. Table of Contents
3. Introduction
4. Project Details
4.1 Project Scope
4.2 Timeline
5. Methodology
5.2 Vulnerability Identification
5.3 Exploitation
5.5 Housekeeping
6. Findings
6.1 Network Devices
6.2 Data Center
6.3 Clients
7. Recommendations
7.1 People
7.2 Process
7.3 Technology
8. Conclusion
9. Appendices
Save your 1st draft report and name it “VAPT Draft Report v0.1”. Modify and revise your report till
you feel satisfied with the structure and contents of the report. You can save your report with the
name of “VAPT Report v1.0” which mark your first Final Report to be reviewed by your immediate
supervisor or manager. This report might need to be reviewed for a few times and finally approved
by an appointed quality assurance personnel (depending on your organization structure or project
org. structure).
34
Based on your first final report, you could extend the report structures and contents as needed by
the organization, of course, you can make them as your company’s report templates as their re-
usable tools. Think about the most effective way to communicate with your intended audience
through your reporting techniques. A simple report doesn’t mean good, complete report doesn’t
mean bad. The result is the key.
Polishing Your Report

Make your penetration testing report as impressive as you can and capture the attention of your
intended audience. That doesn’t mean a fancy report. A picture worth a thousand words.
Executive or management audience likes a simple but meaningful report rather than a complex
wordy report. Add extra value in your report by placing tables, charts or graphs and other types of
figure that will show complex terms in a simple format.
Choose font types that are easy to read (e.g. Droid Serif 11 or 12 points). Use different font types,
font sizes, and colours to emphasize topics or sections.
Use strong colours to show different level of risk or severities:
High = 3, Medium = 2, Low = 1
Host Type High (3) Medium (2) Low (1)

Network Devices 10 0 5
Servers 20 10 2
Client Workstations 50 20 10
35
Use an effective chart to show the findings:
10
9
8
7
6
10
5
4
6
3 5
4
2
2
1
0
Default or weak Mis-configuration Missing Weak encryption Miscellaneous
password patches/updates
Use an interactive gauge to show the overall risk as shown below:
Overall Risk = High
Impress them with your way of delivering the results, but stick to the objective of effectively
communicating your findings to the audience.
Maintaining Your Report

To effectively maintain your penetration reports, it is not a bad idea to create a central repository
to save and archive your reports based on your document history or version control. Since the
nature of penetration testing reports is classified as “secret” or “confidential”, report files must
be placed in a secure storage. You can use an encrypted hard disk or USB flash disk to store your
36
reports. Worth to try: TrueCrypt and Windows BitLocker, allow you to encrypt contents of a folder
or even the entire volume (normal or hidden). I like to use TrueCrypt despites the issues raised
due to the weak encryption.
Alternatively, we could take the advantage of using some free online cloud storage to store our
reports in encrypted formats (e.g. zip, RAR, 7zip, and etc.). Cloud storage such as
http://www.mega.co.nz and http://www.dropbox.com are quite good. Mega provides up to 50GB
free cloud storage while DropBox provides up to 10GB, which is more than enough to store our
files. Always remember to encrypt any data, reports or information in a cloud storage due to their
nature.
Folder structure of your reports might look like the following:
<RootFolder>
<ProjectName>
<DraftReports>
<Date>
<Date>
<Date>
<FinalReports>
<Date>
<Date>
<Date>
<RevisedReports>
<Date>
<Date>
<Date>
Cloud storage offers flexibility to access your data or reports anytime anywhere. You could also
configure to allow certain parts of your storage to be shared and access by your team, especially
when you need to share raw data from the field.
37
Converting Your Report Format
You may create separate documents in order to create a complete report. I would normally create
a separate file as a Cover Page which includes the Report Cover and Document Information &
History, then a separate file to store the contents of my report as well as having separate
Appendix files. So my report files consist of:
1. VAPT Report - Cover

Contains cover page with document information and history
2. VAPT Report - Contents

Contains complete report contents with additional information (structured) as well as the
table of contents and references.
3. VAPT Report - Appendices

Contains all necessary appendices (e.g. Nessus scan results, Nmap scan results, etc.)
With some appropriate tools, we can easily convert one report format to another. I would suggest
to use a free pdf writer and converter like Nitro PDF Reader and Creator
(https://www.gonitro.com), which allows us to directly convert our Microsoft Word document
(.doc and .docx) to pdf, and if you have several files used to create a complete set of report, you
could easily combine them all (pdf file formats) with a tool called PDF Merge Tool or use similar
tool available online at http://www.pdfmerge.com. A completely merged penetration testing
report could be named as you wish. I normally use the name like “ACME Vulnerability Assessment
& Penetration Testing Report v1.0 – DDMMYYYY”.
38
CHAPTER 4
Putting Them Together

Now you have learned on how to create a good penetration testing report, not only good… but
effective. Effective to communicate with your audience. Let’s put them together.
The following summarize the steps to start creating a good and effective penetration testing
report - 9 Steps to Success:
Step 1: Select a report format as needed

Step 2: Use the report structure template
Step 3: Create a draft report (your 1st report)
Step 4: Extend the report structure as required
Step 5: Elaborate what you want to tell to the audience
Step 6: Polish your report by adding extra objects (e.g. charts, graphs, tables)
Step 7: Do error checking (e.g. grammar, spelling, and vocabularies)
Step 8: Maintain document history and version control (e.g. central repository, archival)
Step 9: Improve the quality of your report by continuously updating it
Note: Create separate reports for network infrastructure and application/web application
vulnerability assessment and penetration testing. Do not combine them all in a single report, to
avoid confusion.
Enhancing Your Report

I would advise enhancing your report from time to time to reflect the technology changes and
trends. Do more research on several related websites on how to add extra values to your report
so that we could focus on providing value-added services on top of what we are currently doing,
such as adding knowledge transfer to the existing penetration testing or any security assessment.
39
Add more references to your report templates to reflect the latest industry
standards/benchmarks.
Housekeeping
Housekeeping on a report? Hmmm… yes, we still need to do a little clean-up. Find any minor and
major errors in your report, verify and let other people review your report. We might not be able to
spot a little problem or I called them “black spots”. Report reviewer would be able to give us more
advice in order to improve the quality of our report and share their expertise. I have been writing
technical reports for years, but still I need someone to review and measure the effectiveness of
my report. The reviewer would act as if they are the intended audience. He or she could tell us if
the report satisfies them or not. The key is, do not over confidence. We are not perfect. Let
someone judge our work.
Summary and Conclusion

Writing an effective penetration testing report is an art that needs to be learned and to make sure
that the report will deliver the right information to the targeted or intended audience. A skill that
every penetration tester needs to gain. A penetration test is useless without something tangible
to give to a client or senior management.
A well-structured penetration testing report which covers the objective of a penetration testing or
security assessment is an important aspect in communicating with the management on how to
tackle the risks. A penetration testing report should not only good in terms of appearance - fancy,
but it should be effective to provide the organization with the overall security posture as well as
a clear strategy in facing the risks.
Survey shows that the lack of penetration testing report writing skills affecting the effectiveness
of deliverable as something tangible to be given to the client. By having a good guideline on how
to create a good yet effective penetration testing report, the writing skills are expected to be
improved. A simple start is to create a draft and slowly enhance and improve the structure and
contents of the report. Do not just focus on the technical parts, but also, improve in the
management part. Always include risk management in every vulnerability assessment and
40
penetration testing report to provide a clear view of the organization’s security posture as well as
risk mitigation strategy (security controls).
Hope that this short course will help us to start improving the quality of our penetration testing
report to the max.
In order to improve the contents of this course, the Author welcomes any comments and
suggestions.
Appendices
Appendix A – Network Infrastructure Vulnerability Assessment and Penetration Testing Executive
Report
Appendix B – Web and Mobile Application Vulnerability Assessment and Penetration Testing
Executive Report
References
[1] Smith-Worthington/Jefferson, Technical Writing for Success, 3e, 2011
[2] Charles Cotter, Technical Report Writing – Best Practices Writing Principles and Process, 2014
[3] Atinder Sodhi, Best Practices for Technical Writing, 2012
41
SAMPLE REPORTS
< Company Logo >
ACME Consulting
Information Systems
Vulnerability Assessment
And Penetration Testing
EXECUTIVE REPORT
v1.0
For
ABC Networks
INFORMATION TECHNOLOGY DIVISION
Document Details
Company: ABC Networks (“ABC”)
Document Title: Network Infrastructure - Vulnerability Assessment and Penetration Testing
Executive Report
Version: 1.0
Due Date: 31 March 2015
Author: Semi Yulianto
Pen-testers/Analyst: 1. Pentester #1
2. Pentester #2
3. Pentester #2
Reviewed by: ABC
Approved by: ABC
Classification: Confidential
Document Type: Deliverable
Recipients
Quality Assurance
Issue 02/03/2015 Semi Yulianto, CISSP, CISA Senior Security Analyst 02/03/2015
Review 03/03/2015 Arvin Yulianto, CISSP, CISA Senior Security Analyst 04/03/2015
QA/Final 05/03/2015 Andry Eka Wijaya, CISSP, CISA QA Manager 06/03/2015
Approval
Document History
1.0 06/03/2015 Network Infrastructure - Vulnerability Assessment and Final Report
Penetration Testing Executive Report
Table of Contents
1 Introduction ............................................................................................................................ 1
2 Document Scope ..................................................................................................................... 2
2.1 Scope of Test ...................................................................................................................... 2
2.2 Limitation ........................................................................................................................... 2
2.3 Purpose of Test .................................................................................................................. 2
3 Project Details......................................................................................................................... 3
3.1 Project Description ............................................................................................................ 3
4 Executive Summary ............................................................................................................... 4
4.1 Summary ............................................................................................................................ 4
4.2 Approach ............................................................................................................................ 4
4.3 Scope of Work .................................................................................................................... 5
4.4 Project Objectives .............................................................................................................. 5
4.5 Timeline (Project Schedule)............................................................................................... 5
4.6 Summary of Findings ......................................................................................................... 6
4.6.1 Vulnerability Summary ............................................................................................... 7
4.6.1 Vulnerability by Host Type.......................................................................................... 7
4.6.2 Vulnerability by Device Type ...................................................................................... 8
4.7 Summary of Recommendations ....................................................................................... 9
5 Methodology ......................................................................................................................... 10
5.1 Planning............................................................................................................................ 10
5.2 Exploitation ...................................................................................................................... 10
5.3 Reporting .......................................................................................................................... 11
5.3.1 Risk Analysis .............................................................................................................. 12
6 Detailed Findings .................................................................................................................. 12
6.1 Detailed Systems Information ........................................................................................ 12
6.1 Vulnerability Assessment (VA) ..................................................................................... 12
6.2 Vulnerability Assessment (VA) ..................................................................................... 13
6.3 Configuration Security Audit (CSA) ............................................................................. 13
7 Conclusion ............................................................................................................................. 13
8 References ............................................................................................................................. 14
Information Systems - Vulnerability Assessment and Penetration Testing Executive Report | 1
1 Introduction
A critical problem for public and private institutions is the increasing threat of attack.
This is due to a combination of increasingly sophisticated and automated attack tools,
the rapid increase in the number of vulnerabilities being discovered, and the
increasing connectivity of users. As systems are opened to employees, customers and
trading partners, networks become more complex and are more susceptible to a
security breach. That is why information security is one of the most challenging issues
facing companies today.
These recent trends in cybercrime make it more critical than ever that organizations
acquire a true assessment of their security vulnerabilities so they can identify and
address those vulnerabilities associated with their most valuable information assets.
Your organization's true vulnerability to threats can be determined only by answering
the following questions in regards to each of your identified vulnerabilities:
 Is the vulnerability real, or is it a false positive?

 Can the vulnerability be exploited?
 Are there any sensitive systems or data exposed by the vulnerability?
Clearly, the answers to these questions will allow you to prioritize your vulnerabilities
and structure your security strategy as effectively and efficiently as possible, instead of
simply identifying your vulnerabilities and then attempting to address them based only
on assumptions about risk. One of the easiest and fastest ways to obtain these answers,
both initially, and on an ongoing basis, is to perform a penetration test on your
network.
A penetration test is an authorized, local attempt to "hack" into a system, to identify

exploitable weaknesses, and to reveal what systems and data are at risk. The tester may
use several methods to gain entry to the target network, often initially breaking into
one relatively low priority section and then leveraging it to attack more sensitive areas.
Your organization is probably already running (or wonders what penetration testing
offers you that vulnerability scanning do not. It's simple: An Information Security
Assessment tells you only what an attacker can potentially do to your environment. A
penetration test tells you what an attacker can definitely do to your environment.
That's because penetration tests exploit identified vulnerabilities, just as an attacker

would. Unlike vulnerability scans, penetration tests leave little doubt as to what an
attacker can or cannot do. Penetration tests eliminate the guesswork involved in
protecting your network by providing you with the information you need to effectively
prioritize your vulnerabilities.
2 Document Scope
The document hereby describes the proceedings and results of the information systems
(IS) Vulnerability Assessment and Penetration Testing (VA-PT) conducted at ABC
Networks (“ABC”). The test performed by our team and took place on 17 Nov 2014 to 20
Feb 2015 as part of a special assignment.
2.1 Scope of Test

The scope of the assessment included conducting black-box and white-box testing on
the organization’s information systems covering network, infrastructure based on the
industry standards and guidelines.
2.2 Limitation
The test was limited to certain hosts (IP addresses) provided by the ABC based on the
criticality and business risks of assets being assessed. Due to some technical and non-
technical constraints, several targets were not being exploited during the assignment,
and thus, non-intrusive Security Assessment was conducted to avoid risks.
2.3 Purpose of Test

The purpose of test is to provide security assurance, compliance and best practices
based on industry standards and associations such:
 SANS Institute
 Institute for Security and Open Methodologies – OSSTMM
 Open Information Systems Security Group – ISSAF
 National Institute of Standards and Technology (NIST)
ACME Consulting
 Payment Card Industry Data Security Standard (PCI DSS)
3 Project Details

The following describes project details based on the assignment:
Name of Organization: ABC Networks (“ABC”)
Target of Evaluation: Information Systems (Network Infrastructure)
Project Duration: 60 (sixty) working days
Sources: Given IP addresses
Tests Performed: Phase 1: Information gathering

Phase 2: Vulnerability Assessment
Phase 3: Vulnerability Identification and Analysis
Phase 4: Exploitation
Phase 5: Remediation (fixing)
Phase 6: Reporting
Tools Used:  Nmap

 Nessus
 MetasploitPro
 Metasploit Framework
 Hydra
 Telnet
 Armitage
Type of Tests: Hybrid (Black-box & White-box) Security Tests
Deliverables: Executive Summary & Technical Report
ACME Consulting
4 Executive Summary
4.1 Summary
ABC has assigned the task of carrying out vulnerability assessment and penetration
testing (VAPT) of the organization’s information systems covering network
infrastructure (servers, firewalls, intrusion detection systems, and network devices)
and web applications (publicly exposed IP addresses) located on ABC internal and
external network. This is the final VAPT Executive Report. The assessment was
performed from 17 Nov 2014 to 20 Feb 2015. The detailed report about each task and
our findings are described below.
The purpose of the test is to determine security posture of the ABC’ information systems
as well as determining and measuring the effectiveness of information security
controls being implemented. The tests were carried out assuming the identity of an
attacker of a user with malicious intent. At the same time, due care is taken not to harm
the server or database.
4.2 Approach
The following explains the steps taken during the tests:
 Perform live systems detection on targets

 Gather information about the targets
 Perform unauthorized discovery and mapping of systems, services, or
vulnerabilities
 Identify and assess vulnerabilities detected
 Perform enumeration on targets
 Exploit any known vulnerabilities found for proof-of-concept (PoC)
 Perform detailed analysis on findings
 Calculate and rank risks based on severity and risk factor
 Prepare technical and non-technical reports
ACME Consulting
4.3 Scope of Work

The scope of this security assessment and penetration test was limited to:
 Network Devices (routers and switches)

 Security appliances (firewalls, IDSes, and IPSes)
 Server hosts (operating systems)

This security assessment is carried out to gauge the security posture of ABC’
information systems as well as determining and measuring the effectiveness of
information security controls being implemented. The result of the assessment is then
analysed for vulnerabilities. Given the limited time that is given to perform the
assessment, only immediately exploitable services have been tested. The
vulnerabilities are assigned a risk rating based on threat, vulnerability and impact.
4.5 Timeline (Project Schedule)

The timeline (project schedule) of the test as follows:
Penetration Test Start Date/Time End Date/Time

Initial Testing (Phase 1) 17/11/2014 30/01/2015
Final Testing (Phase 2) 05/01/2015 20/02/2015
Risk Analysis & Mitigation 17/02/2015 27/02/2015
Reporting 04/03/2015 06/03/2015
Table 1: Timeline (Project Schedule)
Penetration Test Project Timeline (ETC = 60 Days)

Initial Testing (Phase 1)
Final Testing (Phase 2)
Risk Analysis & Mitigation
Reporting
Table 2: Illustrative Timeline
ACME Consulting

The following summarize our assessment findings:
Dashboard
Overall Security Posture Vulnerability by Severity
6%
20%
61%
13%
MEDIUM Critical High Medium Low
Source: Risk Analysis Source: Vulnerability Assessment
Vulnerability by Host Type Vulnerability by Device Type

100 25
80 92 20 22
78
60 15
14
40 10
37 10 10
20 5 8
17 9 12 5 0 00 0 01 2 200 0000 3 2
0 0
High Medium Low Total Critical High Medium Low Total
Network Devices Servers (OS) Firewall IPS Router Switch
Source: Vulnerability Assessment (VA) Source: Configuration Security Audit (CSA)
Figure 1: Dashboard
ACME Consulting
4.6.1 Vulnerability Summary
Severity Count Percentage

Critical 8 06.20%
High 26 20.16%
Medium 17 13.18%
Low 78 60.47%
Total 129 100.00%
Table 3: Vulnerability Summary (Source: Vulnerability Assessment)
Vulnerability Summary
6%
20%
61%
13%
Critical High Medium Low
Figure 2: Vulnerability Summary
4.6.1 Vulnerability by Host Type
Host Type Critical High Medium Low Total

Network Devices 8 17 12 0 37
Servers (OS) 0 9 5 78 92
Total 8 26 17 78 129
Table 4: Vulnerability by Host Type (Source: Vulnerability Assessment)
ACME Consulting
Vulnerability by Host Type

100
90
92
80
70 78
60
50
40
30 37
20
10 17
9 12 5 0
0
High Medium Low Total
Network Devices Servers (OS)
Figure 3: Vulnerability by Host Type (Source: Vulnerability Assessment)
4.6.2 Vulnerability by Device Type
Host Type Critical High Medium Low Total

Firewall 0 0 10 0 10
IPS 0 1 2 0 3
Router 8 14 0 0 22
Switch 0 2 0 0 2
Total 8 17 12 0 37
Table 5: Vulnerability by Device Type (Source: Configuration Security Audit)
Vulnerability by Device Type

25
20 22
15
14
10
10 10
8
5
0 0 0 0 1 2 2 0 0 0 0 0 0 3 2
0
Critical High Medium Low Total
Firewall IPS Router Switch
Figure 4: Vulnerability by Device Type (Source: Configuration Security Audit)
ACME Consulting
* Vulnerability analysis based on Raw Data collected during a comprehensive assessment. Refer to the
attached documents/references for detailed analysis.
4.7 Summary of Recommendations
Several critical vulnerabilities have been found and it is advisable to perform

corrective actions as stated below:
 Enforce message signing in the host's configuration. On Windows, this is found in

the Local Security Policy. On Samba, the setting is called 'server signing'.
 Install missing patches and adopt a patch management process to keep single or
multiple servers up to date (applicable to Microsoft Windows, Unix/Linux and other
operating systems).
 Filter Remote Desktop (RDP) access through VPN access or any form of Network
Access Control (NAC) to avoid credential brute force attacks and prevent
unauthorized access.
 Upgrade any unsupported operating systems currently in use in a production

environment (e.g. data center).
 Disable Telnet. Secure Shell (SSH) should be used as a cryptographically secure

alternative to Telnet. Upgrade Secure Shell (SSH) the latest version.
 Disable the use of SNMP, else SNMP version 3 should be configured. If access using
community strings is required, strong community strings should be configured.
 Configure an ACL to restrict access. Apply the ACL to the relevant lines.
 Configure network devices using strong passwords (e.g. enforce passwords policies,
procedures, and standards).
 Implement SSL in securing critical web-based applications.
ACME Consulting
 Implement IPSec in securing critical host-to-host communications (e.g. IPSec

Transport mode or Tunnel mode with Authentication Header).
 Restrict the use of Peer-to-Peer (P2P) applications on the internal/private networks

to reduce risks to common threats and attacks.
5 Methodology
Vulnerability Assessment and Penetration Testing Methodology Simplified:
•Information Gathering
Planning •Detecting Live Systems

•Reconnaissance
•Scanning & Fingerprinting
•Vulnerability Assessment
Exploitation •Enumeration
•Privilege Escalation
•Exploitation
•Finding Analysis
Reporting •Risk Calculation & Rating
•Reporting
5.1 Planning
During planning, we gather information from the given technical infrastructure design
to learn about targets. Then, we detect the live system its OS and determined the
running services and its versions.
5.2 Exploitation
Utilizing the information gathered in Planning we start to find the vulnerability for
each OS and service that we discovered after that trying to exploit it.
ACME Consulting
5.3 Reporting
Based on the results from the first two steps, we start analysing the results. Our risk
rating is based on this calculation:

Impact Low 1 2 3 4 1 4 6 8 3 6 9 12 4 8 12 16
Medium 2 4 6 8 4 8 12 16 6 12 18 24 8 18 24 32
High 3 6 9 12 6 12 18 24 9 18 27* 36 12 24 36 48
Critical 4 8 12 16 8 16 24 32 12 24 36 48 16 32 48 64
Table 6: Risk Analysis [1]
* Based on our analysis, risks that fall under this category will be considered as High.
L Low 1 – 16
M Medium 17 – 32
H High 33 – 48
Table 7: Risk Rating Calculation [1]
[1] SANS Best Practices Whitepaper http://www.sans.org/reading-room/whitepapers/bestprac/writing-

penetration-testing-report-33343, NIST SP800-30 Rev 1 Risk Management Guide for Information Technology
Systems http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf)
After calculating the risk rating, we start writing the report on each risk and how to
mitigate it.
ACME Consulting
5.3.1 Risk Analysis
Host Type Threat Vulnerability Impact* Risk

Server Host (OS) 3.1 1.6 2.2 12.6
Network Devices 4.0 2.9 2.0 23.1
Average 3.6 2.3 2.1 17.8
MEDIUM
* Impact is calculated based on Technical Impact.
6 Detailed Findings
6.1 Detailed Systems Information
6.1 Vulnerability Assessment (VA)
No. Host IP Host Name Operating System (OS) Core Criticality

(Yes/No) (1 – 9)
1. 192.168.1.100 LON-DC1 Windows Server 2012 R2 SP0 Yes 8
2. 192.168.1.101 LON-DC2 Windows Server 2012 R2 SP0 Yes 7
3. 192.168.1.102 LON-SVR1 Windows Server 2003 SP0 Yes 6
6. 192.168.1.105 LON-SVR4 Windows Server 2003 SP0 No 4
7. 192.168.1.106 LON-WEB1 Windows Server 2008 R2 SP0 Yes 8
10. 192.168.1.109 LON-DB1 Windows Server 2008 R2 SP0 Yes 9
11. 192.168.1.110 LON-DB2 Windows Server 2003 SP0 Yes 9
12. 192.168.1.120 LON-DB3 Windows Server 2003 SP0 Yes 9
13. 192.168.1.121 LON-IDS1 Windows Server 2003 SP0 Yes 7
14. 192.168.1.122 LON-FW1 Windows Server 2003 SP0 Yes 7
15. 192.168.1.123 LON-FW2 Windows Server 2003 SP0 Yes 7
16. 192.168.1.124 LON-RTR1 Cisco IOS 12.x Yes 5
17. 192.168.1.125 LON-RTR2 Cisco IOS 12.x Yes 5
18. 192.168.1.200 LON-RTR3 Cisco IOS 12.x No 5
ACME Consulting
6.2 Vulnerability Assessment (VA)
No. Host Type Sheet Core Non-Core Overall

1. Internal Servers T1 Medium Low Medium
2. DMZ Servers T2 Medium Low Low
3. External Servers T3 Medium Low Low
4. Data Center Servers T4 N/A Low Low
6.3 Configuration Security Audit (CSA)
No. Host Type Sheet Core Non-Core Overall

1. Network Devices T5 Medium Low Low
2. Security Appliances T6 Medium Low Low
* High vulnerabilities found in the Initial Phase of the assessment have successfully remediated. Follow-up and
continuous monitoring should be done for Medium and Low level vulnerabilities (Risk Treatment Plan/RTP).
7 Conclusion
Most of the vulnerabilities found in the Initial Phase of the assessment have
successfully remediated. Vulnerabilities that could not be remediated immediately due
to some technical and operational reasons (eq. needed for remote administration and
troubleshooting) still introduce risks, therefore, compensating controls must be applied
and implemented to reduce or mitigate risks associated with vulnerabilities being
exposed.
Compensating security controls are controls that provide an alternative to normal

controls that cannot be used for some reason. For instance, a certain server cannot
have antivirus software installed because it interferes with a critical application. A
compensating control would be to increase monitoring of that server or isolate that
server on its own network segment.
For systems to remain secure, security posture must be evaluated and improved
continuously. Establishing the organizational structure that will support these ongoing
improvements is essential in order to maintain control of corporate information
systems.
ACME Consulting
We conclude that the overall security has been improved. We recommend that ABC’
information systems’ security posture should be reviewed or assessed at least every 6
(six) months or annually depending on the amount of changes to the infrastructure.
8 References
Appendix A – Vulnerability Assessment Summary
Attached Vulnerability Assessment summary.
Appendix B – Configuration Security Audit Summary

Attached Vulnerability Assessment summary.
Appendix C – Nmap Scanning Report

Attached Nmap scan reports.
Appendix D – Nessus Vulnerability Scanning Report

Attached Nessus scan reports.
Appendix E – Nipper Security Audit Report

Attached Nessus scan reports.
ACME Consulting
< Company Logo >
ACME Consulting
DemoApp
Application Vulnerability
Assessment and Penetration
Testing
EXECUTIVE REPORT
v1.0
For
ABC Networks
INFORMATION TECHNOLOGY DIVISION
Document Details
Company: ABC Networks (“ABC”)
Document Title: DemoApp – Application Vulnerability Assessment and Penetration Testing
Executive Report
Version: 1.0
Due Date: 31 March 2015
Author: Semi Yulianto
Pen-testers/Analyst: 1. Pentester #1
2. Pentester #2
3. Pentester #2
Reviewed by: ABC
Approved by: ABC
Classification: Confidential
Document Type: Deliverable
Recipients
Quality Assurance
Issue 02/03/2015 Semi Yulianto, CISSP, CISA Senior Security Analyst 02/03/2015
Review 03/03/2015 Arvin Yulianto, CISSP, CISA Senior Security Analyst 04/03/2015
QA/Final 05/03/2015 Andry Eka Wijaya, CISSP, CISA QA Manager 06/03/2015
Approval
Document History
1.0 06/03/2015 DemoApp – Application Vulnerability Assessment and Final Report
Penetration Testing Executive Report
Table of Contents
1 Introduction ............................................................................................................................ 1
1.1 The Importance of Application Security Assessment ...................................................... 1
1.2 Why Perform an Application Security Assessment .......................................................... 1
2 Document Scope ..................................................................................................................... 2
2.1 Scope of Test ...................................................................................................................... 2
2.2 Limitation ........................................................................................................................... 2
2.3 Purpose of Test .................................................................................................................. 2
3 Project Details......................................................................................................................... 3
3.1 Project Description ............................................................................................................ 3
4 Executive Summary ............................................................................................................... 3
4.1 Summary ............................................................................................................................ 3
4.2 Approach ............................................................................................................................ 4
4.3 Scope of Work .................................................................................................................... 5
4.4 Project Objectives .............................................................................................................. 5
4.5 Timeline .............................................................................................................................. 5
4.6 Summary of Findings ......................................................................................................... 6
4.6.1 OWASP Top 10 Vulnerabilities - 2013 ........................................................................ 6
4.6.2 OWASP Mobile Top 10 Risks - 2013 ........................................................................... 7
4.6.3 DemoApp Web ............................................................................................................ 8
4.6.4 DemoApp Mobile ...................................................................................................... 10
5 Methodology ......................................................................................................................... 11
5.1 Planning............................................................................................................................ 11
5.2 Exploitation ...................................................................................................................... 12
5.3 Reporting .......................................................................................................................... 12
6 Detailed Findings .................................................................................................................. 12
6.1 OWASP Top 10 Vulnerabilities - 2013 ............................................................................. 12
ACME Consulting
6.2 Other Web Vulnerabilities ............................................................................................... 13
6.3 OWASP Mobile Top 10 Risks - 2013 ................................................................................ 13
6.4 Other Mobile Vulnerabilities ........................................................................................... 13
7 Other Recommendation...................................................................................................... 13
7.1 People ............................................................................................................................... 13
7.1.1 Core Security Training .............................................................................................. 13
7.2 Process ............................................................................................................................. 14
7.2.1 Develop and Implement Testing Framework .......................................................... 14
7.2.2 Implement Security Development Lifecycle (SDL) .................................................. 15
7.3 Technology ....................................................................................................................... 15
7.3.1 Implement Web Application Firewalls (WAFs) ........................................................ 15
8 Conclusion ............................................................................................................................. 15
9 References ............................................................................................................................. 16
ACME Consulting
DemoApp – Application Vulnerability Assessment and Penetration Testing Executive Report | 1
1 Introduction
1.1 The Importance of Application Security Assessment
Insecure software is undermining our financial, healthcare, defence, energy, and other
critical infrastructure. As our digital infrastructure gets increasingly complex and
interconnected, the difficulty of achieving application security increases exponentially.
We can no longer afford to tolerate relatively simple security problems.
Application Security Assessment conducted by ABC Consulting (“ABC”) reviews and

evaluates the level of risk associated with an application in terms of its web
vulnerabilities and the potential disclosure of sensitive information. The primary goals
of this assessment are to:
 Provide management with an understanding of the level of risk introduced by the

application.
 Provide recommendations and details to facilitate a cost-effective and targeted

mitigation approach.
 Create a basis for future decisions regarding information security strategy and
resource allocation.
1.2 Why Perform an Application Security Assessment

 To execute a real-world attack on a critical application and understand the level of
risk that exist at a single moment in time.
 To complement your automated scanning appliance to better identify and validate

all security vulnerabilities associated with your Internet-facing environment.
 To understand how well your development team followed the secure software
development life cycle.
2 Document Scope
The document hereby describes the proceedings and results of the Application Security
Assessment and Penetration Testing conducted at ABC Networks (“ABC”) The test
performed by our team and took place on 11 March 2014 to 27 Feb 2015 as part of a
special assignment.
2.1 Scope of Test

The scope of the Application Security Assessment and Penetration Testing included
conducting a black box and white box testing on applications based on the industry
standards and guidelines. The test was conducted against applications and includes
attempts to exploit application level vulnerabilities.
2.2 Limitation
The test was limited to certain applications provided by the ABC based on the criticality
and business risks of assets being assessed. Due to some technical and non-technical
constraints, several targets were not being exploited during the assignment, and thus,
non-intrusive Security Assessment was conducted to avoid risks.
2.3 Purpose of Test

The purpose of test is to provide security assurance, compliance and best practices
based on industry standards and associations such:
 OWASP Top 10 Vulnerabilities – 2013

 OWASP Mobile Top 10 Risks – 2013
 OWASP Testing Guide v4.0 (2014).
ACME Consulting
3 Project Details

The following describes project details based on the assignment:
Name of Organization: ABC Networks (“ABC”)
Target of Evaluation: DemoApp Application

https://demoapp.abc.com/ (DemoApp Web)
https://demoapp.abc.com/mobile/demoapp.apk (DemoApp Mobile)
Project Duration: 30 (thirty) working days
Sources: Customize web-based and mobile application developed by ABC
Tests Performed: Phase 1: Application Profiling

Phase 2: Application Security Assessment and Penetration Testing
Phase 3: Application Source Code Review
Phase 4: Vulnerability Identification and Analysis
Phase 5: Exploitation
Phase 6: Remediation (fixing)
Phase 7: Reporting
Tools Used:  Acunetix Web Vulnerability Scanner (Dynamic Analysis)

 SnapUI Pro (Dynamic Analysis)
 Manual Tests (Dynamic Analysis)
 AndroChef Java Decompiler (Static Analysis)
 Yasca with FindBugs & JLint for Java (Static Analysis)
Type of Tests: Hybrid (White-box & Black-box) Security Tests
Deliverables: Compliance Reports (Executive & Technical Report)
4 Executive Summary
4.1 Summary
ABC has assigned the task of carrying out Security Assessment and Penetration Testing
of the applications located on ABC’s internal (private) and external network (public).
This is final Penetration Testing report. Application security assessment and
penetration test was performed from 11 March 2014 to 27 Feb 2015. The detailed report
about each task and our findings are described below.
The purpose of the test is to determine security vulnerabilities on the client-server

applications running on the server specified as part of the scope. The tests are carried
ACME Consulting
out assuming the identity of an attacker of a user with malicious intent. At the same
time, due care is taken not to harm the server or database.
Risk analysis based on risk calculation (5.3 Reporting) explained as follows:
Host Type Threat Vulnerability Impact Risk

DemoApp Web 04.00 02.06 02.35 19.42
DemoApp Mobile 04.00 01.00 03.00 12.00
Average 04.00 01.53 02.68 15.71
LOW
* Impact is calculated based on Technical Impact.
4.2 Approach
The following explains the steps taken during the tests:
 Perform information gathering on application (profiling)

 Perform broad scans to identify potential areas of exposure that may act as entry
points
 Perform targeted scans, code review, and manual investigation to validate
vulnerabilities
 Test identified components to gain access to the target applications
 Identify and validate vulnerabilities
 Rank vulnerabilities based on risk level of exploitation
 Perform supplemental research and development activities to support analysis
 Identify issues of immediate consequence and recommend solutions
 Develop long-term recommendations to enhance security
 Transfer knowledge (eq. secure coding training)
During the client-server application level, we checked the server’s configuration

issues, and, more importantly, the logical errors in the web application itself.
ACME Consulting
4.3 Scope of Work
The scope of this security assessment and penetration test was limited to the below-
mentioned applications:
Name of Application Version Description

Control
DemoApp Web v1.0 Rev 0.0 Customize web-based
https://demoapp.abc.com/ application developed by ABC.
DemoApp Mobile V1.0 Rev 0.0 Customize mobile application

https://demoapp.abc.com/mobile/demoapp.apk for Android, iOS & BlackBerry
OS developed by ABC.

This security assessment is carried out to gauge the security posture of ABC’s client-
server application. The result of the assessment is then analyzed for vulnerabilities.
Given the limited time that is given to perform the assessment, only immediate
exploitable services have been tested.
The vulnerabilities are assigned a risk rating based on threat, vulnerability and impact.
4.5 Timeline
The timeline of the test as follows:
Penetration Test Start Date/Time End Date/Time

Initial Testing (Phase 1) 11/03/2014 29/08/2014
Final Testing (Phase 2) 01/09/2014 27/02/2014
Risk Analysis & Mitigation 02/03/2015 04/03/2015
Reporting 05/03/2015 06/03/2015
Table 1: Timeline (Project Schedule)
Penetration Test Project Timeline (ETC = 30 Days)

Initial Testing (Phase 1)
Final Testing (Phase 2)
Risk Analysis & Mitigation
Reporting
Table 2: Illustrative Timeline
ACME Consulting
4.6.1 OWASP Top 10 Vulnerabilities - 2013
Code Vulnerability Detailed Description

A01 Injection Injection flaws, such as SQL, OS, LDAP, and XPath injection occur
when untrusted data is sent to an interpreter as part of a command
or query. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper
authorization.
A02 Broken Application functions related to authentication and session

Authentication management are often not implemented correctly, allowing
and Session attackers to compromise passwords, keys, or session tokens, or to
Management exploit other implementation flaws to assume other users’ identities.
A03 Cross Site XSS flaws occur whenever an application takes untrusted data and
Scripting (XSS) sends it to a web browser without proper validation or escaping. XSS
allows attackers to execute scripts in the victim’s browser which can
hijack user sessions, deface web sites, or redirect the user to
malicious sites.
A04 Insecure Direct A direct object reference occurs when a developer exposes a
Object References reference to an internal implementation object, such as a file,
directory, or database key. Without an access control check or other
protection, attackers can manipulate these references to access
unauthorized data.
A05 Security Security misconfiguration can happen at any level of an application

Misconfiguration stack, including the platform, web server, application server,
database, framework, and custom code. Developers and system
administrators need to work together to ensure that the entire stack
is configured properly. Automated scanners are useful for detecting
missing patches, misconfigurations, use of default accounts,
unnecessary services, etc.
A06 The most common flaw is simply not encrypting sensitive data.
When crypto is employed, weak key generation, and management,
and weak algorithm usage are common, particularly weak password
hashing techniques. Browser weaknesses are very common and easy
to detect, but hard to exploit on a large scale. External attackers
have difficulty detecting server side flaws due to limited access and
they are also usually hard to exploit.
A07 Missing Applications do not always protect application functions properly.

Functional Level Sometimes, function level protection is managed via configuration,
Access Control and the system is misconfigured. Sometimes, developers must
include the proper code checks, and they forget. Detecting such
flaws is easy. The hardest part is identifying which pages (URLs) or
functions exist to attack.
A08 Cross Site CSRF takes advantage the fact that most web apps allow attackers to
Request Forgery predict all the details of a particular action. Because browsers send
(CSRF) credentials like session cookies automatically, attackers can create
malicious web pages which generate forged requests that are
indistinguishable from legitimate ones. Detection of CSRF flaws is
fairly easy via penetration testing or code analysis.
ACME Consulting
A09 Using Virtually every application has these issues because most
Components with development teams don’t focus on ensuring their
Known components/libraries are up to date. In many cases, the developers
Vulnerabilities don’t even know all the components they are using, never mind their
versions. Component dependencies make things even worse.
A10 Unvalidated Web applications frequently redirect and forward users to other
Redirects and pages and websites, and use untrusted data to determine the
Forwards destination pages. Without proper validation, attackers can redirect
victims to phishing or malware sites, or use forwards to access
unauthorized pages.
4.6.2 OWASP Mobile Top 10 Risks - 2013
ACME Consulting
4.6.3 DemoApp Web
4.6.3.1 OWASP Top 10 Vulnerabilities – 2013
Vulnerability Description Severity Status Risk Risk

Score Rating
A01 Injection High I/D 24.00 Medium
A02 Broken Authentication and Session High I/D 24.00 Medium
Management
A03 Cross-Site Scripting (XSS) Medium I/D 16.00 Medium
A04 Insecure Direct Object References Medium I/D 16.00 Medium
A05 Security Misconfiguration Medium I/D 16.00 Medium
A06 Sensitive Data Exposure High I/D 36.00 High
A07 Missing Function Level Access Control Medium I/D 16.00 Medium
A08 Cross-Site Request Forgery (CSRF) Medium I/D 16.00 Medium
A09 Using Components with Known Vulnerabilities Medium N/I - -
A10 Unvalidated Redirects and Forwards Medium N/I - -
Overall = 20.50 Medium
4.6.3.2 Other Vulnerabilities

Score Rating
A11 Apache Denial of Service (DoS) Medium I/D 24.00 Medium
A12 PHP Denial of Service (DoS) Medium I/D 16.00 Low
A13 HP System Management XSS High I/D 16.00 Low
Overall = 18.67 Medium
Status: I/D = Identified, N/I = Not Identified (Tested but Not Identified), A/L = Alert, N/A = Not Applicable
Risk Score based on risk calculation: Risk = Threat x Vulnerability x Impact.
4.6.3.3 Risk Ranking
The following summarizes vulnerabilities based on severity or risk ranking:
Severity Total
High 1
Medium 8
Low 2
ACME Consulting
Vulnerability by Severity
9%
18%
73%
High Medium Low
Vulnerability by Type
A11 Other Vulnerabilities 3.96
A10 Unvalidated Redirects and Forwards 0.00
A09 Using Components with Known Vulnerabilities 0.00
A08 Cross Site Request Forgery (CSRF) 1.00
A07 Missing Function Level Access Control 1.50
A06 Sensitive Data Exposure 2.50
A05 Security Misconfiguration 6.00
A04 Insecure Direct Object References 1.75
A03 Cross Site Scripting (XSS) 6.50
A02 Broken Authentication & Session Management 4.00
A01 Injection 0.50
0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00
Based on vulnerabilities found for each category.
ACME Consulting
4.6.4 DemoApp Mobile
4.6.4.1 OWASP Mobile Top 10 Risks

Score Rating
M01 Weak Server Side Controls High N/I - -
M02 Insecure Data Storage High N/I - -
M03 Insufficient Transport Layer Protection Medium N/I - -
M04 Unintended Data Leakage High I/D 12.00 Low
M05 Poor Authorization and Authentication High N/I - -
M06 Broken Cryptography High N/I - -
M07 Client Side Injection Medium N/I - -
M08 Security Decisions via Untrusted Inputs High N/I - -
M09 Improper Session Handling High N/I - -
M10 Lack of Binary Protections High N/I - -
Overall = 12.00 Low
4.6.4.2 Other Vulnerabilities

Score Rating
M11 Multiple Software Errors/Bugs Medium I/D 12.00 Low
Overall = 12.00 Low
Status: I/D = Identified, N/I = Not Identified (Tested but Not Identified), A/L = Alert, N/A = Not Applicable
Risk Score is based on risk calculation: Risk = Threat x Vulnerability x Impact.
4.6.4.3 Risk Ranking
The following summarizes vulnerabilities based on severity or risk ranking:
Severity Total
High 0
Medium 0
Low 2
ACME Consulting
Vulnerability by Severity
0%
100%
High Medium Low
Vulnerability by Type
M11 Other Vulnerabilities 6.00
M10 Lack of Binary Protections 0.00
M09 Improper Session Handling 0.00
M08 Security Decisions via Untrusted Inputs 0.00
M07 Client Side Injection 0.00
M06 Broken Cryptography 0.00
M05 Poor Authorization and Authentication 0.00
M04 Unintended Data Leakage 2.00
M03 Insufficient Transport Layer Protection 0.00
M02 Insecure Data Storage 0.00
M01 Weak Server Side Controls 0.00
0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00
Based on vulnerabilities found for each category.
5 Methodology
5.1 Planning
During planning, we gather information from the client-server application (profiling)
which is installed in our testing environment (virtualization). Then, we detect the path
information, the configuration file used by the application and other identifiable
components.
ACME Consulting
5.2 Exploitation
Utilizing the information gathered in planning, we start to find the vulnerability for
each piece of the application that we discovered then trying to exploit it. Vulnerability
identification and exploitation are done by using automated vulnerability scanners
combined with manual tests to validate and confirm the results.
5.3 Reporting
Based on the results from the first two steps, we start analyzing the results. Our risk
rating is based on this calculation:

Impact Low 1 2 3 4 1 4 6 8 3 6 9 12 4 8 12 16
Medium 2 4 6 8 4 8 12 16 6 12 18 24 8 18 24 32
High 3 6 9 12 6 12 18 24 9 18 27* 36 12 24 36 48
Critical 4 8 12 16 8 16 24 32 12 24 36 48 16 32 48 64
Table 5: Risk Analysis [1]
* Based on our analysis, risks that fall under this category will be considered as High.
L Low 1 – 16
M Medium 17 – 32
H High 33 – 48
Table 6: Risk Rating Calculation [1]
[1] SANS Best Practices Whitepaper http://www.sans.org/reading-room/whitepapers/bestprac/writing-

penetration-testing-report-33343, NIST SP800-30 Rev 1 Risk Management Guide for Information Technology
Systems http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf)
After calculating the risk rating, we start writing the report on each risk and how to
mitigate it.
6 Detailed Findings
6.1 OWASP Top 10 Vulnerabilities - 2013
Several known vulnerabilities related to OWASP Top 10 Vulnerabilities – 2013 with
“Medium” to “High” severity rating, exist in the application being tested.
ACME Consulting
Detailed findings can be found in Technical Reports (delivered separately for technical
audiences).
6.2 Other Web Vulnerabilities

In addition to “High” risk vulnerabilities identified by OWASP Top 10 Vulnerabilities -
2013, several known vulnerabilities such as Apache, PHP, and HP System Management
Denial of Service (DoS) attack, exist in the application being tested.
audiences).
6.3 OWASP Mobile Top 10 Risks - 2013

Several known vulnerabilities related to OWASP Mobile Top 10 Risks – 2013 with “Low”
severity rating, exist in the application being tested.
audiences).
6.4 Other Mobile Vulnerabilities

In addition to “Low” risk vulnerabilities identified by OWASP Mobile Top 10 Risks -
2013, several known vulnerabilities such as Multiple Errors/Bugs, exist in the
application being tested.
audiences).
7 Other Recommendation
7.1 People
7.1.1 Core Security Training
Software security training is a prerequisite for implementing the SDL, and individuals
in technical roles (developers, testers, and program managers) who are directly
ACME Consulting
involved with the development of software programs must attend at least one unique
security training class each year.
Understanding software security problems is a foundational part of building better

software. By allowing individuals involved with the development of software programs
to stay informed about security basics and latest trends in security and privacy, you’ll
increase their commitment to writing more secure software.
Basic software security training should cover foundational concepts such as:
 Secure design, including attack surface reduction, defense in depth, the principle of
least privilege, secure defaults.
 Threat modeling, including overview of threat modeling, design implications of a

threat model, coding constraints based on a threat model. Secure coding, including
buffer overruns (for applications using C and C++), integer arithmetic errors (for
applications using C and C++), cross‐site scripting (for managed code and web
applications), SQL injection (for managed code and web applications), and weak
cryptography.
 Security testing, including differences between security testing and functional

testing, risk assessment, security testing methods Privacy, including types of privacy‐
sensitive data, privacy design best practices, risk assessment, privacy development
best practices, and privacy testing best practices.
7.2 Process
��
7.2.1 Develop and Implement Testing Framework
A reference framework that comprises techniques and tasks that are appropriate at
various phases of the software development lifecycle (SDLC). Companies and project
teams can use this model to develop their own testing framework and to scope testing
services from vendors. This framework should not be seen as prescriptive, but as a
flexible approach that can be extended and molded to fit an organization’s
development process and culture.
This testing framework could consist of the following activities that should take place:
ACME Consulting
 Before Development Begins
 During Definition and Design
 During Development
 During Deployment
 Maintenance and Operations
Refer to OWASP Testing Guide v4.0 (2014) as an example of a typical testing framework
that can be developed and implemented within an organization:
https://www.owasp.org/index.php/OWASP_Testing_Project
7.2.2 Implement Security Development Lifecycle (SDL)
A software development security assurance process consisting of security practices

grouped by seven phases: training, requirements, design, implementation, verification,
release, and response.
Refer to Microsoft SDL as an example of a good security assurance process:

http://www.microsoft.com/security/sdl/default.aspx
7.3 Technology
7.3.1 Implement Web Application Firewalls (WAFs)
Web Applications Firewalls are a special breed of product used to detect attacks against
web applications in more depth than an Intrusion Prevention System. WAFs can be
used in our environments to provide enhanced protection to web applications/servers.
Using a WAF is a good way to augment our IPSs and provide another layer of protection
for our Defense‐In‐Depth architecture.
8 Conclusion
Most of the vulnerabilities found in the Initial Phase of our assessment have been
successfully remediated. Vulnerabilities that could not be remediated immediately due
to some reasons still introduce risks, therefore, compensating controls must be applied
and implemented to reduce or mitigate risks associated with vulnerabilities being
exposed.
ACME Consulting
Compensating security controls are controls that provide an alternative to normal
controls that cannot be used for some reason. For instance, a certain server cannot
have antivirus software installed because it interferes with a critical application. A
compensating control would be to increase monitoring of that server or isolate that
server on its own network segment.
For systems to remain secure, security posture must be evaluated and improved
continuously. Establishing the organizational structure that will support these ongoing
improvements is essential in order to maintain control of corporate information
systems.
We conclude that the overall security has been improved. We hope that the ABC’s
applications will be reviewed at least every 6 (six) months or annually depending on
the amount of changes to the source code.
9 References
Appendix A – Acunetix Vulnerability Scanning Report
Attached Acunetix WVS scan reports
Appendix B – Manual Testing

Attached Manual Testing report
ACME Consulting
This page is intentionally left blank
Writing an Effective Penetration Testing Report
AN EXECUTIVE VIEW
Report writing is a crucial part for any service providers. A report should detail the outcome of
the test and, if you are making recommendations, document the recommendations to secure
any high-risk systems. Writing an effective penetration testing report is an art that needs to be
learned and to make sure that the report will deliver the right information to the targeted
audience.
A penetration testing report should be able to capture the following:
 Obtain an accurate understanding of your security and risk posture

 Comprehensive reporting, relevant to your organization and stakeholders
 Comply with industry regulations and information security best practices
This book tries to explain some common questions;
 Why is a penetration test report so important?

 Who is the report for?
 What should the report contain?
The primary objectives and expectations are to:
 Understand how to create a good and effective penetration testing report

 Understand the mechanism to provide an effective deliverable
 Apply risk management knowledge and skills and blend them in your deliverables

Writing An Effective Pentest Report v1.0 Rev 10022016 by Semi Yulianto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Writing An Effective Pentest Report v1.0 Rev 10022016 by Semi Yulianto

Uploaded by

Copyright:

Available Formats

PENETRATI

Andryanto Eka Wijaya

Also my gratitude to my parents and family

Deep knowledge and excellent skills on Vulnerability Assessment, Ethical Hacking,

Involved in various projects related to vulnerability assessment and penetration testing

Feel free to contact the author through: semi.yulianto2009@gmail.com

Comments and suggestions are welcome.

Jakarta, November 2014

Network security assessment is a combination of automated and hands-on manual vulnerability

 Network reconnaissance to identify networks or hosts

Network reconnaissance & scanning

• Nmap or ZenMap (open source)

Vulnerability identification & investigation

• Nmap with NSE (open source)

• Metasploit Framework (open source)

 NIST SP 800-115, Technical Guide to Information Security Testing and Assessment

Answers to the above questions are explained as follows:

Planning and Preparation

Senior Security Network

Security Security Technical

Figure 2: Sample Project Team Resources (Small)

No. Position/Function Resource Name

Vulnerability - a weakness which allows an attacker to reduce a system's information assurance.

Impact - a successful threat exercise of a vulnerability (internal or external).

Risk rating based on this calculation:

Risk = Threat x Vulnerability x Impact

Figure 2: Risk Analysis and Rating Calculation

Host Type Threat Vulnerability Impact Risk

Overall Risk = MEDIUM

Gathering and Translating Raw Data

Analyse and Filter Your Data

nmap <options> –iL <target_list> –A <output_filename>

nmap -n –sS –sU –Pn –P0 –iL targets.txt –A output

nmap -n –Pn –P0 –A –iL targets.txt –A output

Now we can convert the output.xml to output.html as shown below:

xsltproc output.xml –o output.html

The above command results three different types of files:

Filename File Type

Secure Data Exchange/Transmission

Translating Raw Data

Figure 4: Sample Vulnerability by Type

No. Vulnerability Type Total

Figure 5: Sample Chart - Summary of Vulnerable Hosts

Default or weak password 10

Figure 6: Sample Summary of Vulnerable Hosts

No. Host IP Hostname Operating System Vulnerable Exploited? Risk Factor

Figure 7: Sample Project Activities

No. Activity/Task Estimated Duration Start End Complete (%)

Figure 8: Sample Gantt chart (not related to Figure 7)

 What is the subject?

Standards and Templates

Have a look at some examples here for your references:

1. NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

2. SANS Institute – Writing Penetration Testing Report

4. PTES Reporting Standard

A good example of an organize penetration testing report is a well-structured and organized

The Executive Report (Report ID: 001)

The Technical Report (Report ID: 002)

The Hybrid Report (Report ID: 003)

 Type of audience (target audience)

 Executive level of management (top-level management, board of directors, senior

There were identified:

- 7 vulnerabilities due to easily guessable credentials.