How to create a pentesting report (with examples)

🔥 The world of cybersecurity only exists if there is documentation about it.

Reasons to Create a Penetration Testing Report

The world of cybersecurity is extremely formal, filled with regulations, certifications, audits, etc. For this reason, it makes a lot of sense for ethical hackers to develop strong documentation skills. A formal record of all activities, findings, strategies, etc., must be maintained. The report not only documents the results of the test but also provides a framework for continuous improvement, informed decision-making, and regulatory compliance. It is an essential part of the security process.

1. Documentation of Results: A report documents all findings from the test, including detected vulnerabilities, the methodology used, and technical details. This is crucial for maintaining a clear record of the system's current security status.

2. Prioritizing Remediation: The report helps prioritize corrective actions based on the criticality of the vulnerabilities found. Without a report, it might be difficult for the security team to decide which issues to address first.

3. Regulatory Compliance: Many industry regulations and standards (such as PCI-DSS, HIPAA, or ISO 27001) require regular penetration testing and the submission of reports as part of compliance requirements. A formal report is evidence that the test has been conducted.

4. Communication with Management: A well-structured report allows executives and other stakeholders to understand the risks the organization faces and the necessary actions to mitigate them. This is important for justifying cybersecurity investments and making informed decisions.

5. Continuous Improvement: The penetration test report can serve as a reference for future tests. It allows the organization to track progress in improving the system's security over time.

6. Legal Defense: In the event of a security breach or incident, having a detailed penetration test report can serve as evidence that proactive measures were taken to secure the systems, which may be relevant in legal proceedings.

What Should Be Covered in Your Report?

The following is not a table of contents, which we will discuss later, but it's important to start by highlighting the topics you should cover in the report:

• Scope: Describes the objectives, limitations, and scope of the pentesting, clearly specifying what is allowed and what is not.
• Reconnaissance: Includes the results obtained from gathering public information, such as WHOIS, DNS, and other methods used to investigate the target.
• Vulnerability Scanning: Presents a list of vulnerabilities identified using automated scanning tools.
• Exploits Used: Provides details of the exploits employed, explaining how they were carried out and whether any adjustments or customizations were necessary.
• Penetration Testing Results: Documents the manual tests conducted, including the exploitation of vulnerabilities and any access obtained to systems.
• System Activity Log: Details the actions performed on the target systems, such as the commands used, changes made, and any other relevant activities.
• Screenshots and Evidence: Includes images that support the results, demonstrating successful exploitation or the identification of vulnerabilities.
• Data Collection: Describes any confidential or sensitive information that was gathered during the pentesting.
• Mitigation Recommendations: Offers proposals to address and correct the identified vulnerabilities, with specific steps and best practices.
• Conclusions and Executive Summary: Provides an overall summary of the activities performed, key findings, and a risk assessment, aimed at a non-technical audience.
• Signatures and Authorizations: Includes the signatures of the security team and authorized parties, validating the content and scope of the report.
• Client Review: Mentions the session to review the report with the client, where doubts are clarified, and the results are discussed.

👉 Precise and complete documentation is essential to ensure the effectiveness and integrity of penetration tests, as well as to provide clients with the necessary information to improve their security posture.

Sections and Parts a Penetration Testing Report Should Have

This is a very common question among professionals who are starting to work in pentesting and although there are templates that can be easily found on the Internet and some tools generate them automatically, as professionals we must follow certain rules when preparing the documents to be delivered to customers after finishing the work.

Basic notions

Reporting is one of the most important issues in any audit and should clearly and concisely reflect the findings and conclusions you have reached. Any report should normally include at least the following.

Cover page

The cover page of the document is usually generic and includes, among other things, information about the company, the date on which the document is delivered, and basic details.

Index

In the table of contents, it is common to include links or shortcuts to make it easy to move through the different sections of the document. Example:

CONTENT

SCOPE..........................................................................................................................................................4

REVIEW SHEET..........................................................................................................................................5

OBJECTIVES AND WORK METHODOLOGY......................................................................................................6

General Description of Tests by Pentesting Phase................................................................................7

Operation......................................................................................................................................................9

Overall risk rating.........................................................................................................................10

HIGH LEVEL - Absence of Anti-CSRF tokens....................................................................................11

