We've mentioned that additional information often
needs to be supplied in a report.
There are a number of reasons for this.
Keeping the main sections of the report concise is one of them. A
bloated report can make for difficult reading and wasted time, but if
that extra detail is potentially important,
then an appendix is a good place for it.
Appendices are also good for transparency.
If there is a checklist or specific methodology being used during the test,
then adding it as an appendix is a good indication of
effort and thoroughness provided by the test. Verbose
output from tools can also appear here.
This can be very useful to help the reader see exactly what a tool is
doing, and if they need to repeat the process, then they'll be able to
compare the result in the report with the result that they got. As long
as the additional data supports the report in some way, then it can go
into an appendix.
So, in particular,
if it helps to detail the vulnerabilities, state, or at least
assist with the mitigations or highlight the risks,
then it can be added.
Looking at Kim's report, we see the first appendix
is the result of the port scans.
You can see a link to the tool that was used, Nmap in this case,
and the exact command used too. That should make it easy for
someone else to perform this exact same scan.
It helps repeat the process and potentially with mitigation too.
The example we see here has been truncated simply for use in this course,
but in reality, it could contain hundreds or even thousands of
lines. If there really is a lot and you really think it's
going to be useful to the reader, then it may be worth using a separate document.
Additional documents can go to the technical teams without
having to go to the non‑technical people. For something like
Nmap scans, a spreadsheet might be useful.
Another appendix here is showing use of hashcat to crack hashes. We've
got the commands used to do it and some verbose output. With output like
this, it's useful to highlight any important parts, so here Kim has
highlighted where the password was cracked and the time taken to do it.
In this module, we've covered a lot of the report, and most of it has a
non‑technical focus.
Pen testers are often very technical, so switching to
the non‑technical can be challenging.
This covers some very important areas for Chris, our less‑technical IT manager.
The executive summary, in particular, is critical to help the business
understand the conclusions of the test and the risks to the business.
Vincent, our technical person at Carved Rock, is also getting something from
this. While understanding the risks to the business are important to him, he's
also getting further details about mitigations and repeating the process of
testing these vulnerabilities. And that's it, that's the end of our report, but
there is still more to think about.