CyberDefenders — WebStrike Lab Write Up

Scenario Overview

In this lab, we are tasked with analyzing network traffic captured in a PCAP file to investigate a suspected security breach on a company web server. A suspicious file was found on the web server, triggering an alert within the intranet. The network team captured the traffic into a PCAP file for further forensic analysis. Using Wireshark and packet inspection techniques, we trace the attacker’s actions to determine how the breach occurred, what vulnerability was exploited, and what data was targeted.

Question 1

1. Identifying the geographical origin of the attack facilitates the implementation of geo-blocking measures and the analysis of threat intelligence. From which city did the attack originate?

Since this is a web-related incident, I started by filtering HTTP traffic in Wireshark to identify external IP addresses communicating with the internal web server. Among the connections, one external IP showed repeated interactions, especially involving POST requests, which immediately raised suspicion.

After isolating that IP address, I verified that it was not part of the internal network. To determine its origin, I performed an IP geolocation lookup. The result mapped the IP address to Tianjin.

This establishes the geographic source of the attack and confirms it originated externally.

Question 2

2. Knowing the attacker’s User-Agent assists in creating robust filtering rules. What’s the attacker’s Full User-Agent?

After identifying the attacker’s IP address, I filtered traffic originating specifically from that source. I then followed the TCP stream of one of the HTTP requests to inspect the full request headers.

Inside the HTTP header section, I located the User-Agent field. This field tells us what client software the requester claims to be using. The User-Agent string revealed a Linux-based Firefox browser.

Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

This suggests the attacker was using (or spoofing) a Firefox browser running on a Linux system.

Question 3

3. We need to determine if any vulnerabilities were exploited. What is the name of the malicious web shell that was successfully uploaded?

Because the scenario mentions a suspicious file, I shifted focus to HTTP POST requests, as file uploads are typically performed using POST. We filter it with “http.request.method==POST”.

By examining the POST request bodies and following the TCP stream, I found a file upload containing the filename **image.jpg.php**. The double extension immediately stood out. This is a common bypass technique where the application may validate the first extension (.jpg) but still execute the last extension (.php).

This confirms that a PHP web shell was uploaded through a vulnerable file upload feature.

Question 4

4. Identifying the directory where uploaded files are stored is crucial for locating the vulnerable page and removing any malicious files. Which directory is used by the website to store the uploaded files?

After identifying the malicious file, I needed to confirm where it was stored and whether it was executed. I searched for HTTP GET requests referencing image.jpg.php. We filter it with “http.request.method==GET”.

The request URI revealed the directory path **/reviews/uploads/**. This indicates that uploaded files were stored inside this directory and that the server allowed direct access to files from this location.

This is a critical misconfiguration because upload directories should not allow execution of PHP scripts.

Question 5

5. Which port, opened on the attacker’s machine, was targeted by the malicious web shell for establishing unauthorized outbound communication?

Once the web shell was uploaded, I analyzed its contents within the POST request stream. We filter it with “http.request.method==POST”. The PHP payload included a reverse shell command that specified a port number.

Reverse shells work by forcing the compromised server to initiate a connection back to the attacker’s machine. The command clearly indicated port 8080 as the communication channel.

This confirms the attacker attempted to establish remote command access through that port.

Question 6

6. Recognizing the significance of compromised data helps prioritize incident response actions. Which file was the attacker attempting to exfiltrate?

Finally, I analyzed traffic following the execution of the web shell. We filter first with “http.request.method==POST”, then we follow this http stream. Attackers commonly attempt to read sensitive system files after gaining access.

Within the command activity, I found references to **/etc/passwd**, which is a Linux system file containing user account information.

Accessing this file suggests the attacker was performing system enumeration and gathering information for potential privilege escalation.

Conclusion

The WebStrike challenge highlights how a vulnerable file upload feature can quickly lead to full server compromise. A malicious PHP web shell was uploaded using a double extension, executed from an exposed uploads directory, and used to establish a reverse shell over port 8080. The attacker then attempted to access sensitive system files such as /etc/passwd for further reconnaissance.

This lab reinforces the importance of strict file validation, disabling script execution in upload directories, and monitoring outbound traffic. It also shows how structured network traffic analysis can clearly reconstruct an entire attack chain from initial access to post-exploitation activity.

CyberDefenders link: https://cyberdefenders.org/blueteam-ctf-challenges/webstrike/

written by Annisa E. Putri