Analyze network traffic using Wireshark's custom columns, filters, and statistics to identify suspicious web server administration access and potential compromise.
The SOC team has identified suspicious activity on a web server within the company's intranet. To better understand the situation, they have captured network traffic for analysis. The PCAP file may contain evidence of malicious activities that led to the compromise of the Apache Tomcat web server. Your task is to analyze the PCAP file to understand the scope of the attack.
Easy - Network Forensics | Completion Achievement
- Given the suspicious activity detected on the web server, the PCAP file reveals a series of requests across various ports, indicating potential scanning behavior. Can you identify the source IP address responsible for initiating these requests on our server?
Looking into the Statistics > Conversations > TCP tab, we can see a single IP address starting many conversations with the same address over different destination ports, which would be clear evidence of port/service enumeration against the server IP address:
The port enumeration is confirmed by using the IP address as a display filter:
This is behavior associated with Nmap scans.
- Based on the identified IP address associated with the attacker, can you identify the country from which the attacker's activities originated?
Using online IP lookup sites, we can easily find the country of the attacker IP:
- From the PCAP file, multiple open ports were detected as a result of the attacker's active scan. Which of these ports provides access to the web server admin panel?
Going back to the Conversations screen with the display filter ip.src == 14.0.0.120, we should be able to see which ports were open based on the fact that the attacker continued interacting with them:
It seems the attacker continued interacting with the internal server through port 8080, presumably through HTTP. Did they interact with some sort of admin dashboard? Let's use this filter to find out: ip.src == 14.0.0.120 and tcp.port==8080 and http
This confirms that port 8080 was used to interact with an admin dashboard.
- Following the discovery of open ports on our server, it appears that the attacker attempted to enumerate and uncover directories and files on our web server. Which tools can you identify from the analysis that assisted the attacker in this enumeration process?
Looking at the packet info using the previous filter, we can observe a very interesting User-Agent in many of the HTTP requests:
- After the effort to enumerate directories on our web server, the attacker made numerous requests to identify administrative interfaces. Which specific directory related to the admin panel did the attacker uncover?
Using the following display filter, we will be able to see which requests from the attacker made it to the web server based on a 200 OK server response: ip.dst == 14.0.0.120 and tcp.port==8080 and http.response.code==200. If you scroll into the packets with a text/html content type, we will be able to see an interesting URI uncovered (and later exploited) by the attacker:
- After accessing the admin panel, the attacker tried to brute-force the login credentials. Can you determine the correct username and password that the attacker successfully used for login?
The following query should help with identifying how the attacker brute-forced login credentials to the /manager admin pane: ip.src== 14.0.0.120 and tcp.port==8080 and http.request.uri contains manager. In the packet details of each packet, we can see the attacker trying many common combinations of weak/default Apache credentials through the Authorization: Basic header. Eventually, the attacker successfully logged in:
- Once inside the admin panel, the attacker attempted to upload a file with the intent of establishing a reverse shell. Can you identify the name of this malicious file from the captured data?
The answer to this question can be found in the last POST request from the previous display filter by following the HTTP stream. The filename can be found in the HTTP request headers:
- After successfully establishing a reverse shell on our server, the attacker aimed to ensure persistence on the compromised machine. From the analysis, can you determine the specific command they are scheduled to run to maintain their presence?
Looking at the packets right after the reverse shell was uploaded will reveal how the attacker interacted with the shell and how it appears in network traffic. We can use this query to focus on the communication between the attacker and the web server only: ip.src== 14.0.0.120 and ip.dst==10.0.0.112.
The attacker has successfully started a reverse shell and they're sending data through TCP. Let's use this display filter to focus on these specific exchanges: ip.src== 14.0.0.120 and ip.dst==10.0.0.112 and tcp.port==55162. After some scrolling through the packets, we will find a command to maintain persistence through cron in packet 20666 (the whole TCP stream is tcp.stream==9461).
