You've cruised through your latest assessment and cracked your customer's defenses with an intricate attack path. You rooted their webservers and snagged access to a Domain Admin. Now it's time for the real fun to begin:
Writing a penetration testing report to summarize your actions and findings.
Oh, you got so wrapped up in moving deeper that you didn't take notes and screenshots along the way?
It’s okay, this post has you covered. Keep reading if you’re new to writing reports, want to level up your documentation process, or are just looking for a sample penetration testing report for inspiration.
A real-world example of a penetration testing report created by the HTB Academy team. Use it as a template for your next report!
Following a security test, a penetration testing report is a document that outputs a detailed analysis of an organization’s technical security risks. It covers many facets of an organization’s security posture, such as vulnerabilities, high-low priority concerns, and suggested remediations.
Penetration testing reports are also a key part of maintaining regulatory compliance such as HIPAA, ISO/IEC 27001, PCI DSS, etc. This helps an organization or business prove that it takes serious measures to protect its infrastructure and any sensitive data it holds, which in turn bolsters product security and customer trust.
Hence I always say that proper reporting and documentation are what separates Script kiddies from true penetration testing professionals.
Decimating a network’s defenses alongside our team members is fun. But it’s not the core reason why customers hire us to hack them. When undergoing penetration tests, what clients really want is an assessment or penetration testing report to provide them with a snapshot of their environment, its defenses, and their preparedness to deal with threats at that moment in time.
That information (the good and the bad) will be used to determine:
Whether you lean towards internal or external testing or are looking to become a penetration tester, strong reporting and documentation skills are vital because:
During an Internal Penetration Test at a client's headquarters, a particularly hostile network administrator was skeptical of our abilities since the kickoff call. He stated that previous penetration tests from other companies had slowed the network down massively due to inexperienced and reckless testers.
Less than 20 minutes into testing, this network admin had sent emails to the entire distribution list and came over to my desk telling me that our scans had slowed the network to a halt. Eventually, we discovered that this was caused by the debug mode being enabled on every network device, which combined with normal Nmap scans, caused slowdowns. Once this was disabled, testing proceeded without issues.
In this case, our documentation backed up our actions and forced the customer to investigate further. If we didn’t have any (or had poor) documentation, the blame could have easily been placed on us, and it could have greatly impacted the client relationship and our firm’s reputation.Ben Rollin, Head of Training Development, Hack The Box
Free course on documenting and reporting
The content and examples in this post are based on our HTB Academy on Documentation & Reporting module. Enroll in the module to master everything related to writing penetration testing reports and documentation.
Before explaining how to write effective pentesting reports and take practical notes, below are common report types (based on the main pentesting methodologies) that you should be aware of.
Black box testing reports simulate real-world cyber attacks by providing pentesters with little to no information about the IT infrastructure of a business. Penetration testers will “go in blind.” This forces them to closely follow the thought process and actions of an unprivileged attacker.
Gray box reports are a step up from black box testing reports. Instead of “going in blind,” attackers are granted some normal user-level privileges and might have some knowledge of a network’s infrastructure.
White box penetration testing involves sharing detailed information with pentesters that includes, network, system, and credential information. Testers are granted high-level privileges and are able to view source code. This helps them conduct a more comprehensive internal or behind-the-scenes assessment and report based on one specific aspect of security.
Depending on the scope, this type of report may also be considered an interdisciplinary assessment. Some application assessments and reports may only focus on identifying and validating the vulnerabilities in an application with role-based, authenticated testing with no interest in evaluating the underlying server.
Others may want to test both the application and the infrastructure with the intent of initial compromise being through the web application itself (again, perhaps from an authenticated or role-based perspective) and then escalating privileges.
This type of penetration testing report is reserved for IoT-type devices but can be extended to testing the physical security of a device shipped by the client or an onsite kiosk or ATM. Each client will have a different comfort level with the depth of testing, so it's vital to establish the rules of engagement before the assessment begins. You’ll then know how extensive your testing and reporting should be.
Make note-taking “muscle memory” and it will serve you well. The overall reporting process will become more efficient, accurate, and less prone to errors. You’ll also be better prepared to troubleshoot issues and client concerns.
Having a repeatable note-taking process will also provide massive benefits for writing penetration testing reports, taking cybersecurity courses, or completing challenging cyber labs to hone skills or pass certifications.
While no assessment, operator, or objective is the same, these tips will get you off to a strong start:
Now that we have our note-taking process down, here’s a quick overview of things to pay attention to during the testing process:
There are many ways to write a penetration testing report. Fortunately, most tests will share several key sections such as an executive summary, recommendations and remediations, findings and technical details, and finally, the appendices. These sections are the foundations of your report.
Objective: Clearly explain the risks that discovered vulnerabilities present and how they’ll affect the future of the organization if exploited.
Length: One or two pages. Anything more is not a summary, and will probably be overlooked. Being precise and concise is paramount.
Any report worth reading should include an executive summary to help non-technical leaders digest and determine strategic action based on the information in your report. This section is arguably one of the most important since it will provide leadership with a bottom line up front (BLUF) summary of what was done, where defenses excelled, and what failed to stop you, the attacker.
Keep in mind that your target audience during this part of the report are decision-makers who allocate funds to forward remediations (not technical staff who execute changes). For this reason, we want to ensure that it is easily understood and should therefore avoid using acronyms, infosec jargon, and including overly technical details.
Providing helpful recommendations such as changes to processes, hardening of application and hardware settings, and even educational solutions is a great way to finish writing the executive summary. Although, it isn't a sales pitch. So ensure that any recommendations provided are vendor agnostic.
The ultimate pentesting certification
Accelerate your cybersecurity career with the HTB CPTS: The cost-effective, hands-on penetration testing certification that’s valued by employers, prepares you for real-world environments, and gets you job-ready.
Objective: Provide the client with recommendations for short, medium, and long-term implementation that will improve their security posture.
Length: Ideally, you want to report everything to the customers, but this could become cumbersome depending on the severity of your findings. Including the findings that are of critical, high, and maybe even medium importance is a must. If you have a large number of findings, especially in the low and informational importance, it may be best to include them all in an appendix attached to the report instead of writing a 400-page report filled with extra information
This section provides the customer with a set of recommendations for their short, medium, and long-term implementation. To ensure that recommendations are effective and that risks are represented accurately, use a scoring system and classification set like the Common Vulnerability Scoring System (CVSS) or Common Vulnerabilities and Exposures (CVEs).
Just like a doctor's assessment and diagnosis of a serious medical condition, a second opinion is always useful for ensuring a high degree of accurate and effective remediations. With that in mind, relevant third-party links and resources that discuss highlighted issues are also useful to include. .
Objective: Deliver technical details of how clients can remediate the security flaws that you found.
Length: Length doesn't matter here, but want to be clear and concise in demonstrating the path you took and the actions required. Defenders should be able to replicate the attack based solely on your documentation of it. Screenshots are perfect for this purpose.
This section is written for those who will be implementing fixes based on our findings. We want to be as descriptive and specific as possible. This means providing the following information:
Write this as you go (which again reinforces the importance of taking notes). It should show your full stream of thought and actions as you progressed through the assessment.
What was your mission?
If the objective was to acquire domain administrative access or to display the ability to exfiltrate data from the customer's network, be sure to communicate that. Clearly communicating your mission is key because the technicians who read your report may not have been aware of the assessment.
Document the agreed scope to include any hosts, IP address blocks, specific domains, and/or any specific applications or hardware that was to be tested. You want to ensure that technical teams understand what resources were excluded from testing since they could be potential blind spots for them.
This is where we document how we completed our tasks or how we were rebuffed by the customer’s defenses.
Share your successful chains along with those that failed. This lets organizations know where their defenses are working, and what needs attention. These assessments are meant to provide actionable information for the customer, not a highlight reel of our skills.
We can show our methodology in detail here with the use of shell output, screenshots, and supporting documentation such as scan outputs, write-ups of Proofs of Concept, and more. Most importantly, this information should make our actions repeatable so that teams can validate and secure the issues at hand.
Objective: Deliver technical details of how clients can remediate the security flaws that you found.
Length: The more you can provide to prove your case, the better your report will be.
The appendices will hold any supporting output, screenshots, and documentation needed to provide proof of your actions and to demonstrate the potential impact your attack path had.
These can be in the form of attachments or directly included in the report. These appendices could include Bloodhound output, lists of credentials discovered and cracked, user data, NMAP scans, and anything else of note.
1. Know your audience: Tailor the different sections to the audience. For example, the executive summary is probably the only thing that executives are going to read. Keep it high level and focus on the things that impact the business and actually pose significant risks to critical systems/clients/data.
2. Take extensive notes: Include any tools or tactics that you've tried, especially those that failed. Sometimes you'll want to revisit systems after learning something new and realize that a tactic you tried previously would have worked if you had that information when you tried the first time around.
3. Simplify complex topics: Our roles as penetration testers can be highly technical and extremely complex. Nevertheless, if we can't explain something complex in a concise, easy-to-understand manner, we’ll limit our ability to help customers and provide value to our employers.
4. Collaborate when possible: Many of us will find ourselves working with a team of testers to ensure quality work. Setting up a shared space for report writing, collection of artifacts and general collaboration will ensure that everyone is on the same page. This will improve your report and the feedback you provide to your customers.
5. Proofread to protect credibility: The credibility of an otherwise strong penetration testing report can be derailed by simple errors like spelling and grammar mistakes. Use some form of grammar checking, (Grammarly is my favorite), and ideally, have another team member read it over from a different perspective.
Our end goal as penetration testers should always be to craft a story that attempts to answer all of the following important questions:
Author bio: George Bilbrey (TreyCraf7), Academy Training Developer at Hack The Box.
With fourteen years of cyber security experience spread across military service (United States Marine Corps) and private consulting, George is passionate about pentesting, ICS Security, and helping others grow and improve their knowledge by creating innovative and engaging content and supporting various non-profits helping bring security to the masses.
Outside of content creation, he's a founding member of the cyber security community The Neon Temple in Tampa Florida, and holds several certifications that include CISSP, GICSP, GCIP, and more.
You can connect with him on LinkedIn or Twitter.
