Penetration testing is the process of attacking a system to determine security vulnerabilities. This is often done as a preliminary step before the system is deployed or as a check to see how well a system has been hardened. A penetration testing report is a document that summarizes the vulnerabilities found during a penetration test.
Solid reporting skills are a valuable instrument to connect with a client. As a pentester, this is particularly useful for explaining what you have done when testing applications and networks. The report offers a chance to clarify what the target’s security level is, the way different attacks were executed, and what sort of work was performed during the pentest assessment.
A Penetration test report should include the following:
We describe here what the objectives are of conducting the test What are the research questions that the client wants to have answered? For example, can an attacker access certain data in the system without being authorized? Is it possible to elevate the rights of basic users to admin level? It is a good opportunity to point out again why this assessment is so important.
Tools and Setup:
The tools used and the setup that was required to start the penetration test. This can also include the accounts that were provided and if the test was performed as a white, black, or grey box.
This chapter of the penetration testing report describes various steps or phases of the penetration testing methodology.
i.e.: There are seven stages during a penetration test. These seven stages are:
Several standard frameworks and methodologies exist for conducting penetration tests. These include the Open Source Security Testing Methodology Manual (OSSTMM), the Penetration Testing Execution Standard (PTES), the NIST Special Publication 800-115, the Information System Security Assessment Framework (ISSAF), and the OWASP Testing Guide.
Scope and Rules of engagement
A determination of scope is important when you are going to perform a test. For instance, you need to know what are the IP ranges and URLs of the web applications that are in scope. In this paragraph, you describe which segments belong to the “to be tested” scope and which parts are explicitly excluded or any other constraints.
Pentest test reports regularly start with a high-level synopsis of the pentester’s discoveries. This summary is expected to be a brief outline of the outcomes for organization chiefs and directors, who are searching for significant points without wanting to delve into the technical details of the report.
This outline uncovers where the pentesters hacked the security controls and what data they were able to reveal inside the networks. The most outstanding aspect and the dangers the company is facing at that moment. After that, optionally is a paragraph of the security strengths and security weaknesses that were found.
In addition, it explains proposals for security upgrades, including what needs to be secured first, followed by other short, medium, and long-haul objectives for improving the organization’s security.
Finding overview example
|Number||Vulnerability name||Severity||CVSS score|
|1||Remote Code Execution||Critical||9.9|
|4||HTTP Header Injection||Medium||6.9|
|6||Programming error message||Low||3.9|
The title of the vulnerability needs to be a short name that describes the finding, such as Cross-site scripting or Unsupported version detection.
This segment contains an explanation of the issue and a clarification of the effect it could cause whenever it was exploited. This is typically kept general and clear to give the client an idea about the issue. You can explain here how the issue functions, leaving particulars about the client’s current situation for other segments of the report.
This is the application or server where the vulnerability is found, this can be an IP address, URL, or anything where the finding is from.
This part is mainly used for administrators or developers that actually have to solve the finding and verify if the fix is implemented the correct way.
To be able to reproduce the finding it has to be written in very simple steps what to do. From every click to every entry, supported with screenshots and short videos that can be added as an attachment.
Usually, hackers have to write exploits as they find vulnerabilities. Others are available on the internet. The tester should include detailed exploit steps or direct the reader of the report to the public exploit code.
This is an important section to tell the client what the impact of the vulnerability would be if it were successfully exploited. Make the explanation of the impact as realistic as possible, rather than writing down what could theoretically happen. The best way to do this is to stick to immediate consequences such as “An attacker may access your user account.”
To just express that something is dangerous does not necessarily mean everyone understands the risk. Therefore, it is very important to explain why it is so risky. For example, if there is an unrestricted file upload vulnerability found, it should be mentioned that because of this the attacker can execute code remotely and elevate the rights within the application to view all the user’s private data, such as medical or banking information.
The OWASP Risk Rating Methodology describes this on a scale of Low to Very High. https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
A CVSS Score (Common Vulnerability Scoring System) supports companies in defining the severity of an issue on a scale of 0 to 10 — no risk to critical. Therefore, it is an important component to show why did you assign a specific risk category to a specific finding.
CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics, as shown below:
Links will be added here with more information about the finding from known sources. I.e. the vendor or CVE details. CVE stands for “The Common Vulnerabilities and Exposures”. This system provides a reference method for publicly known information-security vulnerabilities and exposures. https://cve.mitre.org/
In the wake of strolling through the subtleties of the pentest, the following area will show possible solutions for each finding.
The start of the remediation explanation will be a short note on what the next step is to take, after that, a more defined explanation is given, pinpointed on the client’s specific situation.
For example, the start of the recommendation will look like
- Install the latest software version of a component.
- Upgrade the current hardware asset
- Implement secure passwords.
The detailed description is:
- Version 3.2.1 is found on component X. This version is vulnerable for CVE-xx-xx-xx. This is a remote code execution vulnerability. The component has to be updated to version 4.0.1.
- The current hardware is EOL(End of Life). The hardware needs to be replaced by a supported version. Make sure the new hardware is supported by the vendor and receives frequent updates.
- Default passwords are being used on these devices. Ensure that all the passwords are replaced with unique combinations of capital and lowercase letters, special characters, and numbers with a minimum length of 12 characters. The password should not contain dictionary words. Privileged accounts are advised to use 25 characters or greater.
The conclusion can consist of two parts, recommendations and the risk summary. The recommendations, where advise is given about patching, enhancing, or implementing security measures as needed. The purpose is not only to list the problematic areas that need to be addressed, but also to providing solutions for the problems. Strategic and tactical recommendations to help the client with risk mitigation decision making in terms of resource investments.
The penetration testing report is the tool that the pentester uses to communicate his work to the customer. Therefore, it should be easy to understand for different knowledge levels so they are able to take decisions to address the identified risks.