Examine network traffic with Wireshark to investigate web server compromise, identify SQL injection, extract attacker credentials, and detect uploaded malware.
Introduction
I want to focus on my Wireshark skills a lot more in the coming months. I have a lot of experience with Microsoft’s KQL and using that to dig through network traffic, but that only happens after it comes through a SIEM or EDR tool before. I like to know how to analyze network traffic from the ground up, so you’ll be seeing a lot more Wireshark in the future!
For todays lab I’ll be going through the Web Investigation Lab by CyberDefenders. I like their scenarios quite a bit as they’re less focused on Red Teaming like many other online platforms.
You are a cybersecurity analyst working in the Security Operations Center (SOC) of BookWorld, an expansive online bookstore renowned for its vast selection of literature. BookWorld prides itself on providing a seamless and secure shopping experience for book enthusiasts around the globe. Recently, you’ve been tasked with reinforcing the company’s cybersecurity posture, monitoring network traffic, and ensuring that the digital environment remains safe from threats.
Late one evening, an automated alert is triggered by an unusual spike in database queries and server resource usage, indicating potential malicious activity. This anomaly raises concerns about the integrity of BookWorld’s customer data and internal systems, prompting an immediate and thorough investigation.
As the lead analyst in this case, you are required to analyze the network traffic to uncover the nature of the suspicious activity. Your objectives include identifying the attack vector, assessing the scope of any potential data breach, and determining if the attacker gained further access to BookWorld’s internal systems.
Quite a lot of text for the scenario introduction. Not that I’m complaining that much, I love a good story.
The final paragraph breaks down the objectives for this lab. We should be able to achieve all of this through Wireshark. Like I mention above, I’m trying to focus on honing my Wireshark skills, so being able to complete a lab entirely through Wireshark will be exactly what I’m looking for. The scenario introduction seems to indicate that Wireshark is all we need, more on that soon.
For now we can download the lab files, unzip it, and open up WebInvestigation.pcap with Wireshark to get started!
Question one
By knowing the attacker’s IP, we can analyze all logs and actions related to that IP and determine the extent of the attack, the duration of the attack, and the techniques used. Can you provide the attacker’s IP?
From the scenario introduction text we know that the ‘BookWorld’ database triggered an alert after a spike in activity. We can infer that querying the database isn’t unexpected by itself, but a spike in requests is indicative of something going wrong. I put together a quick wireshark filter to just see any successful (200) requests: http.response.code == 200.
It’s not pretty or fancy by any means, but the filter does get us the answer. The filtered results shows 133 packets. Scanning down through the results shows one IP address showing up 108 times. This is the IP address that caused the spike in queries, and is our answer.
Question two
If the geographical origin of an IP address is known to be from a region that has no business or expected traffic with our network, this can be an indicator of a targeted attack. Can you determine the origin city of the attacker?
I said up top that I’d come back to whether Wireshark is all we would need to complete this lab. Seems like that is not the case.
There are a few different ways that we can get the geolocation of the IP address. Personally I wrote my own tool to do this from the command line using the APIs from ipinfo, VirusTotal, and AbuseIPDB. I wrote it just to save time in bulk-searching for whether an IP has been reported before, but it’s also been useful in tracking where an IP could possibly be located.
For this lab I used ipinfo, and quickly found the city. Bit of a shame that we’re already leaving Wireshark by question two, but it’s nice practice anyhow.
Question three
Identifying the exploited script allows security teams to understand exactly which vulnerability was used in the attack. This knowledge is critical for finding the appropriate patch or workaround to close the security gap and prevent future exploitation. Can you provide the vulnerable PHP script name?
Back to Wireshark for this one, yay!
I wrote a quick filter that shows us all packets from the malicious IP, where the protocol being used is http. Like before this isn’t anything groundbreaking, but it removes the tcp and other noisy packets that may slow us down a little. Here’s the filter I used: ip.src == 111.224.250.131 && http.
If you look at the ‘Info’ tab you can quickly see what the attacker was doing (if sorting by packet number). They first go to what must be the homepage, seen by the style.css, favicon.ico, and index.html resources being retrieved. After that it seems that the attacker focused entirely on the search.php page. Jumping ahead a little, it does appear that SQL Injection attacks took place using this PHP script. We’ll touch on those later on, for now we can move on to the next question.
Question four
Establishing the timeline of an attack, starting from the initial exploitation attempt, what is the complete request URI of the first SQLi attempt by the attacker?
Note: Decode the Value.
After the initial connections you would expect to see when someone requests a web page we can start to see what the attacker is actually searching for. After searching for 'test+test', 'war', and 'book'. we see a weird change in the Request URI: /search.php?search=book%27.
This is a URL Encoded string. It will decode to 'book '. Note the trailing space. This is not malicious and won’t cause any errors, but it could be considered a form of Active scanning (T1595) wherein the attacker is actively checking if the search page is decoding the encoded search parameter.
This is not our answer, we instead need to look for a Request URI that is actively exploiting this (and running an SQL Injection). We can find that in this Request URI: /search.php?search=book%20and%201=1;%20--%20-.
Note that for the answer we need to decode this command. You can do this using Cyberchef, or by hand if you really want to flex.
Question five
Can you provide the complete request URI that was used to read the web server’s available databases?
The first hint for this question gives us a nice clue as to what we should search for:
Look for requests containing database-related keywords like INFORMATION_SCHEMA, which often signify attempts to enumerate database details.
I wrote this filter to check for any URI that contained ‘INFORMATION_SCHEMA’. ip.src == 111.224.250.131 && http && http.request.full_uri contains INFORMATION_SCHEMA. This can be refined down to ip.src == 111.224.250.131 && http.request.full_uri contains INFORMATION_SCHEMA, as specifying that we’re only looking for packets using http is superfluous.
We’ll find our answer in packet number 1520. Remember to decode it!
Question six
Assessing the impact of the breach and data access is crucial, including the potential harm to the organization’s reputation. What’s the table name containing the website users data?
We’re just over halfway done with this lab. I’m already quite happy with how much Wireshark we’re using.
We need to change up our filter a bit here. Previously we have been looking at what requests the attacker has been sending to the web-server, but now we need to look at what the attacker has been receiving. I changed it up a little to the following: ip.dst == 111.224.250.131 && http.request.full_uri contains INFORMATION_SCHEMA. The only real difference in this filter to the others is that instead of filtering for the attacker IP being the source, we have changed it to the destination.
With the (decoded) SQL query /search.php?search=book' UNION ALL SELECT NULL,CONCAT(0x7178766271,JSON_ARRAYAGG(CONCAT_WS(0x7a76676a636b,table_name)),0x7176706a71) FROM INFORMATION_SCHEMA.TABLES WHERE table_schema IN (0x626f6f6b776f726c645f6462)-- - the attacker has recieved the following array containing the tables available to them: ["admin", "books", "customers"]. The answer should be pretty obvious!
Question seven
The website directories hidden from the public could serve as an unauthorized access point or contain sensitive functionalities not intended for public access. Can you provide the name of the directory discovered by the attacker?
Another pretty simple filter will help us out here: ip.src == 111.224.250.131 && http. There are 41685 packets shown here, but bare with me as I walk you through how easy these are to parse.
Starting around packet number 1685 you’ll see any GET requests to search.php cease. No more SQL Injections are being performed, and it appears that the attacker is now running a directory scan. In fact we can confirm this is being done, as the User-Agent tell us exactly what tool is being used: gobuster/3.6.
Gobuster is a neat little bruteforcing tool. I’ve used it a few times as you can probably see in previous posts. It made me smile a little when I first figured out what tool the attacker was using. It then makes sense why there are so many packets after this. Gobuster is trying every single URI in a wordlist, I suspect rockyou, which creates a lot of noise.
We can scroll all the way down to the bottom (if you’re viewing the packets in order) and see what the attacker does once Gobuster has completed. After a GET request to /zt.js, which would be at the bottom of the wordlist, you can see that the attacker starts to manually target a directory. We know that this was manual, as the User-Agent changes from Gobuster to Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0.
Question eight
Knowing which credentials were used allows us to determine the extent of account compromise. What are the credentials used by the attacker for logging in?
The attacker will be logging in to the hidden urls they found in the above question. We know from the wording of the question that they’ll be logging in, meaning that they’re sending a POST request.
We can use this filter: ip.src == 111.224.250.131 && http.request.full_uri contains "admin" && http.request.method == POST.
Fairly self-explanatory, but we are looking for the attacker IP sending a POST request to the admin URI, this returns 8 packets for us to investigate. Looking at the HTML Form information contained in the packet, we can see the credentials that the attacker attempted against the admin endpoint they found earlier.
The attacker tries four credentials. Three of these return a 200 and give a ‘Invalid username or password’ message (Follow the HTTP stream to see this). The last credential is successful and returns a 302. Check the HTML Form information to see the credentials!
Question nine
We need to determine if the attacker gained further access or control of our web server. What’s the name of the malicious script uploaded by the attacker?
The same filter that we used in question eight will give us the answer for this question as well. We are looking for the mime_multipart form data, specifically the application/x-php part - Content-Disposition: form-data; name="fileToUpload"; filename="NVri2vhp.php"\r\n. This shows us the .php file that was uploaded by the attacker, and our final answer!
Conclusion
When I got to the second question I was worried that this was going to be another lab tagged with Wireshark when in reality we only used it for one question. Thankfully we went right back to Wireshark afterwards! In a lab where every other answer can be found in Wireshark, question two stands out as being a bit odd.
In saying that, it’s nice to keep in mind where an attack is coming from. If a known location (like another office) is performing gobuster scans on your internal network then you should immediately on alert for a user being compromised, or even an inside risk. For this lab we found out that the attack was being performed from China, so we can safely assume this was an external attacker.
Overall another neat little lab. More Wireshark coming soon!