This is how you can deliver true value through your pentest reports

There are only two things your client wants: how their business can be affected by impactful exploitation of a vulnerability and how they can prevent this from happening?

The Scenario

Let’s say you are hired to perform a two-week penetration testing on a client’s major web application facing the internet. They’re interested in knowing if it has any flaws that can be exploited by a malicious actor. As a plus, they want you to act as closely as possible as a real threat actor, that is, your testing will be black box .

You begin to prepare your toolbox of tactics, techniques and procedures that will fit the job’s requirements and on the agreed date you start playing with the application. Cool, here we go!

Soon the two weeks fly by and you have a reasonable amount of vulnerabilities that you were able to successfully exploit and document.

Now that you have finished the fun part, you start to put all of the findings in a report, so your client can fix the flaws as soon as possible. That should be easy to do, right? You just take each finding and put them in a table/list like format, present the PoC codes and you’re done. Piece of cake.

The problem

Now comes the day of the presentation, where you’ll be able to show off your leet skills on how you were able to bypass their WAF and how this allowed the full compromise of their Active Directory (AD) and, as a consequence, their entire environment. You showed them a nice obfuscated payload for a XXE , showed also how you used CrackMapExec to enumerate the AD and finally you presented a very nice BloodHound graph that shows all the weak configurations that you used to compromise the environment.

At the end of the presentation, the tech members, responsible for understanding the vulnerabilities so they can fix them, were stunned because they knew exactly what you had accomplished, but they started asking several questions about various parts of the process because for them it wasn’t clear how you did what you did. You tell them to look at the technical details in the report for further clarification, but you see in their faces that this didn’t help much.

To make thing worse, the C-level on the meeting, which was the guy who hired you in the first place, had a poker face that you didn’t notice at first, but soon he also started asking several questions about what you could have done with what you found. He had already read the entire report and even so, he wasn’t able to get the point you were trying to make on the presentation.

After you tried to answer questions that for you were so obvious, like “What could you have done with Domain Admin credentials?” or “What are those symbols in the payload used for the XXE?”, you go home asking yourself what went wrong. Why did they have so many questions? You thought you were going to nail the presentation.

The explanation

Now I’m going to show you why this can happen and how you can fix this problem. I’ll divide this part into two: executive and technical communication.

Technical communication

Here we have a few reasons where a situation like this can take place. The first one is about you overestimating the technical member’s knowledge of offensive security. You have to understand that our job is kind of unique, that is, we know that IT is a very diverse field; we have programmers, sysadmins, blue teamers, red teamers, tech support, printer magicians etc. The point is that everyone has a different area of study and different background. You cannot assume that every IT professional you talk with will understand 100% of what you’re saying.

To address this specific issue, there are some things you can do:

• Explain in great details everything you did. Pretend that you are talking to a child about a complex topic, so this way you can come close to have a very detailed and didactic explanation;
• Organize your exploitation flow. This is about having a nice and easy to follow a story, where you can link every single action and make them talk to each other. This way you can more easily communicate your path inside the environment;
• Everything has to have references. Remember that you cannot assume that the tech team will understand each and every term you throw at them, so make sure you include reliable sources for every claim or every term that you’ll use. This is also helpful so you can show them that you are not making anything up, everything has a reason and a proper trustworthy source;
• The recommendations are the most important part. You have to make sure they’ll get the best possible recommendation for fixing the vulnerabilities you found. And this means explaining in detail why this recommendation is the right one. Also, make sure to include the proper sources for them;
• Take a lot of screenshots, they are free! However, every single screenshot you take must have three items so they don’t turn out useless or create difficulties instead of helping:

1. Detailed description: have you ever heard the quote “an image is worth a thousand words”? This applies very well in this case because you can’t think that an image alone will be enough to explain some technique you are trying to show. So, as soon as you take the screenshot, describe it, tell what you just did and how this connects with the process;
2. Don’t take a screenshot of your entire monitor. Excess of useless information will do no help. Of course, there are situations where you will have to do this, but for most cases, you only have to capture enough to contextualize the reader and show the information you want to show. To help with this matter, it’s helpful to use a screenshot tool, like flameshot (my personal companion and recommendation) or greenshot . Both of them solve this problem for you because you can drag a rectangle on the screen to mark what you want to capture;
3. Highlight the important stuff. Speaking of screenshot tools, you can also use them to draw on your pictures with ease. There are two critical cases when you want to do this: to hide information you don’t want to show (passwords, names etc) and to point out specific pieces of information on the picture to draw the readers attention, so they don’t feel lost without knowing where to look.

I think that if you address those topics, you’ll be able to boost your technical report so your audience can better understand what you’re trying to communicate.

Executive communication

Now comes the most important part of your job: to be able to effectively communicate with the people who hired you. Remember all the questions they’ve asked you? Well, this means that they didn’t understand your language, both in the report and the presentation. Remember: they’re not technical people, they are business people. So you have to be able to speak their language if you want them to understand the importance of your findings. This means that you have to:

• Speak using non-technical terms. It doesn’t matter if you explained what an XXE attack is or that you were able to compromise the Domain Admin account. They are not interested in knowing that. What matters for them is how this can damage their business, their clients or their client’s data;
• Show real business impact. This is why they hired you in the first place. So your job is quite incomplete if you don’t show them how their business can be affected by the things you’ve found. To do that, the first thing you have to know is what’s their business about. In your first meeting, take some time to ask a few questions about what they do, how they operate and what is the most important things for them. Even if you get superficial answers, it’s better than nothing. This way you’ll be able to link everything you found to their respective business impacts. Some examples might include:

1. Client data theft (might lead to legal issues);
2. Secret theft (patents, source codes etc);
3. Employee data theft (might lead to legal issues);
4. Stock market performance might be severely affected (show some examples);

Another thing you can mention about business impact is how bad these flaws fall under the Brazilian LGPD law (or any other law regarding data protection). They can lead to huge fines and other severe consequences to the company.

• Finally, the last thing about executive communication is the writing of your report. It’s empirical that you are able to write well. Written communication is essential for the proper understanding of what you want to pass. This means that you must have good grammar skills, as well as be able to clearly communicate what you want. For this, you can always take a course in your native language or even look for some free online resources to learn and be more proficient. Remember that the best workers are known for their attention to detail, and your language and writing skills are the main tools you will use to deliver the product your client wants. And as the last point, this part doesn’t apply only to the executive part of your report. It’s needless to say that the entire document must benefit from clear and concise writing.

Conclusion

After this journey, we can clearly see that it takes so much more than being a leet hacker if you want to be a professional pentester. We can also see that all the details sum up to deliver a great final product, one that you’ll be proud of and you’ll know that your client will get the value they were expecting.

A great pentest report is the one that speaks for itself, that is, it can communicate effectively with both executive and technical audiences.