It has been a while since I last wrote a learning the ropes 101 post, and for that I'm sorry. Having spoken to quite a few folks about reporting recently, I felt it's only right to put together a post describing how to write a pentest report or if you're on the receiving end of your first pentest report, how they are usually structured. I've covered reporting before here & here however both were geared towards bug hunting, while useful to understand the core concepts of a good report they do not cover a proper penetration test report.
A penetration test report is more often tailored to multiple reading groups and as a result needs to be broken down into multiple sections for easier digestion by the business. The typical readers tend to be C-Level executives, Technical managers, project managers, developers and IT folks.
A report is usually constructed of three parts (this is a rough guide, all companies do reporting slightly differently).
- Executive Summary also referred to as management summary
- Technical Summary
Breaking down the reporting sections a bit; when writing, I personally write the above in reverse order. Starting with findings, then technical summary and finally executive summary. This is based on having completed the findings it is easier to then convert what was found to content that is easily digestible by a non-technical reader.
It is important to factor in the target audience and how much time they're likely to be able to spare to read the report, this is just as important for digesting your first pentest report as it is writing one!
If you are reading this as you have or are about to receive your first technical pentest report then the following subsections detail where each section is relevant to the business and how sections can be ingested.
- Chief Executive Officer(CEO)/Managing Director/Board Director: Usually have minimal time on their hands and as a result will probably not read beyond page 1. For this reason they will need a visual representation of findings to indicate the areas where they need to invest in, immediate risks to the business and any impact to operations of the business. Additionally they may need to summarise the findings and report back to their board, therefore concise findings that detail impact in the executive summary are important.
- Chief Technical Officer (CTO) - As this role is usually a bit more technically understanding they will probably get to page 3, they may skim read any critical vulnerabilities to get a feel for what level of effort is required and any graphical presentation of results. Their main priority is to know what action to take in the business and where: are there issues with developers (in house or outsourced), network team or hosting partners or network kit, how will this impact the business and do they need to ask for more budget from the CEO/CFO/Board?
- Chief Information Security Officer/Security Manager - In bigger organisations may not have time to read the entire report but will read the business and technical summaries, therefore the first two sections need to detail the impacts in a manner that is understandable and actionable. In smaller companies the CISO will likely read the entire report minus the tail end of lower risk vulnerabilities, they will need technical detail and remediation advice. Details of the overall trends observed during the engagement that will enable them to present results to the risk committee and executive board.
- Devops/Developers/IT Network folks i.e the front line techies - Will read the vulnerabilities and findings that they have been told to fix, the findings section for them will need clear details on how to reproduce, a recommendation and references that will enable them to deploy a fix for said issue.
Writing the Report
Now we understand our target audience it is time to have a look at what each section might look like and what level of depth each should go into when writing the report. As I said above this is in reverse order and how I would approach it based on experience working with different consultancies each company will do it slightly different.
When you are describing your findings for the report there are key areas that should be included.
Specifically there should be a short description of the issue identified explaining how it impacts the affected host/application/area then detailing how that is a risk to end users or interactions.
Findings should also include where possible evidence such as screenshots, photographs, output that can be read clearly outlining the issue or other documentation. As with all things when it comes to reporting every person and company will do it slightly different. However, the technique I learned back when I was doing a forensics degree and backed up by my mentor; Paul Ritchie was:
Introduce the finding, explain what the issue is where it is located and how to reproduce it, show evidence regarding the finding document multiple steps to reproduce in a clear manner to enable the client or another tester to reproduce the issue. More evidence is always better than less and providing steps that are understandable is key!
An example finding write up is shown below to allow you to better understand how to represent information, here is a write up of an exposed telnet management interface. It is purely fictional but gives an overview of what a finding may look like in a penetration testing report. The IP address used is
127.0.0.1 for illustration purposes and a false organisation called ZSEC Industries.
Infrastructure testing identified that ZSEC Industries were exposing administrative management services. These services were not limited through strict access control and allowed anyone to connect and attempt to login.
Administrative interfaces are a major target for external attackers as they may enable the attacker to gain full compromise of the application or the underlying infrastructure with a valid set of credentials.
It was found that the services included telnet and file transfer protocol(FTP) which transmit data in clear text between the client and server. It would therefore be possible for a suitably placed attacker to intercept the data and derive the credentials. Usually at an internet service provider level or on the same network if on the internal network, this especially becomes a problem when there is a flat network structure in place.
Of further concern, was that host did not require a username to be supplied to login. This increases the chances of a successful brute-force attack. The following output from the telnet command details a connection to the service:
[email protected]:~/zsec$ telnet 127.0.0.1 9999 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. *** Lantronix UDS2100 Device Server *** MAC address 00AABBCCCCEE Software version V126.96.36.199 (060719) Password :
The services were found to be vulnerable to brute force attacks. These attacks are common vectors against Internet exposed interfaces and a number of tools can be used to automate these activities. If an attacker could successfully obtain credentials through this method, they would have control of the application in the context of the compromised user.
The consultant was able to successfully brute-force access using a tool called hydra which carries out various brute-force attacks with a supplied wordlist:
hydra -P 500-worst-passwords.txt 127.0.0.1:9999 telnet
It was found that the password was within the 500 worst passwords list which granted the consultant administrative privileges on the device:
[email protected] > whoami
The affected system was:
- 127.0.0.1 - localhost - 9999/tcp
It is recommended that all management services utilise stricter access control to limit access to only those IP addresses or users that are required. Access control lists should be used to specify only specific source addresses, where possible. All management services, whether exposed or not should protect client communications through cryptographic technologies, included in protocols such as HTTPS and SSH.
- Lantronix Security Material - https://www.lantronix.com/solutions/security/
- Access control lists explained - https://www.computernetworkingnotes.com/ccna-study-guide/access-control-list-explained-with-examples.html
Once you've completed your findings write up it can be very useful to produce a technical summary. The aim of this is to give the reader a quick reference to the issues identified, what their risk rating is and an overview of how to remediate them. As mentioned in the target readers section this will be most likely read by technical C-level staff and technical managers, it may also be read by front line techie team leads who need to distribute sections of the report to their team.
Often this can be represented in a table or a few short paragraphs that dive into more technical detail than the management summary. The primary focus of this summary should be around highlighting the points of interest and requirements for remediation that can be understood by a technical audience.
An example technical summary built from the tech findings discussed above:
The testing against ZSEC industries found that there was a large number of issues that affected the external infrastructure. During this period of testing, there were three (3) high-risk, one (1) medium-risk, and one (1) low risk vulnerabilities identified.
A summary of the issues identified is shown in the following table:
|Vulnerability ID||Issue Title||Affected||Recommendation||Risk Rating|
|H1||Exposed Administrative Interface||127.0.0.1:23||Restrict access based on source IP range||High|
|H2||Oracle EBS Server Side Request Forgery(SSRF)||127.0.0.1:8090||Update the install to latest version||High|
|H3||Open Mail Relay Allowed||127.0.0.1:25||Configure SMTP server so that the mail relay parameter only sends mail from known domains or IP addresses||High|
|M4||Exposed SVN Repository||127.0.0.1:80/.svn/||Remove access or restrict access based on access control lists||Medium|
|L5||DNS Cache Poisoning||127.0.0.1:53||Restrict access to the DNS server’s cache to only local user only||Low|
Once you've written out all of your findings in technical form, the next area to write is the management summary. The summary is generally going to be read by a non technical audience. I always refer back to a phrase that @CornerPirate coined; #TeachGranny. Take everything you're about to explain in the management summary and try to explain it in terms that your granny could understand.
The language in the summary should focus on the risks to the business, why should the reader care about the issues what quantifies them as an impact to their business? In essence the exec summary is usually split up like a story would be, with an introduction, a middle (this is where you explain the risks to the client's C level) and an end, usually consisting of a conclusive summary of the fixes required. An example executive summary is shown below;
ZSEC Industries(ZSEC) contracted with ZephrSec to perform a security assessment of their external infrastructure estate. The engagement occurred during the period from 13/01/2020 and 19/01/2020. The objective of the engagement was to identify vulnerabilities in ZSEC's systems and network security that both internal and external adversaries could exploit.
During the assessment, there were three high risk issues identified, these were primarily found to affect administrative and business applications that were internet facing. An attacker could leverage the risks identified to gain access to network management interfaces which could enable them to access further systems on ZSEC's internal network. By doing so, an attacker would breach the confidentiality of information held on the system and this could have further impact on the integrity and availability of systems.
Testing has highlighted issues, mainly related to systems hardening and configuration issues; however, by remediating these issues, ZSEC will harden the security of their perimeter and underlying systems. By making some configuration changes, most of the issues identified can be resolved.
It is essential that patching processes are reviewed to ensure all servers and third party software remain updated. This process should be reviewed as patching mitigates the vulnerabilities present in older versions of the software. The recommendations found during this test should be reviewed and addressed based on the client’s internal risk rating for each issue.
Important takeaways from the above summary is to write with confidence in your findings. Also provide advice that is actionable for the board or non-technical users, try to avoid acronyms where possible and overly verbose language.
Tying Everything Up
Once you've written your report, you should have an executive summary, a technical summary, some findings and depending on those findings potential appendixes detailing more information on said findings. Most organisations will have a quality assurance (QA) process whereby the report is reviewed for any technical inaccuracies and grammatical errors.
Typically this is done by two separate people to account for any potential oversights and help tidy up the report for delivery so that the final product is error free and reads well.
Whether you're writing or receiving a report be it your first or five thousandth report, it is important to take care of each. If you are on the receiving end most times it should be pretty straight forward to digest each segment of the report and sufficiently segregate the sections between relevant teams in your organisation.