Why Going Beyond Basic Vulnerability Testing Matters 

Basic exploitation of vulnerabilities often fail to reveal the true extent of the risk they pose. A simple exploit might prove that a weakness exists, but it doesn’t fully demonstrate how damaging it could be if fully taken advantage of. The primary goal of a penetration test is to highlight the true risk a particular technology poses to the business.  

“It is not enough to simply know that a vulnerability exists – the aim is to understand how it could be exploited and how it would impact the organization’s operations, data, and reputation.” 

To accurately gauge risk, exploits should be fully weaponized during a penetration test. This approach allows testers to simulate realistic attack scenarios, offering a clearer picture of what a determined adversary could accomplish, and enabling the organization to better strengthen its defenses. 

Cross Site Scripting 

XSS is often demonstrated using alert(1), and this doesn’t illustrate what can be accomplished with the vulnerability since the risk can range from stealing cookies to phishing. If alert(1) triggers, we can weaponize the exploit by including a form that asks for a username and password and sends to a malicious server. 

Vulnerable HTML Code 

To exploit this, we insert script into the parameter text: 

The payload triggers showing the 1:

But this does not show the true risk to the remediation team. To understand the risk the exploit has to be weaponized. The following html form asks for the user’s name and the submit button sends the username to another server:

We can put this into the text parameter, this example uses Burp’s Collaborator for the listening server, and have the form injected into the page: 

When the submit button is clicked the value is sent to the listening server, in order to grab the input, the listening server could host a php file such as: 

Local File Inclusion 

Local file inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application.1 

The payload would look like: 

This would show the passwd file: 

LFI in web applications can be weaponized in different ways such as reading source code, poisoning logs, discovering secrets and API keys, or even extracting data from bash history files. Understanding these potential attack vectors is crucial for securing web applications against this type of vulnerability.

How log poisoning could be used for the weaponization? 

If the server also has ssh open, then the application can show the auth log file. When an authentication is made to the server, successful or unsuccessful it is logged to this file. The method includes console logins, ssh, sudo etc. If it is ssh and ssh in publicly accessible, we can poison the log: 

The code injected would have to be the same as the application running obviously, in this example we’re using php. The code is inserted into the page and calling the command becomes simple: 

This would run the whoami command on the server and can be used to gain a reverse shell. 

Conclusion: Weaponization = Real Risk Visibility 

Weaponizing exploits during penetration testing is critical for exposing the true impact of vulnerabilities. It’s not about causing harm it’s about helping organizations see the complete picture, enabling informed, prioritized, and effective remediation.  

At Zyston, we believe that accurate risk understanding is the first step to real cybersecurity resilience. Our approach doesn’t just highlight vulnerabilities, it helps you understand exactly what’s at stake, so you can act with confidence and clarity.