Include Command Strings – Penetration Test Reporting Tips

John Strand[1] is fond of saying that a penetration test report is supposed to be more than just a record of how we pwned someone’s systems[2]. A good pentest report is also supposed to be a teaching tool that provides the folks on the receiving end with information that makes it possible for them to do a lot of the same things we did. There are a couple of reasons why we want them to do that.

First, if the customer for a pentest report is able to run (execute) the exact same commands on the exact same systems that we did, and if they then get the exact same results, that verifies and validates our findings. That, right there, is reputation gold!

So, how do we make that happen?

Easy. We include the exact command strings used during an engagement within the pentest report, along with the results achieved from running said command(s).

Second, once the client has made changes to implement some measure of mitigation, they can re-run those commands to see if their changes worked. That is empowerment, and when you empower your clients, you make it possible for them to do what they need to do more effectively. That makes this tactic of sharing the command strings even more amazing.

Empowering clients has another side effect. Not only does it have the potential to raise their trust in you and your findings, it helps them raise their own bar for their internal cybersecurity practices. There are other benefits, but I’ll get to those in a moment.

Some Considerations

If you are an experienced pentester, take a moment to think about how your client will feel when you hand them a manual on how to test their mitigation efforts and see for themselves how effective (or not) those efforts have been. Next, think of all the vulnerabilities you keep finding, again and again and again. What if more normal IT and internal security folks had more baseline knowledge on how to figure out whether their systems have vulnerabilities that can be found by running three or five scans using tools available natively on their systems? They don’t have to be CTF Jedi or have a dozen SANS certs to run an Nmap scan, or any one of a dozen other scans on their own systems. And by empowering them, you help them raise the bar. As we both know, it could use a lot of raising.

Now let’s flip things around.

If you are fairly new to the cybersecurity biz, think for a moment how using this tactic will reflect upon your skill, ability, and above all, attention to detail. Keen attention to detail can and will have a direct and positive impact on your career. I have seen quite a few new testers come in off a CTF, bootcamp, or mad dash to acquire every hacker certification on the planet. One thing that is guaranteed to make a good impression to clients, lead testers, mentors, etc., is when you pay that extra bit of attention and document everything clearly. Including your command strings is an easy and effective way to demonstrate your attention to detail, and your skill level. If you have been hired by a pentesting company, revealing the exact commands you used lets more senior testers see where you might need improvement. If the team you are working with is any good, the folks who have been in the trenches a while will share their tips and suggest other, possibly better, ways to run a similar test in the future. Those tips and suggestions are priceless. Take them and use them.

Various Implementations

I have seen implementations of command string inclusion used by different pentesters over the years. Before I share which ones I like best, let me describe the most common variations.

Command string shown in screenshot of shell window/interface:

Command string included within written narrative:

Command string included within written narrative, followed by a screenshot of implementation:

Command string included within written narrative with breakdown of what each switch does, followed by a screenshot of implementation:

It may be apparent that I listed the variations in order of complexity. It may also be apparent that I listed them in order of the quality of the reporting, from worst to best. The fourth option listed is, I grant, a bit over-the-top-OCD even for me, but there may be instances where that level of detail is useful for a specific client. There are, as far as I’m concerned, instances where each of these implementations is appropriate. That is where the art part of report writing comes into play.

When in doubt, I recommend rolling with Door #3, Command string included within written narrative, followed by a screenshot of implementation. Doing that provides the report reader with more context than a screenshot or the command alone would do.

It is also a good idea to create and use custom styles for any inline code or command/code blocks. Implementations I have seen typically use a monospaced font and light grey shading. The monospaced font helps the reader recognize that it is code, and the light grey shading makes the commands stand out without being obnoxious, even if the command in question is buried within a 19-line paragraph of narrative text. Once those styles are available, they can be used for inline mentions of specific commands, key/value pairs, function calls, etc.

One word of caution: If you use a non-standard font like hack[3] in your reports, there is a high probability that the reader’s system will not have that font installed. If the report is exported to a PDF, however, embedding fonts is an option that can solve that problem.

At the end of the day, the goal is to do what we can to ensure that each report provides useful and meaningful information to the client. Including the actual command strings used to execute scans, exploits, and other actions taken during an engagement may seem like a lot of extra work, but the potential payoff from including that extra level of detail will help add value to the report and make its author stand out from the crowd in a good way.

[1]. John is the Founder and owner of Black Hills Information Security, Senior Instructor Emeritus for the SANS Institute, original co-author of the SANS SEC504 course, and, whether he knows it or not, one of the folks I think of as a mentor, for me and for a lot of other people in cybersecurity.

[2]. Ok, this is a paraphrase. But you get the idea.


Leave a Reply

Your email address will not be published. Required fields are marked *