CONSEQUENCES........................................................................................................................................12

SOLUTION..................................................................................................................................................13

EVIDENCE AND REFERENCES........................................................................................................................14

HIGH LEVEL - Content Security Policy (CSP) Header Not SeT.......................................................................15

CONSEQUENCES........................................................................................................................................16

SOLUTION..................................................................................................................................................17

EVIDENCE AND REFERENCES........................................................................................................................18

HIGH LEVEL - Missing Anti-clickjacking Header.............................................................................................19

CONSEQUENCES........................................................................................................................................20

SOLUTION..................................................................................................................................................21

EVIDENCE AND REFERENCES........................................................................................................................22

MEDIUM LEVEL - Application Error Disclosure.................................................................................................23

CONSEQUENCES........................................................................................................................................24

SOLUTION..................................................................................................................................................25

EVIDENCE AND REFERENCES........................................................................................................................26

MEDIUM LEVEL - Cookie No HttpOnly Flag......................................................................................................27

CONSEQUENCES........................................................................................................................................28

SOLUTION..................................................................................................................................................29

EVIDENCE AND REFERENCES........................................................................................................................30

MEDIUM LEVEL - Cookie Without Secure Flag.................................................................................................31

CONSEQUENCES........................................................................................................................................32

SOLUTION................................................................................................................................................33

EVIDENCE AND REFERENCES........................................................................................................................34

MEDIUM LEVEL - Cookie Without Secure Flag.................................................................................................35

CONSEQUENCES........................................................................................................................................36

SOLUTION..................................................................................................................................................37

EVIDENCE AND REFERENCES........................................................................................................................38

MEDIUM LEVEL - Permissions Policy Header Not Set.......................................................................................39

CONSEQUENCES........................................................................................................................................40

SOLUTION..................................................................................................................................................41

EVIDENCE AND REFERENCES........................................................................................................................42

MEDIUM LEVEL - SSL/TLS uses weak hashing and encryption algorithms................................................................43

CONSEQUENCES........................................................................................................................................44

SOLUTION..................................................................................................................................................44

EVIDENCE AND REFERENCES........................................................................................................................46

MEDIUM LEVEL - Strict-Transport-Security Header Not Set.............................................................................47

CONSEQUENCES........................................................................................................................................48

SOLUTION..................................................................................................................................................49

EVIDENCE AND REFERENCES........................................................................................................................50

MEDIUM LEVEL - X-Content-Type-Options Header Missing.............................................................................51

CONSEQUENCES........................................................................................................................................52

SOLUTION..................................................................................................................................................53

EVIDENCE AND REFERENCES........................................................................................................................54

LEVEL Info - General Information.................................................................................................................55

LEVEL Info - Reverse IP Lookup..............................................................................................................58

LEVEL Info - IP Analysis..............................................................................................................................59

LEVEL Info - Domain Analysis...............................................................................................................61

LEVEL Info - Port Analysis....................................................................................................................62

LEVEL Info - SSL Analysis.................................................................................................................................67

LEVEL Info - Services Analysis...................................................................................................................70

Version Control

The version control must include at a minimum, a description of the changes introduced at each modification of the document with a date and author. Example:

Revision sheet

Disclaimer and confidentiality of information

Scope

The scope of the present work consisted of assessing the security risk and its degree of exposure through intrusion techniques. Security tools, vulnerability analyzers, and information gathering methodologies were used in the same way as they would be used by attackers.

The tasks carried out included active reconnaissance of systems to assess their potential risks. Finally, an analysis and intrusion attempt was performed on the active systems to find potential vulnerabilities that could affect them. The objectives carried out for the Pentest are the selection of the domain, systems, services, and applications on the following IP addresses and domains:

1200.190.180.170: webdelcliente.com

The client contracted Router ID to conduct an external audit against its websites and applications to provide a practical demonstration of the effectiveness of its systems and security methodology, as well as to provide an estimate of its susceptibility to exploitation, integrity, exposure, or loss of data.

The test was conducted by Router ID's Information Security Penetration Testing Method. Router ID's Information Security Analyst (ISA) conducted the audit in coordination with the client's Information Technology (IT) staff members to ensure secure, orderly, and complete testing within the approved scope.

