You need to be able to explain the findings, rate the vulnerabilities, and explain how the results will affect the customer in the real world. It's important that the client can understand the end report, reproduce exploitation and effectively implement remediation.Best practices:
- Rate your vulnerabilities
- Theoretical vs. Real Findings: do not mark findings as critical if they are only theoretical and have no actual known exploit available. These should still be considered findings, but with a lower rating, if I can't find any avenue to exploit the host.
- Solutions: always report a solution to the vulnerability; If you don't have a solution, help the client develop a mitigation strategy.
- Standardize all your reports by using LaTex templates or something similar.
What you should have in your report:
- Introduction/Overview: High-level description of the project, dates, and company/infrastructure being tested.
- Scope and Objective: This section should outline the IP ranges, URLs, and applications that are to be tested. It should also explain the purpose of the test.
- Deviations from the Statement of Work: Many tests have changed from the original requirements, such as having to stop testing on a host, to stop scanning, and/or make changes to the testing windows.
- Methodology: A high-level description of the testing process and standards.
- Significant Assessment Findings: This section should be dedicated to critical findings.
- Positive Observations: This part is just as important as the significant findings. No one likes to see a whole report where their company is negatively portrayed. Talking about what the company did well helps lessen the blow on where fixes need to be made.
- Findings Summary: This should have an overall view of the findings broken down by severity. The conclusion of the summary explains if the environment was found to be vulnerable for any opportunities for exploitation.
- Detailed Findings: This should include severity, vulnerability definition, issue/detailed description/risks, asset, recommendation, snapshots/logs/how to exploit walkthrough
- Appendix: Listing of all assets and ports. Additional information and snapshots.
Lastly, if you want to set yourself apart from other pentesters, try to find ways to give yourself added value that others may not offer. For example, if you are doing a PT for a large company, you can provide a simple OSINT (Open Source Intelligence) report, in addition to the final report, to describe what and who can be publicly found from the Internet. There have been times when I created scripts (Python, PowerShell, Bat) that perform checks against critical findings so that after they remediate their systems, they can just execute the script to verify.