What makes a great penetration tester

Recently at a conference in Oslo, someone at a Managed Service Provider (MSP) told me they were not particularly jealous of my work. “As a penetration tester, don’t you all the time test the same systems at the same customer, finding the same vulnerabilities every year?” I answered that this is not a problem with being a penetration tester, it is a problem with not clearly communicating the risk with having a vulnerability. There might be other internal factors at the customer explaining why the problem persists, but the only influence a penetration tester can have is through the report. If the problem is severe enough, the customer should be convinced to fix it at once, or elevate it internally so that it will be fixed.

Explaining risk is a field of study all on its own. For this article, a risk consists of an asset, a vulnerability and a threat. The threat is an actor with motivation and capabilities. Penetration testing has the goal of finding risks and showing the impact of them. You convince the customers the risk is real by showing impact; what a threat actor could get out of exploiting the vulnerability. If the impact you showed last year was not enough to convince the customer, you need to work harder this year to find an angle that actually shows how bad it is.

I think that the problem of persisting vulnerabilities is a symptom of bad reporting. It is very common among penetration testers to hate reporting, and I am/have been guilty of this myself. The report should be the most important part of the assignment, as it is usually the only deliverable the customer sees from a project. It is literally what they pay for. If you hate doing what you are paid for, are you really enjoying your job?

This brings me to what your role is as a penetration tester. If all your motivation is to “hack stuff”, you are almost no better than a criminal. Penetration testing is research, and your job is being a writer. Everything you do during an assignment should reflect this. Work out from a research question that you try to answer, and split this down to actionable questions that you use to answer the greater question. These different questions can be used in your report to make it clearer to the reader what you have been doing.

For example, you are tasked with doing a “pentest on the Internet exposed services of our company”. This is not a question, and very hard to turn into actions. First, what is a “pentest”? What are the customer expecting from your research? Make some assumptions and turn it into something you can answer, for example: “How would an attacker using automated methods view the company?” Then you might split this up in to smaller, more actionable questions: “What are the exposure of the company on Shodan?” or “Which ports can an attacker find using nmap?” Maybe after reviewing the data, there’s a web application that peaks your interest. Testing this manually does not fit with your original question, but there is no problem revising the question. Ask any researcher in any field, and they will tell you that their research has sometimes taken them on paths they had not imagined.

Your report is a research paper, describing in technical detail your findings and how you came to find them. Do not spare any gritty detail, and focus on the specific vulnerabilities. Then after finishing your technical paper, write a summary that really dwells on why this is important. Here you should mention the risks, and what impact the exploitation of the attack paths you discovered is. This will be your executive summary. Some inspiration can be taken from academic research papers, and news sources’ retelling of the paper:

In 2016, researchers at LIGO released a paper that explained the first observation of a gravitational wave. Their paper is available here. Soon after, most popular media published news stories about the discovery. Here is CNN’s take on it. The difference between the popular media’s sensational telling of the story and the research paper’s sober recollection of all the data is striking. Most of you will not understand most of the research paper (I certainly do not), but the retelling clearly shows the why the result is interesting, and what it means. The how is not important. Combining these articles is what I want from a penetration test report.

Your executive summary should be sensational. “The consultants were able to use publicly known vulnerabilities to gain access to systems containing credit card information. This could result in financial liability and lost reputation. Examples of similar breaches are…” Make the readers of the summary understand the consequences of the attack, and that there are known similar breaches that they have heard of.

On the other hand, your technical report should explain clearly how you found the vulnerability, and how you exploited it. “By using the Nessus vulnerability scanner, a system vulnerable to the MS17–010 Eternalblue attack was discovered. By using the public Metasploit implementation of this exploit, access was granted to this system with Administrator access. The server is storing credit card data in a SQL database, and it was then trivial to read this data.” You should of course be even more detailed, and source any external references. Make the problem clear for the people implementing the mitigations you describe. In academic words, you should make all your findings reproducible by the reader.

This is really a point of writing the report for the whoever is reading it, which is true for any written piece. The executive summary should be written for executives. The technical part for IT staff. And the entirety of the report should be written for human beings. That means clear language that is easy to understand. Try not to say more than you have to. And revise everything you write in the report, cutting away anything that does not fit.

If we recognize the report as a more important part of the pentesting process, I hope we can make penetration testing seem more mature. And maybe this will lead to a more secure world out there. Truly, a key difference between penetration testing and criminal activity is the report. It is also the only way of convincing the customer that the uncovered issues warrants a response.

Take your job as a writer seriously. There are loads of resources for technical and non-fiction writing out there, study some as well as you would your latest exploit techniques. Anyway, the best way of getting better at writing is to write, so might I also suggest to start blogging?

If you want to discuss this or disagree with me, don’t hesitate to reach out on twitter. You could also join me, and many more fantastic people, on the BloodHound slack, where we even have a dedicated channel for reporting.

Originally published here.