Consider the great importance of fixing these security breaches that allow a great risk of compliance violation and potentially subject to fines and loss of business reputation.

This Report contains confidential information and should not be sent via e-mail, fax, or any other electronic means unless specifically approved by the Company's security policies. All electronic or hard copies of this document should be stored in a secure location.

Do not share the information contained in this document unless the other person is authorized to do so. router-id.com permits you to copy this report for the purpose of disseminating information within your organization or any regulatory agency.

Methodologies used

Objectives and methodologies used

This document details the security assessment referred to as External Pentesting. The objective of this work was to identify vulnerabilities within the scope agreed between the parties and the risks they may cause to the company's business.

It is your responsibility to implement the recommendations that will be made, to increase security in the domains (application development, infrastructure support), as well as managing the organization's level of risk exposure and compliance with regulatory issues.

If you do not have qualified personnel for this task we can carry it out. Ask about our security and hardening remediation service.

The specific objectives are:

• Detect vulnerabilities and security problems that can be exploited by attackers.
• Evaluate the effectiveness and response of the implemented security systems (Firewalls, intrusion detection, and other systems).
• Analyze and determine the level of exposure of the technological infrastructure of the systems according to the vulnerabilities detected.
• Present concrete recommendations to correct the problems and security breaches detected and minimize the associated risks.

Audit Context and General Notions

General description of phase tests by pentesting

1. Advanced SQL Injection

2. IP Analysis

3. Metadata Analysis

4. Port Analysis

5. Services Analysis

6. Web Services Analysis

7. Domain Analysis

8. SSL Analysis

9. Apache not supported

10. Application Error Disclosure

11. Robots and sitemap file

12. Backup files

13. Host Header Attack

14. Absence of CAPTCHA

15. Absence of Anti-CSRF tokens

16. Authentication

17. Autocomplete

18. Reverse IP Lookup

19. Outdated client components

20. Checking anti-CSRF tokens

21. Test network/infrastructure configuration

22. CORS / Cross-Origin Resource Sharing Misconfiguration

23. Relative Path Mix-up

24. HTTPS Content Available via HTTP

25. Content Security Policy (CSP) Header Not SeT

26. Clear Text Password

27. Cookie No HttpOnly Flag

28. Cross Site Scripting

29. Cross-Domain JavaScript Source File Inclusion

30. Role Definition

31. Downloading Documents without a Valid Session

32. Cross Domain / HTTP Access Control De-configuration

33. Firewall detection and strength

34. Information Disclosure - Insecure PHP Directives

35. DISCLOSURE OF INFORMATION - Handling of inappropriate errors

36. DISCLOSURE OF INFORMATION - by ''X-Powered-By''

37. DISCLOSURE OF INFORMATION - Debugging Error Messages

38. Timestamp Disclosure - Unix

39. Proxy disclosure

40. IIS and .NET Version Disclosure

41. User input or login

42. Default authorization scheme

43. Session management scheme

44. Information leakage

45. HSTS Missing From HTTPS Server (RFC 6797)

46. HTTP TRACE Methods Allowed

47. General Information

48. NoSQL Injection - MongoDB

49. Remote Operating System Command Injection

50. XSLT Injection

51. Directory Listing

52. Site Maps

53. Missing Anti-clickjacking Header

54. Path Traversal

55. Permissions Policy Header Not Set

56. PHP Multiple Vulnerabilities

57. Weak or not enforced User Policy

58. Private IP Disclosure

59. Uncontrolled redirects

60. Information Gathering Search Engine Acknowledgement

61. Skipping 403

62. Secure Pages Include Mixed Content

63. Server-side template injection

64. SQL Injection

65. SSL/TLS, SSLv2 and SSLv3 detection

66. Strict-Transport-Security Header Not Set

67. SUB RESOURCE INTEGRITY ATTRIBUTE MISSING

68. Unauthenticated Blind SSRF via DNS Rebinding

69. Unrestricted file uploading

70. Exposed session variables

71. Outdated WordPress Themes and Plugins

72. X-Content-Type-Options Header Missing

Exploit

The exploitation phase consists of carrying out all those actions that may compromise the audited system, the users or the information it handles. Mainly it is checked that attacks such as the following cannot be carried out:

