Good blog read from pentesterlab.com about retesting in regards to pen tests and report writing. I like the points made about keeping detailed notes, from keeping Burp requests and application-specific output/input to keeping tool-agnostic notes and recreation steps so someone with their own tools can quickly verify/validate.

During my time in the PWK labs, note-taking was highly important. Most of the time, it is done in order to reroot a box later on or to provide detailed information for the lab report that can accompany the exam report. I approached my reports with a few goals.

First, I wanted to be able to follow my own notes to re-root a box 2 days or 2 months from the time those notes were taken. I did end up redoing every box in the labs at least once through my notes alone. Second, I want there to be enough detail to create whatever report I need to create, or help those who have questions about a box in my social media circles. Third, I wanted to create a report that I would be just as good giving to a client as to the OffSec admins for grading. And part of that is making sure that next year when the test is repeated (either by me, a teammate, or a competitor), validation can be done quickly and accurately.

As a consumer of pen test reports, I really want to be able to understand the issue, which requires giving me very clear notes and evidence. And hopefully enough information that I can verify the issue, and validate a fix post-implementation. I also want to make sure my non-technical boss can consume the issue using summaries and higher level language for impact and criticality.

Heck, pen testing isn’t the only place I practice this. During my many years of being a systems admin doing support tickets, I try my best to put as much detail into tickets as I can. I want to make sure if I need to check the ticket again in 8 months, I have everything I need without needing to respend time learning something that is hazy. I want to make sure anyone else who reads the ticket can also piece details together without spending time. And I usually want to help educate whomever submitted the ticket so they can either do better, know what to reference in the future, or maybe just have an idea of what I do for them. 🙂

This is really about three things: documentation skills, communication skills, and empathy to put yourself into a reader’s shoes.