One of the most important things every pentester needs to do during an engagement is to document their actions, rationale, and results while they are running the actual engagement. Or, as BB King[1] is fond of saying, “Report as you go.” This seems like a really obvious thing to do, but after years of reading and editing penetration test reports from some amazingly brilliant hackers, I can absolutely testify to the fact that every one of them does fail to do so now and then, and that failure will result in a poor report at best, and a monumental problem at worst. Allow me to explain.
When you begin a penetration test (aka pentest), there are likely to be certain things you will do that you have done a hundred times before. The problem is that if you don’t document your tests while you are doing them, you may try to remember afterward what you did on the specific engagement for Company A, and you are likely to have a tough time doing so. In addition, there will be many times when you are only granted access to the customer’s systems for a limited time. Once that window closes, if you don’t have your screenshots and test results documented, you are hosed.
Since you may have run the exact same kind of network scan, web app test, or mobile device rootkit for two or three other companies since the engagement for Company A, recalling Company A’s particulars may be challenging. Also, you could easily have been working late because the customer did not want you pinging their network during normal business hours. If you are a morning person, but you had to run your scans starting at 10 PM EST, you are not likely to be at your peak performance. That can impact your memory, which means you might not remember what you did and why if you didn’t take some really good notes at the time.
All of these scenarios are very common, and by “reporting as you go,” taking really good engagement notes during the pentest itself, you can avoid some of the most common pitfalls that even experienced testers run into.
So now that we’ve established that you should be taking really good notes, and that you should include them in what will eventually be your report document, let’s touch briefly on the kinds of things you should record.
- Date and time: While working an engagement, pick a time zone and record the date and time of each action taken based on that time zone. Sometimes a tester will choose the time zone where they reside and/or are performing the test. Other times, they may use the client’s time zone. Whatever you choose, pick one time zone and use it consistently.
- Action performed: Simply put, what did you do? Did you run an Nmap NSE script, or maybe a Nessus scan? Did you employ Google dorks looking for OSINT about the company you were testing?
- Command string(s) used: This information is not only a good way to help you built your personal hacking grimoire, but those command strings can help your customer duplicate your results, or, hopefully, use the same commands to verify whether or not their mitigation efforts bore fruit.
- Rationale: Why did you perform this action? Ok, this is actually more important when you are “winging it,” or if something you did revealed an interesting vulnerability, error, or message. By sharing the “why” with your client, you help them understand better how the results mattered. Which brings me to the next item…
- The results returned: This is something that gets overlooked a lot! Let’s say that you ran EyeWitness or some other software designed to take screenshots of websites. If there were no interesting results, make a note of it and include that information in your report. If you found a login page that took default creds, make a note of that and put that in your report. If your Nmap scan returned 547 open ports on 392 servers, make a note of it. Better yet, save all the output out to files you can parse and reference later. That output should also be included as appendices or supplemental data you send along with your report.
- Screenshots: Unless you have our own personal Tardis[2], you are not going to have a second chance to take screenshots of your engagement. Take screenshots as you go, and don’t worry about taking too many of them. Better to have images you don’t use than to kick yourself later because you don’t have the screenshot you want as supporting evidence of an issue. (FYI, there is a separate post in the works on simple ways you can make your screenshots awesome. Stay tuned!)
- Known vulnerabilities or CVEs: This item can possibly wait until you are doing your formal write up, but, if during the engagement you decided to run a different kind of scan, or if the first three Metasploit exploits you ran didn’t work, but something you saw made you try Door #4 and that did work, it’s likely that you know what CVE or vulnerability was involved. Make note of which exploits you tried, what vulnerability or CVE they targeted, and anything else that influenced your decision process in that moment.
All of the above items are just suggestions, so if there are other specific items or factoids you want to keep track of, go for it. My only suggestion is that you document more than what you think you will actually need for the report. I have never yet heard a tester complain about too much documentation on a test, but I’ve heard a lot of them moan bitterly over the screenshot that got away.
To quote BB again, you don’t get paid for hacking. What you get paid for is your report.[3] And as far as the customer is concerned, if what you did does not show up in your pentest report, it didn’t happen.
So report as you go, and get lots of dough.
[1] https://www.blackhillsinfosec.com/team/brian-king/
[2] https://en.wikipedia.org/wiki/TARDIS
[3] https://www.youtube.com/watch?v=bJ4gJVXPAS0&t=2887s