• Code injection
• Inclusion of local or remote files
• Authentication evasion
• Lack of authorization controls
• Execution of commands on the server side
• Cross Site Request Forgery attacks
• Error control
• Session management
• Information leakage
• Session hijacking
• Checking conditions for denial-of-service attacks
• Malicious file uploading

👉 These types of attacks are performed by adapting the development of each attack, techniques in use, and the latest available technologies.

Post exploitation

If a vulnerability is found that allows other actions to be performed on the audited system or in its environment, additional checks will be carried out in order to verify the criticality of this vulnerability. Depending on the possibilities that a specific vulnerability allows, the following post-exploitation actions will be attempted:

• Obtaining confidential information.
• Evasion of authentication mechanisms
• Performing actions on the user side
• Performing actions or executing commands on the server hosting the application
• Privileges available on the server (if access to the server is gained)
• Other systems or services accessible from the compromised application
• Perform actions without the user's consent.

📖 The possibility of chaining several vulnerabilities to gain higher level access or to evade security controls will also be scenarios assessed when performing the risk analysis. We use several methodologies, but we will focus on OWASP TOP 10 - 2021.

A worldwide non-profit organization dedicated to improving the security of applications and software in general.

https://owasp.org/Top10/es/

Overall risk rating

Having considered the potential outcomes and risk levels assessed for each documented testing activity, Hackware considers the overall risk exposure concerning attempts by malicious actors to breach and control resources within its information environment to be HIGH (as determined using the CVSSv3 Risk Rating CVSSv3 Score).

https://www.incibe-cert.es/blog/cvss3-0

The table below provides a key to the risk naming and colors used throughout this report to provide a clear and concise risk scoring system.

It should be noted that quantification of the overall business risk posed by any of the issues identified in the tests is beyond our scope. This means that some risks may be considered high from a technical point of view, but, as a result of other controls unknown to us, may or may not be critical from a business point of view.

Risk Rating	CVSSv3 Score	Description
CRITICAL	9.0 - 10	A critical vulnerability has been discovered. It needs to be resolved as soon as possible.
HIGH	7.0 - 8.9	A high vulnerability has been discovered. This requires a short-term resolution.
MEDIUM	4.0 - 6.9	A medium vulnerability has been discovered and needs to be resolved during the maintenance process.
LOW	0.1 - 3.9	A low vulnerability has been discovered. This should be addressed as part of routine maintenance tasks.
INFO	0	A discovery has been made and is reported for information. This should be addressed to comply with leading practices.

• Tests performed, discoveries, and proofs of concept (we will look at this in more depth).
• Conclusions and recommendations (more on this in more detail).

In the introduction and context of the document, details about the audit to be performed, and its scope are described, something that should also be reflected in the agreement signed with the client. This part of the document is intended to inform the reader about the tests that have been performed without going into too much detail, as an executive summary.

Another important detail that must be taken into account in any report is the section corresponding to the methodologies used, which in any case will depend on the audit to be performed. It is highly advisable to implement methodologies that have already been refined and are well-accepted by the industry. For example, some interesting methodologies are listed below, although they apply depending on the type of audit performed:

• Penetration Testing Execution Standard (PTES)
• PCI (Payment Card Industry) Penetration testing guide
• Open Source Security Testing Methodology Manual (OSSTMM)
• OWASP Top 10
• OWASP Testing Guide
• OWASP Mobile Top 10
• OWASP API Top 10

The actual content of the document should include the tests that have been performed, explaining each of the stages of the audit, tools, and techniques used, as well as the results of each one. This is a section where it is important to include the details most clearly and concisely, avoiding redundancies and overly long blocks of code or log outputs to favor the readability of the document. If it is necessary to include such elements, it would be advisable to address them in separate annexes so that the reader can review them separately. At this point, probably the most important thing is that the information should be of value. In other words, there is no point in including each of the proofs of concept that have been executed if they have not produced the expected results. Only information that is relevant and of interest to the purpose of the audit should be included. There is no point in spending 2 or 3 pages of the report explaining that an Apache exploit has been launched (for example) if the exploit did not work because the service is probably not vulnerable. Include only information that adds value.

