Hack The Box – Marshal in the Middle (Forensics Challenge)

The security team was alerted to suspicious network activity from a production web server. Can you determine if any data was stolen and what it was?

This is a nice network forensics exercise involving encrypted traffic and data exfiltration. In addition to the usual PCAP we are also given a selection of logs from Zeek (formerly Bro) to assist with the analysis.

We don’t have a great deal of information to get guide the analysis – not even the IP address of the web server – but starting with the Zeek logs we can quickly see what ports and protocols were in use.

cat conn.log | zeek-cut id.resp_p proto | sort | uniq -c | sort -nr

We have a lot of UDP connections on port 53, and then TCP connections on port 443, and port 80, consistent with DNS and HTTP(S). However, the TCP connection on port 53 is weird; let’s dig into that a bit more, using zeek-cut and grep to filter the uid associated with the connection, and tie it back to the source IP address.

cat conn.log | zeek-cut id.resp_p proto uid | grep -e '^53' | grep 'tcp'
cat conn.log | zeek-cut -u ts uid id.orig_h id.orig_p id.resp_h id.resp_p | grep 'CiThKS3yGNtjJrsuLe'

Now that we have something more to work with we can open up the PCAP in Wireshark and look at the TCP/53 traffic itself.

tcp.port == 53

The timestamp and IP addresses match the Zeek logs. Following the TCP Stream allows us to make more sense of the traffic.

tcp.stream eq 2

This is interesting! We have found a C2 channel used by the threat actor, and it appears they are running as the root superuser account. We can see the threat actor check connectivity to a database server, then use a script exfildb.sh to dump the remote database. Next, the threat actor uploads the contents of /etc/passwd to Pastebin using the curl utility.

After uploading the content of /etc/passwd, the threat actor also uploaded /etc/shadow. That’s not great! The threat actor used the head utility to check the first four lines of the database dump file, then used curl again to upload the database to Pastebin. That’s really not great!

Lastly, we see the threat actor securely delete their tools and database dump from the /tmp/.h4x directory before closing the connection. Before we take a closer look at what was uploaded to Pastebin we need to configure Wireshark to decrypt the encrypted HTTPS traffic. Luckily we have been provided with the secrets.log file that will allow Wireshark to decrypt the traffic for us.

Now that the HTTPS traffic is decrypted we can filter on the HTTP Host header value to find the uploads to Pastebin. Based on our reading of the C2 traffic earlier, we know that the database dump was uploaded in the third request.

http.host == "pastebin.com"

We can read the data more easily by selecting Follow HTTP Stream. Scrolling through the data we quickly find the flag, and complete the challenge!

tcp.stream eq 187



Hack The Box – Keep Tryin’ (Forensics Challenge)

This packet capture seems to show some suspicious traffic.

All that is provided for this challenge is a small PCAP, and the observation that it contains “some suspicious traffic”. Let’s go!

Opening the PCAP in Wireshark we find that it only contains 26 packets.

The first thing my eye was drawn to was the DNS traffic. The use of TXT records with long, seemingly random hostnames looks a lot like DNS tunnelling, but let’s see what else we have.

Looking through the PCAP we find that Packet 10 contains a HTTP POST request to a resource named /flag. Following the HTTP Stream (tcp.stream eq 0) shows the following text:


Similarly, in Packet 21 we find another HTTP POST request to a resource /lootz.

Following the HTTP Stream (tcp.stream eq 1) give us what appears to be base64 encoded text.


Decoding with CyberChef gives us the following:

Keep trying, buffy

Neither of these have any immediately obvious use, so let’s go back to the DNS traffic and take a closer look.


The first DNS request is for the following TXT record:


We can drop the first part of the hostname (init) and the domain (totallylegit[.]com), leaving us with a seemingly random string. From the character set we could be dealing with more base64, however as the standard base64 character set is not safe for use within URLs, we will have to specify the base64url decoding instead. Fortunately CyberChef makes this trivial by offering multiple Alphabets as an option in the From Base64 operation.


This looks promising! The first DNS request did in fact contain base64 (strictly speaking, base64url) data, which decoded to:


The second DNS request is for the following TXT record:


Again, after dropping the first, and trailing parts of the request we are left with the following base64url encoded string:


As before, decoding this in CyberChef with the URL Safe alphabet works, but the data appears to be corrupt…

…or encrypted. Thinking back to the first HTTP POST request in Packet 10, the form data might have been a hint.

Key: TryHarder

My first thought was to add an XOR operation to my CyberChef recipe, using TryHarder as the key, but no luck. Fortunately CyberChef makes it easy to try other ciphers, and not too long later I found that decrypting using RC4 with TryHarder as a key successfully produced a Zip archive containing a file named secret.txt – as per the first encoded DNS request.

Adding the Unzip operation to the CyberChef recipe gives us our flag, and the challenge is complete.



Hack The Box – Took the Byte (Forensics Challenge)

Someone took my bytes! Can you recover my password for me?

This time all we are given is a single file named password,  which is identified simply as data.

Examining it in a hex editor doesn’t give many more clues.

I began thinking that the data might be encrypted somehow, and threw it into CyberChef.

Using the XOR Brute Force module with the default key length of 1 byte, I noticed that using 0xff as a key output a PK header associated with a ZIP archive which appeared to contain a file named password.txt. Quickly building a new recipe, I used the standard XOR module to decrypt the data using key 0xff, then used the Unzip module to extract and view the contents of password.txt which contains our flag.