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

Flag

HTB{Th15_15_4_F3nD3r_Rh0d35_M0m3NT!!}

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:

TryHarder

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.

S2VlcCB0cnlpbmcsIGJ1ZmZ5Cg==

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.

dns

The first DNS request is for the following TXT record:

init.c2VjcmV0LnR4dHwx.totallylegit.com

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.

c2VjcmV0LnR4dHwx

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

secret.txt|1

The second DNS request is for the following TXT record:

0.0ejXWsr6TH-P_1xkEstaVwi7WDy8AcxufnGotWXH3ckb2Lh5A-qFljIWOAOLUS0.T1W8P4CpiCZbCM7_QKcv-r0JG29RpsyYY5YkZRxo7YDIYUJpHlGgxu5PWV1G_DA.KNrmnrktfbeDgzcpPJBjPTeMYx3Qs1Q6bAuFhROWXemJ80gPTYIz0xl8usJQN3m.w.totallylegit.com

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

0ejXWsr6TH-P_1xkEstaVwi7WDy8AcxufnGotWXH3ckb2Lh5A-qFljIWOAOLUS0.T1W8P4CpiCZbCM7_QKcv-r0JG29RpsyYY5YkZRxo7YDIYUJpHlGgxu5PWV1G_DA.KNrmnrktfbeDgzcpPJBjPTeMYx3Qs1Q6bAuFhROWXemJ80gPTYIz0xl8usJQN3m

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.

Flag

HTB{$n3aky_DN$_Tr1ck$}

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.

Flag

HTB{27AjFDkqi1wJ}

Hack The Box – Illumination (Forensics Challenge)

A Junior Developer just switched to a new source control platform. Can you find the secret token?

There isn’t much to this challenge. We are given an archive containing some source code and the associated .git directory.

Entering into the .git directory…

…and reading the Git logs…

git log

…we can see that commit 47241a47f62ada864ec74bd6dedc4d33f4374699 removed a “unique token”. We can view that specific commit and see exactly what was changed.

git show 47241a47f62ada864ec74bd6dedc4d33f4374699

We can clearly see the original token highlighted in red, which has been replaced with some placeholder text. Looking at the character set and the trailing = character, base64 encoding is a good bet.

echo "SFRCe3YzcnNpMG5fYzBudHIwbF9hbV9JX3JpZ2h0P30=" | base64 -d

There we go. Job done.

Flag

HTB{v3rsi0n_c0ntr0l_am_I_right?}

Hack The Box – MarketDump (Forensics Challenge)

We have got informed that a hacker managed to get into our internal network after pivoting through the web platform that runs in public internet. He managed to bypass our small product stocks logging platform and then he got our costumer database file. We believe that only one of our costumers was targeted. Can you find out who the customer was?

This time all that is provided is a PCAP file; I started by opening it up in Wireshark…

…and viewing the Protocol Hierarchy Statistics.

The statistics report that 38.7% of the TCP bytes are simply Data – that seems an interesting enough starting point. I used a simple Display Filter:

data

Then selected the first of the TCP packets (#2636) and Follow TCP Stream (TCP Stream #1056) to allow me to follow the session more easily.

It looks like we have a capture of all the commands the attacker ran on the host post-compromise, including a dump of a text file – costumers.sql

cat costumers.sql

Scrolling through the dumped file it becomes apparent that one of the lines stands out.

American Express, NVCijF7n6peM7a7yLYPZrPgHmWUHi97LCAzXxSEUraKme

It kind of looks like base64, but the character set is not quite right. CyberChef should help make sense of this.

One of the really helpful things about CyberChef is that sometimes it just knows what the data is. The magic function suggests the data is actually base58 encoded…

…and there we go. Flag retrieved and challenge solved!

Flag

HTB{DonTRuNAsRoOt!MESsEdUpMarket}