Finally, in the recommendations section, it is useful to include some points to take into account to improve the security of the audited system, although you can also highlight those configurations and/or good practices that are being carried out so that the client continues to make use of them and encourage their maintenance. If vulnerabilities are found, it is very important to include countermeasures or recommendations that are useful to mitigate them or protection mechanisms that help to solve the detected problems. Be careful, the fact of including these countermeasures is not binding and does not mean that you are the one who is going to implement them. You have been hired to execute an audit and detect problems, implementing the solutions is something to be assessed by the client.

Type of audit

Different types of reports can be created depending on the client's needs, which have to be reflected in the agreement. The audit to be performed may focus on one of the following scenarios:

• Perimeter/external pentesting.
• Internal pentesting.
• Wireless pentesting.

Depending on each case it is necessary to take into account additional factors that should be reflected in the document, for example when a client requests a mixed approach and one part of the audit will be external and another part internal.

Technical Report and Executive Report

With all of the above clear, the first thing to keep in mind is that not all clients are the same and in some cases, it is necessary to develop 2 or more reports reflecting the tasks performed. It is important to adapt and understand the target audience. That is to say, if the person who is going to read the report is a technical person, he/she will be interested if it is oriented to describe the vulnerabilities, defects, and recommendations provided by the document. In this case, it will be reviewed by a person who has at least some basic knowledge and will understand what you are saying, but if, for example, the same document is read by a manager, area manager, or non-technical personnel, it is most likely that he/she will understand little or nothing. Imagine for a moment that a financial expert (to give an example) gives you a technical report of a financial audit, do you think you will have enough criteria to say if what you have been sent is “right” or “wrong”? you will probably skip reading it and send it to someone who is an expert on the subject. Depending on the scope and what has been discussed with the customer you will probably have to produce one report for technical staff and another for decision makers, in each case the language you use and the message you convey must be clear enough for the target reader.

Pentesting Report Templates and Examples

⚠️ Templates do Not Make a Good Report, use them to learn but don't copy paste.

You can use templates available on the Internet or those that may be available in the company where you work, of course, it is perfectly valid but it is still a basis that helps you save time in defining a design and “layout” sections. You can (and should) adapt the template to the audit you are performing, it is not something static that you must follow to the letter. If you need to add, remove, or move sections you do it and that's it. Do not let the template you use become a problem, it has been created precisely so that you can do the job faster.

Here is a list of some reports we found over the internet

1. Sample Penetration Test Report by Astra.
2. Sample Penetration Test Report by Pentest Hub.
3. Sample Penetration Test Report By Purple Sec
4. Penetration Test Template by University of Phoenix.

Crafting Clear and Concise Reports

How to Write a Successful Pentesting Report

1. Planning in Writing: Avoid leaving report writing to the last minute. Document findings during the audit and eliminate unnecessary information to avoid a lengthy but worthless report.
2. Peer Review: Writing is an art. Ask a colleague to read the report before submitting it. Clarity for you may not be the same for others. Getting a second opinion helps to catch errors and improve understanding of the message.
3. Make it Easy to Read with Visual Elements: Incorporate screenshots to illustrate key points. Keep quality over quantity; conciseness is key. Avoid irrelevant details and focus on essential information.
4. Levels of Criticality: Assign severity levels to each vulnerability according to the CVS model. Emphasize the urgency of solving critical problems and distinguish those of lesser concern.
5. Good Writing Practices: Pay attention to spelling details for a professional presentation. Include contact information, schedules, and communication channels. Consult with the client before suggesting updates to outdated services.
6. Practical Recommendations: In the screenshots, preserve privacy by avoiding sensitive information. Attach PoCs and exploits in attachments. Use links for technical concepts. Provide recommendations in “checklist” format and provide additional references and instructions.
7. Avoid Excesses and Personal Opinions: Adjust the amount of captures to avoid excesses. Be neutral; avoid personal opinions. Maintain a balance so that the report does not look like a photo album but like a quality document.
8. Event History: Include a history with scope changes, organizational changes, system layout, and relevant events. Provide a chronological context to enhance understanding of the audit process.
9. Useful Tools and Templates: Uses templates from PurpleSec, Pentest-hub, TCM Security, Offensive Security, and TGB Security. Explore the PWNDoc tool for efficient reporting.