One last HackTheBox Business CTF 2023 Forensic Challenge (3/3)

Assemblyline Blog Entry #6

⚠️⚠️⚠️ CAUTION ⚠️⚠️⚠️

This document describes malware analysis in Assemblyline. Malware analysis must be performed in an isolated environment.

The following is the third part of a write-up detailing the solutions for forensic challenges that were part of the HackTheBox Business CTF 2023 competition. In the first two parts (Part 1, Part 2), we leveraged static analysis tools, but in this part, we’ll need to push it to the next level and bring out the sandboxes.

Forensics #4: No Start Where

The fourth forensic challenge starts the same way as the earlier challenges, by uploading the ZIP file to Assemblyline. The Extract service extracted a packet capture file (PCAP) from the ZIP file. Assemblyline is usually using the Suricata service to handle and extract data out of PCAPs. It turns out that there was a very silly bug in our Suricata module where we were only extracting the last file that was found in the PCAP, and the interesting files were missed. We ended up fixing it later, but for the CTF, I decided to look at it manually using WireShark’s tshark tool. Upon inspection, we can see two streams that are downloading files using HTTP. We can extract those two files using the following command:

tshark --export-objects http,`pwd` -r 67eafb5c72ab31d0368b4ab2e1525f24d3070e8147f82982f5b5ef6976e3a657

This command results in Security%20Baseline%20Discipline.zip and WINWORD.EXE being extracted. Let’s upload those two files to Assemblyline.

First file:

Zip file’s file tree

Second file:

WINWORD.EXE’s file tree

With the second file, we can see that the .exe file extension was a lie, and the file is a 7-zip archive! The archive is password-protected, and the Extract service was not able to give us the content, or the archive listing.

Regarding that first file Security%20Baseline%20Discipline.zip, the Extract service yields a Word document, and an .scr file. We can see a preview of the first page of most documents through the DocumentPreview service, which shows us a benign-looking report:

First page preview of the Word document

Opening that document manually shows us a second page, which does not have any interesting content. In Assemblyline, we can see some extra information about the file like the name of the creator, the name of the last person who modified the document, and the “create” and “last modified” datetime. If we wanted to see the second page in Assemblyline, it is possible to do so by resubmitting the file and changing the default option of DocumentPreview in the Service Specific Parameters of your submission:

DocumentPreview’s parameters

Switching our attention to the second file, we need to understand that .scr (screensaver) files are simply executables, so we can look at the PE service’s results. The most interesting part is the icon that this executable uses since it is trying to hide as another Word document:

Screensaver’s icon

Unless we want to do some reversing, the executable does not tell us much more. Assuming that the challenge is not in the Reversing category, we should be able to find more information another way.

Let’s try resubmitting our file to Assemblyline with Dynamic Analysis services enabled, also commonly called sandboxes. We have both the Cuckoo service which uses the Cuckoo sandbox and the CAPE service which uses the CAPE sandbox. The Assemblyline team is working on improving the CAPE sandbox to match every feature present in Cuckoo, on top of the new ones. For now, we’ll just select both and see what they’ll give us, and as an FYI, those services generate a lot of results. We will look at CAPE’s results and see what we can gather from them. Here are a few interesting snippets:

CAPE’s network result snippet

CAPE’s stealth_window signature result snippet

CAPE’s suspicious_command_tools signature result snippet

The 7-Zip command above contains a password!!

Process tree result section with 7-Zip’s extraction and password

CAPE also gives us a screenshot from the execution:

Screenshot of the DLL’s execution

Among the extracted files, we can find the D5E0.bat Batch script that we see from the Spawned Process Tree section. It looks heavily obfuscated:

Obfuscated Batch script

It’s a good thing we have the BatchDeobfuscator service! Let’s see what it was able to do to try to make this script more readable (albeit not always executable anymore):

Deobfuscated Batch script

Another Identify issue found during this CTF is that the new Batch script from the Batchdeobfuscator service is not detected as a code/batch file anymore, so code highlighting is not present. We did not get that much more information from it than we already had from the CAPE results, but it is interesting to see the Batch script and how obfuscated it was.

With the password (Njg1NDM4NjY0YzQwNjc) in hand, we can go back to that fake WINWORD.EXE 7-Zip file. We can resubmit the file by hash and specify in Extract’s Service Specific Parameters the password.

Setting Extract’s password parameter

File tree after setting the right password

Once we get the bundau.dll file, we are supposed to reverse engineer it to get the AES constants, investigate how to interpret the functions sending the keys to get them from the original PCAP, and decrypt the other packets to get the flag. As this is not something that Assemblyline is targeted for, we are going to let the reader do this part on their own if they wish!

Hopefully you enjoyed the ride, and want to keep learning about Assemblyline. You can find more information about What other security products WON’T tell you about malicious archives in our next blog entry. We would like to thank HackTheBox and all challenge authors who dedicated time and effort to make the CTF a rewarding experience.

All images unless otherwise noted are by the author.