When it comes to offensive security, a lot of information regarding the ways of writing an effective pentest and bug-bounty report are out there.
Although, these reports contains findings based on technical approach (penetration testing or bug bounty programs), most of these reports are not properly documented. An indication of the necessity for theoretical knowledge and a justification of the importance of academia.
This is due to the fact, that reading from books alone, is not sufficient enough to learn on various types of reports and how to write them, but also the need to understand which report fits the particular event you are engaged in, as a cybersecurity offensive security team lead or expert.
If a pentest event is conducted, and vulnerabilities are discovered, the informations are to be documented in an organized fashion, that even a non-professional is able to understand these informations documented, a professional is able to replicate the discovery, and implement the remediations, and in the case of future occurrences, the organization whose infrastructure was discovered to have these vulnerabilities in them, can consult these reports again as a reference manual in proffering solutions.
This is why, as a cybersecurity offensive team lead or member, you should understand the effective way of writing a Technical Report which focuses on Penetration Testing and Bug-Bounty program.
So, How do I write a good Technical Report as a Penetration Tester, you might ask ? First let’s define what a Technical Report is, from a Penetration Testing and Bug-Bounty perspective.
WHAT IS A PENETRATION TESTING AND BUG BOUNTY REPORT?
“A Penetration Testing or Bug Bounty report, is a technical report which contains a detailed description of a pentesting event carried out in an organization infrastructure, the procedures and order which these activities were carried out, the vulnerabilities or weakness discovered, the tools utilised during the entire process, and the possible remediations or mitigation plans, to address these security weaknesses or findings.” – Fixitgearware Security 2024.
HOW TO WRITE AN EFFECTIVE PENETRATION TESTING OR BUG BOUNTY REPORT:
Penetration testing and bug-bounty reports are not as cumbersome as they are made to feel like they are. However, there is a need for a comprehensive detailed information, while ensuring these detailed information hits the bull’s eye (straight to the point).
When a penetration testing or bug bounty report is clear and concise, the entire team who have to read these reports do not only fall in Love with the written report, but also come to a better understanding that the security researcher knows what they are doing.
At FixitGearWare Security, as part of our plan in propagating cybersecurity, we have outlined with detailed examples (e.g. using SQL injection as a case study), a clean steps to write a good technical report, when conducting your Penetration Testing or Bug Bounty Event.
Good Title:
This title should bear the name of the vulnerability discovered, with a description of the component where the vulnerability was discovered, of the organization being researched on.
Example:
“SQL INJECTION VULNERABILITY FOUND IN FIXITGEARWARE SECURITY LOGIN PAGE.”
Executive Summary:
The Executive summary comprises of the key activities and findings. The information here should have a concise information of what steps was taken to detect such vulnerability. These steps is what would be part of the discussion in the recommendation.
Example:
A time based SQL injection vulnerability was discovered in the user’s login form of FixitGearWare Security. This vulnerability affected the “Users Input” field of the login form. When a simple payload “ ‘ OR IF(1=1, SLEEP(5), 0)- –” was injected, the page became non-responsive for five seconds. This indicates that I could increase the sleep time and inject the payload in the affected component, resulting to the form not being available to a legitimate user, until the time specified in the payload has expired.
List of Tools and Brief Information:
Tools used, and a brief description of what they were used for should be briefly described.
Example:
During the entire process, the following tools were used.
– Burpsuite Crawler: A feature in burpsuite pro (paid version of burpsuite), capable of crawling an entire website. This tool was developed by Portswigger.
– SQLmap: An automation tool for SQL injection commands. This tool uses various SQL injection payloads, to test the supplied target link or entry point.
– Subfinder Tool: Is a tool used in performing active and passive recon. This tool was developed by project discovery, and it is open source.
Hint: Always attach links to the tools used during the entire process.
Methodology and Approach:
Your methodology should be in a well detailed fashioned hitting the bull’s eye. Often times security researchers write a lot of jargons, which are not necessary. Remember the goal of your entire report and research should serve only three purpose:
- To be understood by both technical and non-technical persons.
- To convey the vulnerabilities discovered, and
- To provide remediation to your findings.
Hint: Always attach images, jpegs, and text files at this stage of the report.
Example:
During the process of discovering the vulnerabilities, first the tool Subfinder, was used to perform an active recon on the domain name fixitgearware.com. The entire findings where then saved into a textfile named. “fixitrecon.txt”. which is uploaded together with this report.
Upon completing the recon with subfinder, we then proceed to crawl the entire domain stored in the text file “fixitrecon.txt”, using the Burpsuite web crawler. [Always include images below]
When the crawling was completed, we filtered the domains crawled and inspected a few of them. During the inspection, we came across the login page https://www.fixitgearware.com/user-login.html and then navigated to the domain, which was then discovered to be a login page. [Always include images below].
We then decided to test a few SQL injection payloads on both the Users input field, and Password input field. Upon injecting the payload, we discovered that the User’s input field, is able to trigger the injected payload “’ OR IF(1=1”.
Once this was confirmed that the user input field was vulnerable to SQL injection, we proceeded to automate the process using SQLmap.
Attack Vector:
The attack vector should describe the path or a step-by-step by which the attack was conducted.
HINT:
Attack vectors varies and are dependent on the type of vulnerability. For example, the attack vector for SQL-Injection, is not the same as that of XSS (Cross-Site Scripting Vulnerability).
Example:
- The domain “fixitgeaware.com” was picked from the organization official website.
- An active recon was performed using subfinder tool, and the result was saved as “fixitrecon.txt”
- The result which is stored in the “fixitrecon.txt”, is then uploaded to Burpsuite Pro.
- Upon a successful upload, the Burpsuite-Crawler was used to automate the entire domain list crawling.
- The target endpoint https://www.fixitgearware.com/user/login.html, was selected from the results.
- The payload “’ OR IF(1=1”, was injected into the user input field of the form. [Always include images below]
- Then we proceeded to automate SQL injection on the form using the code below:
sqlmap -u “https://www.fixitgearware.com/user/login.html” –data=”username=admin&password=admin” –level=3 –risk=3 –batch –dbms=mysql –technique=B
Detailed Findings:
This segment of the report should contain a detailed discovery of the vulnerability.
Example:
Upon injecting the SQL codes using the SQL injection automation tool, and heading back to the browser to refresh the domain
https://www.fixitgearware.com/user/login.html, we discovered that the browser keep returning information stating there was “An error in connection”. This lasted for a period of 5-secs. We then reviewed the SQLmap scan results and discovered that a specific payload was able to trigger the SQL injection. To confirm the validity of this payload, we then proceeded to increase the time to 10-seconds and discovered that the domain once again timed out for a period of 10-seconds. Each time we increase the time duration of our payload, we discovered that the connection remains unavailable for the time duration specified in the payload. [Always include images below]
Proof of Concept:
The proof of concept should be the codes that is used to exploit the target. It is important to note that this may vary, as it is dependent on the type of pentesting, or vulnerability assessment being conducted. For instance, the POC for XSS, wouldn’t be the same as the POC for a CIDR hacking using meterpreter.
Example:
The proof of concept for the time based SQL injection on the user-input field of the domain https://www.fixitgearware.com/user-login.html, is shown below:
CVSS Score reference documentations:
The CVSS Score rating should follow the appropriate database naming conventions of the NVD (National Vulnerability Database). The NVD version, and reference link, should be indicated in the report. In addition to this, always attach screenshot of the ratings, for clarity.
Example:
Calculation:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Score: 8.6
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Conclusion:
Conclude the assessment, by summarizing your findings with its impact on the organization.
Example:
This security weakness could negatively impact the organization business. In the eventuality that a malicious hacker, is able to detect this vulnerability, the malicious hacker could decide to sleep the database which this form connects to, for a long period of time.
Subsequently, rendering the service (the login form), to be unavailable to the organization’s legitimate user.
Remediation:
This part is very important. Often times pentesters or bug-hunters, copy generic information which are unrelated to the specific POC. Just because a vulnerability talks about XSS, does not mean you should lift content on XSS remediation and append it into your report.
Your remediation should be tailored towards the filter bypass used in exploiting the target.
Example:
For this vulnerability, we would be proffering two remediations:
- White*list Users Input:
Ensure that all users input are filtered, and the user login input field, should only validate acceptable inputs.
- Escape All Users Input:
All inputs, entered by the user in the username input fields, are to be treated as data and not executable code. This can be achieved, by escaping the characters found in the information entered by the user, in the username input field.
Other References:
References although constitute of materials consulted to write the report, at FixitGearWare Security, we go a bit further, by adding links of notable and reliable resources, that have been compromised, using this vulnerability methodology.
This is done, to draw the attention of the organization being tested, on the devastating impact of the vulnerability being reported.
Example:
- Time based SQL impacts organizations 1.
- Time based SQL impacts organizations 2.
- CVE organization report on Time based SQL.
- Other references sample 1.
And with this, we have concluded the steps on how to write an effective technical report on penetration testing and bug-bounty. Thanks for reading.
“Watch a Complete Video with a Detailed example on How To Create a Pentest and Bug-Bounty Report.”
Put your comments below in the comment section on your thoughts about this.
Find this article and information helpful? Show some love and support “Click-Here”
