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 – Forensics Challenges Overview

Hack The Box is a fantastic free (mostly) resource for anyone wanting to improve their offensive security skills. I’ve had an account for years but since I moved away from offensive work to full-time DFIR I haven’t paid much attention to it. Until, that is, I was pointed at their section of forensics challenges.

Rather than logging in to a lab environment via VPN the forensics challenges are standalone downloads of artefacts with a single flag to discover. Points are awarded based on complexity of each scenario while the challenge is active. Every so often a new challenge is added, and an active challenge is retired. No points are awarded for retired challenges, although they are still available to play for those with a Hack The Box VIP subscription.

Due to the distinction between active and retired challenges I am publishing Hack The Box write-ups slightly differently from my usual CTF write-ups. Write-ups for active challenges will be published, but password-protected. The password for each write-up is the Hack The Box flag associated with the challenge. Once a challenge is retired I will remove the password-protection and the write-up will be open to view by everyone.

I realise this might seem strange given all my other write-ups are open, but Hack The Box have a rule prohibiting spoilers for active challenges.

Besides, even if the write-up is password-protected it is often helpful to read other approaches to solving the same problem.

Active Challenges (password-protected)

Retired Challenges

Crowdstrike AdversaryQuest CTF – Much Sad

In January 2021 Crowdstrike opened up their AdversaryQuest CTF. The CTF consisted of 12 challenges split across three new “threat actors”: SPACE JACKAL, PROTECTIVE PENGUIN, and CATAPULT SPIDER. The challenges mostly focused on binary exploitation and reverse engineering which is a bit of a departure from my skillset. Nonetheless I was able to solve two of the twelve challenges; this one relating to the CATAPULT SPIDER adversary, and another from SPACE JACKAL.

Rabid fans of the memetacular Doge and the associated crypto currency, CATAPULT SPIDER are trying to turn their obsession into a profit. Watch out for your cat pictures, lest CATAPULT SPIDER intrude your network and extort them for Dogecoin.

Much Sad

We have received some information that CATAPULT SPIDER has encrypted a client’s cat pictures and successfully extorted them for a ransom of 1337 Dogecoin. The client has provided the ransom note, is there any way for you to gather more information about the adversary’s online presence?

NOTE: Flags will be easily identifiable by following the format CS{some_secret_flag_text}. They must be submitted in full, including the CS{ and } parts.

This challenge is more OSINT focused. The only information we are given is a text file containing the ransom note and some nice Doge ASCII art.

Aside from the ASCII art we have what is presumably a Dogecoin address…

DKaHBkfEJKef6r3L1SmouZZcxgkDPPgAoE

…and an email address.

shibegoodboi@protonmail.com

Searching Google for the username quickly gives us a few promising leads, including a Twitter account and a Reddit account.

I decided to start with the Twitter account, and noticed the link to a Github account named shibefan.

Examining the listed repositories it appears that the user is particularly interested in Dogecoin – no great surprise given what we have been told.

Exploring the repositories themselves we find an HTML page containing the flag.

There is probably much more that could be done around tracking the Dogecoin addresses, but this is enough for now.

Flag

CS{shibe_good_boi_doge_to_the_moon}

 

Crowdstrike AdversaryQuest CTF – The Proclamation

In January 2021 Crowdstrike opened up their AdversaryQuest CTF. The CTF consisted of 12 challenges split across three new “threat actors”: SPACE JACKAL, PROTECTIVE PENGUIN, and CATAPULT SPIDER. The challenges mostly focused on binary exploitation and reverse engineering which is a bit of a departure from my skillset. Nonetheless I was able to solve two of the twelve challenges; this one relating to the SPACE JACKAL adversary, and another from CATAPULT SPIDER.

Not to be confused with spaceflight enthusiasts, SPACE JACKAL have very strict opinions on source code indentation. Brought together by their unbounded hate for ASCII character 9, they will not rest until the last tab stop has been eradicated from the face of the Internet.

The Proclamation

A mysterious file appeared on a deep dark web forum. Can you figure out what we can’t see right now?

NOTE: Flags will be easily identifiable by following the format CS{some_secret_flag_text}. They must be submitted in full, including the CS{ and } parts.

We are given a 512 byte file proclamation.dat and left to get on with it. The first thing I did was use the file utility to determine what kind of data we are dealing with.

file proclamation.dat

The file is identified as a DOS/MBR boot sector. Interesting. Let’s see what strings gives us.

strings proclamation.dat > proclamation.dat.strings
cat proclamation.dat.strings

Ok. After a bit of digging on Google I was able to boot the file using the qemu emulation platform.

qemu-system-i386 proclamation.dat

Cool! Now what? Examining the file in a hex editor showed what looked like random data; maybe it is encrypted somehow?

I wasn’t really sure how to proceed with this – encryption and reverse engineering aren’t my usual thing – but I do know CyberChef! I have an instance of CyberChef installed locally on my SIFT VM so I used that instead of the hosted instance, but the process is the same.

