Penetration Testing with Kali Linux OffSec

Table 1 - Findings and Recommendations 
It’s important to understand that what we identify as the severity of an issue based on its 
vulnerability score is not context-specific business risk. It only represents technical severity, even 
if we adjust it based on likelihood. We can reflect this in our findings as technical severity, or we 
can work with the client’s risk team to gain an understanding of the appropriate level of business 
risk by including consideration of the unique business impact to the client. 
We can start our findings description with a sentence or two describing what the vulnerability is, 
why it is dangerous, and what an attacker can accomplish with it. This can be written in such a 
way to provide insight into the immediate impact of an attack. We then describe some of the 
technical details about the vulnerability. There is often no need to go into overwhelming detail; 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
109 
simply explain at a basic level what the vulnerability is and how to exploit it. The intention is to 
describe a complex exploit in a way that most technical audiences can understand. 
We also need to include evidence to prove the vulnerability identified is exploitable, along with any 
further relevant information. If this is simple, it can be included inline as per the first entry above. 
Otherwise, it can be documented in an appendix as shown in the second entry. 
Once the details of the vulnerability have been explained, we can describe the specific finding that 
we have identified in the system or application. We will use the notes that we took during testing 
and the screenshots that support them to provide a detailed account. Although this is more than 
a few sentences, we’ll want to summarize it in the table and reference an appendix for the full 
description. 
It’s good practice to use our notes and screenshots to walk the reader through how we achieved 
the result step-by-step. The screenshots should contain a short explanation of what it shows. We 
should not rely on the screenshot to speak for itself. We should present the impact of the 
vulnerability in a way that frames its severity for the client in an appropriate manner, and is 
directly relevant to the business or application. 
The remediation advice should be detailed enough to enable system and application 
administrators to implement it without ambiguity. The remediation should be clear, concise, and 
thorough. It should be sufficient to remove the vulnerability in a manner acceptable to the client 
and relevant to the application. Presenting remediation that is excessive, unacceptably costly, or 
culturally inappropriate (e.g. not allowing remote logins for a remote working environment) will 
lead to the fix never being implemented. A strong understanding of the needs of the client is 
necessary here. 
There are several other important items to keep in mind. First, broad solutions should be avoided, 
in favor of things that drill down into the specifics of the application and the business. Second, 
theoretical solutions are not effective in combating a vulnerability. Make sure that any solution 
given has a concrete and practical implementation. Finally, do not layer multiple steps into one 
proposed solution. Each distinct step should be its own solution. 
The Technical Findings and Recommendations section will likely be the major part of the report 
and the time and effort invested in writing it should reflect its importance. 
In describing the findings, we will present the means of replicating them, either in the body of the 
report or in an appendix. We need to show exactly where the application was affected, and how to 
trigger the vulnerability. A full set of steps to replicate the finding should be documented with 
screenshots. This includes steps that we take for granted (such as running with administrative 
privileges), as these may not be obvious to the reader. 
The details should be separated into two sections: 
1.
The affected URL/endpoint 
2.
A method of triggering the vulnerability 
If multiple areas are affected by the vulnerability, we should include a reference to each area. If 
there is a large number of similar issues, then it’s often acceptable to provide samples with a 
caveat that these are not the only areas where the issue occurs. In the latter case, we would 
recommend a systemic remediation. 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
110 
5.2.7
Appendices, Further Information, and References 
The final part of the report is the