8 May 2022

Using Wireshark to Troubleshoot Exploits

Wireshark has many use cases that are not only limited to networking. One example is using it to troubleshoot exploits, which makes it a useful addition to a pentester's toolset. This post will demonstrate how to use Wireshark to troubleshoot a phpMyAdmin remote code execution exploit (CVE-2018-12613). Burp Suite can also be used to troubleshoot exploits and this has been covered in a previous post.

We start by running the exploit without any parameters to identify its usage and required parameters:

Exploit usage

All of the above parameters are required to run the exploit. We will be running the exploit against a vulnerable instance of phpMyAdmin (, which is running version 4.8.1.

phpMyAdmin login page

The phpMyAdmin instance is using the credentials root:P@ssw0rd, which we provide to the exploit and then run it:

Exploit fail

However, in the above screenshot, the exploit returns the message: Unable to find the version and was not successful as it did not return the output of the whoami command. To troubleshoot this, let's use Wireshark to view the network traffic that is sent by the exploit. We start a live capture using Wireshark and add the filter tcp.port == 8080 to only show phpMyAdmin traffic. Next, the exploit is rerun again with the same parameters as before and the phpMyAdmin traffic now appears in Wireshark:

Wireshark live capture

We also see a GET request that was made to /phpmyadmin/index.php. Let's view the related packets by right-clicking on the request and selecting Follow > HTTP Stream:

Wireshark HTTP stream

Here we can see that an HTTP 404 status code was returned in the response:

HTTP 404 response

This suggests that the /phpmyadmin/index.php path does not exist on the server. Relooking at the phpMyAdmin instance path and the path provided as an argument to the exploit, we can see that they don't match:

phpMyAdmin path

Exploit path

So it looks like the path provided to the exploit was not correct. We set the exploit path to /index.php and rerun it. The exploit now runs successfully and we can see the output of the whoami command that is www-data:

Exploit working

Though this example may seem contrived, it highlights an important aspect of exploits: the output returned by a non-working exploit may not always point to the underlying issue. This is where being able to view the network traffic that was generated by an exploit with Wireshark can help facilitate troubleshooting. This is because it may include useful information that may not be found in the exploit output on the command line.

tags: oscp penetration testing wireshark