Assuming that the random data was actually encrypted, my first guess was to use the XOR Brute Force operation with a Key Length of 1, but that didn’t output anything intelligible. Next I tried increasing the Key Length to 2 and, in an attempt to cut down on the output, set the flag format – CS{ – as a crib.

CyberChef chewed on this for a minute or so then popped out eight potential decryptions. Examining the output for Key = eaea, I found the same text that was displayed when I used qemu to run the file, and then, appended to the end of the text, the flag!

Flag

CS{0rd3r_0f_0x20_b00tl0ad3r}

 

Magnet Weekly CTF – Week 12

The Magnet Forensics Weekly CTF has been running since October and sets one question each week using an image that changes each month. The October questions were based on an Android filesystem dump, and November’s related to a compromised Hadoop cluster built on Ubuntu Linux. The December challenges return to more familiar territory for me – Windows memory analysis!

These questions use the memory image from the Magnet Virtual Summit 2020, which I first examined during the MVS CTF earlier this year. You can find the rest of my Magnet Weekly CTF write-ups here.

We have reached the final challenge of the #MagnetWeeklyCTF and this week the questions were set by Tarah Melton.

Part 1 (30 points)

What is the PID of the application where you might learn “how hackers hack, and how to stop them”?

Format: #### Warning: Only 1 attempt allowed!

Ok, we are trying to link a particular string to a Process ID. I started by extracting the strings from the entire memory image then using a case-insensitive grep search to get a better idea of what we might be looking for.

strings memdump.mem | grep -i "how hackers hack, and how to stop them"

The text surrounding the match looks like HTML so any of the Internet Explorer or Chrome browser processes are likely candidates, but given the number of them I don’t want to dump each process memory and search manually. Instead, now that we know exactly what to look for, we can throw the yarascan plugin at the image and check the Process ID associated with the matching section of memory. Easy.

vol.py -f memdump.mem --profile=Win7SP1x64 yarascan -Y "How Hackers Hack, and How To Stop Them"

Ok, not a great start. Volatility as installed on the pre-built Ubuntu 18.04 SANS SIFT VM throws an exception because of conflicting use of the -C option in the malfind plugin:

Volatility Foundation Volatility Framework 2.6.1
Traceback (most recent call last):
File "/usr/local/bin/vol.py", line 192, in <module>
main()
File "/usr/local/bin/vol.py", line 174, in main
command = cmds[module](config)
File "/usr/local/lib/python2.7/dist-packages/volatility/plugins/malware/malfind.py", line 190, in __init__
help = 'Make the search case insensitive') 
File "/usr/local/lib/python2.7/dist-packages/volatility/conf.py", line 363, in add_option
self.optparser.add_option("-{0}".format(short_option), "--{0}".format(option), **args)
File "/usr/lib/python2.7/optparse.py", line 1021, in add_option
self._check_conflict(option)
File "/usr/lib/python2.7/optparse.py", line 996, in _check_conflict
option)
optparse.OptionConflictError: option -C/--case: conflicting option string(s): -C

Fixing the malfind and yarascan Volatility plugins on SIFT 18.04

Luckily I’m not the first person to run into this problem, and an issue submitted to the SIFT github repository contains a workaround:

Make a backup of the malfind.py source file, which in my SIFT VM was located:

/usr/local/lib/python2.7/dist-packages/volatility/plugins/malware/malfind.py

Then open the original file for editing and change the short_option at line 189. The original conflicting option is C (upper-case); I changed this to c (lower-case), as shown below:

config.add_option("CASE", short_option = 'c', default = False, action = 'store_true',

I also had to change the short_option at line 195. The original option Y (upper-case) caused another conflict, so I changed this to U (upper-case), as below:

config.add_option('YARA-RULES', short_option = 'U', default = None,

Now, with those minor changes in place, we can get back to the challenge. Using the modified yarascan plugin, we search for the correctly-capitalised version of the string.

vol.py -f memdump.mem --profile=Win7SP1x64 yarascan -U "How Hackers Hack, and How To Stop Them"

The yarascan plugin finds our string in three different locations, but all within an Internet Explorer process – PID 4480.

Flag (Part 1)

4480

Part 2 (20 points)

What is the product version of the application from Part 1?

XX.XX.XXXX.XXXXX

Part two asks for the version of Internet Explorer that was used. Microsoft suggest a few options to check Internet Explorer release versions; I started by checking the following key in the SOFTWARE registry hive.

grep -E "^Virtual|(SOFTWARE)" out/hivelist.txt
vol.py -f memdump.mem --profile=Win7SP1x64 printkey -o 0xfffff8a0002c9010 -K "Microsoft\Internet Explorer"

We are particularly interested in the value of srcVersion11.0.9600.18860 – but this answer was not accepted. Curious. Maybe the Version value – 9.11.9600.18860 – but again, this was not accepted. I noticed that neither of those strings fit the format hint provided in the question, and reading the Microsoft documentation again I saw that 00 version numbers could be truncated to a single 0. Padding the srcVersion value out to 11.00.9600.18860 might be the answer? No.

Time for a different approach. I used the procdump plugin to dump the process executable from memory, then used exiftool to examine the binary metadata. Sure enough, there was a specific Product Version value.

vol.py -f memdump.mem --profile=Win7SP1x64 procdump -p 4480 -D .
exiftool -ProductVersion executable.4480.exe

Reading the question properly helps!

Flag (Part 2)

11.00.9600.18858

That is the end of the Magnet Weekly CTF, at least for 2020. A big “thank you” to everyone involved in setting-up and running the challenge, and to all the other participants who wrote-up and published their solutions each week!