How to write a pentest report

A few month ago i passed the eWPT exam. That is when i realized that doing a pentest report could be hard for people who just broke in to the industry.

This article will try to give some simple steps on how to write a pentest report and important elements that should be in it. It aims to give professionals new to the field some advices on how to write a report for exams or for customers. It can also be used by bug hunters (the vulnerability report part).

This article is small on purpose, i want it to be clear but not too tenuous to read as the process of writing a report can seem scary to newcomers.

Why do we need a report?

A report is the document that will present all your findings and explain to every role of the company you’ve been hired by for the mandate. It will contain the scope previously defined with your customer, high level explainations of the findings and their impact as well as precise technical descriptions of every finding. There are different parts in a report.

The Executive Summary

This is the part where you need to explain for the executive of the company who will read the report. It needs to be high level explainations with no technical details.

It is relevant to add graphs of the findings such as: Vulnerabilities by impact, Attacks by type and Vulnerabilities by cause.

The definitions on Mitre CWE can help you for defining the categories to use in those graphs.

It can comport a global posture on how the findings and attack combinaison could impact your customer’s business.
It can be also useful to include a remediation priority based on your expertise and the prior discussions you had with your customer.

The Vulnerability Report

This is the part where you present each vulnerability you found. I recommend that you order those by severity.

Each vulnerability should have a score that you can calculate using CVSS scores. Here is a calculator. This score takes in account precise metrics to generate a score as close as possible to the impact the vulnerability could have. However, depending on the context of your customer the impact might not be the same, this will be your expertise and the prior conversation that you had with your customer about their business that will help you define the impact for your customer. You don’t need to tamper the CVSS metrics, this is the goal of the remediation priority i mentioned in the previous part.

Here is a way to present it:

  • Severity
  • CVSS score
  • Affected item
  • Description: you have to explain the vulnerability and explain it in the context of your target. For example: « In the context of the support page, some checks were made on the client side, but those checks could be bypassed. »
    Feel free to add resources about the vulnerability
  • Remediation: Here you have to explain how to mitigate the vulnerability. It is always good to add resources from recognized industry standards like OWASP for web pentesting reports.
  • Evidence: Here you need to add proof of the vulnerability. The goal is that the team that will implement the mitigation is able to reproduce the attack. That is why it is important that during the attacking phase you write plenty of notes and take plenty of screens and proofs.

Note: I personaly prefer when each vulnerabilty is presented with the remediation but you can also write a remediation report part right after this.

Useful Resources

Here is a great template done by Andrew Morrison (docx and odt):

  • Pentext is a collection of XML templates, XML schemas and XSLT code, which combined provide an easy way to generate IT security documents including test reports
  • Pentest standards about reporting
  • Radically Open Security provides in their portfolio some reports of project they did. Thoses are good examples.
  • MITRE ATT&CK is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations.
  • CWE is a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.
  • OWASP list of vulnerabilities (for web pentesting)
  • Exploit db is a great resource for exploitation
  • National Vulnerability Database by the US CERT

OWASP Latam Tour: 24th of May 2019

 I was invited by OWASP Latam Tour to talk about self studying in Cybersecurity

You can see my slides here:

OWASP Latam Tour

OWASP Latam Tour (glissé(e)s) 1
OWASP Latam Tour (glissé(e)s) 11
OWASP Latam Tour (glissé(e)s) 16
OWASP Latam Tour (glissé(e)s) 13
OWASP Latam Tour (glissé(e)s) 15
OWASP Latam Tour (glissé(e)s) 12
OWASP Latam Tour (glissé(e)s) 10
OWASP Latam Tour (glissé(e)s) 7
OWASP Latam Tour (glissé(e)s) 14
OWASP Latam Tour (glissé(e)s) 8
OWASP Latam Tour (glissé(e)s) 9
OWASP Latam Tour (glissé(e)s) 6
OWASP Latam Tour (glissé(e)s) 2
OWASP Latam Tour (glissé(e)s) 3
OWASP Latam Tour (glissé(e)s) 4
OWASP Latam Tour (glissé(e)s) 5
OWASP Latam Tour (glissé(e)s) 1 OWASP Latam Tour (glissé(e)s) 11 OWASP Latam Tour (glissé(e)s) 16 OWASP Latam Tour (glissé(e)s) 13 OWASP Latam Tour (glissé(e)s) 15 OWASP Latam Tour (glissé(e)s) 12 OWASP Latam Tour (glissé(e)s) 10 OWASP Latam Tour (glissé(e)s) 7 OWASP Latam Tour (glissé(e)s) 14 OWASP Latam Tour (glissé(e)s) 8 OWASP Latam Tour (glissé(e)s) 9 OWASP Latam Tour (glissé(e)s) 6 OWASP Latam Tour (glissé(e)s) 2 OWASP Latam Tour (glissé(e)s) 3 OWASP Latam Tour (glissé(e)s) 4 OWASP Latam Tour (glissé(e)s) 5

Compte rendu de notre visite à la rencontre OWASP France

Le 4 avril nous sommes allées ensemble au Meetup d’OWASP France.
Différents sujets on été abordés et des groupes de discussions ont été proposés. Les membres du WoSEC Paris se sont joint à l’atelier ou il était question d’agilité dans la sécurité.
Le prochain meetup ou nous nous rendrons à plusieurs sera celui des cyber rencontres de Orange.
Retrouvez toutes les prochaines rencontres ici: https://www.meetup.com/fr-FR/WoSEC-Women-of-security-Paris/