TryHackMe — Boogeyman 1 Challenge Walkthrough

Email, Endpoint, & Network Forensic Investigation using Thunderbird, LNKParse3, PowerShell Logs, JQ, & Wireshark

Image Credit: https://tryhackme.com/r/room/boogeyman1

Introduction:

Are you afraid of the Boogeyman?

If not, welcome to my weekly walkthrough, you’ve stumbled on the right blog! This blog is a walkthrough of the Boogeyman 1 challenge from TryHackMe and is the first in a series of capstone challenges for the SOC Level 1 path. This challenge is a multi-part digital forensics and incident response (DFIR) investigation focusing on a fictional threat actor called the Boogeyman.

In this challenge, we will investigate email, endpoint, and network artifacts collected from a victim compromised by this new, shadowy threat actor. It is our job as security analysts to determine how the Boogeyman got in, what they took, and how they did it. Doesn’t sound so scary, right?

To unmask the Boogeyman, we’ll utilize a few tools at different points in our investigation including LNKParse3, JQ to parse JSON formatted PowerShell logs, and Wireshark for deep packet capture analysis.

Now let’s grab our flashlights and shine a light on the Boogeyman’s tactics, techniques, and procedures. I don’t want to ruin any of the fun, so this walkthrough will not contain spoilers, but please use this as a reference and enjoy! Thanks for reading along!

Challenge Link: https://tryhackme.com/r/room/boogeyman1

Challenge Scenario:

Uncover the secrets of the new emerging threat, the Boogeyman.

In this room, you will be tasked to analyse the Tactics, Techniques, and Procedures (TTPs) executed by a threat group, from obtaining initial access until achieving its objective.

Task 2 — Email Analysis

Julianne, a finance employee working for Quick Logistics LLC, received a follow-up email regarding an unpaid invoice from their business partner, B Packaging Inc. Unbeknownst to her, the attached document was malicious and compromised her workstation.

The security team was able to flag the suspicious execution of the attachment, in addition to the phishing reports received from the other finance department employees, making it seem to be a targeted attack on the finance team. Upon checking the latest trends, the initial TTP used for the malicious attachment is attributed to the new threat group named Boogeyman, known for targeting the logistics sector.

You are tasked to analyse and assess the impact of the compromise.

Question 1: What is the email address used to send the phishing email?

We’ll jump right into our environment and look at the dump.eml file. There are number of ways that we can approach header analysis of this email, but let’s just open with the Mozilla Thunderbird client so that we can get the victim’s perspective.

The phishing email.

We’ll start out with a simple one and enter the From field address to answer Question 1.

Question 2: What is the email address of the victim?

We’ll follow the same process for Question 2 except this time we will enter the To field name which is the recipient address.

Question 3: What is the name of the third-party mail relay service used by the attacker based on the DKIM-Signature and List-Unsubscribe headers?

Now, we need to get more detail beyond what’s shown in the normal, visible headers by viewing the message source.

To do this in Thunderbird press More > View Source.

It might look a little scary at first, but let’s use the find function of the text editor to locate the DKIM-Signature line:

If you would like more information on what DKIM is or what the header means, refer to the excellent Email Headers list from Mailtrap.io. I refer to this list often when I need additional context for email header analysis!

Email Headers Explained: Definition, Components, Role [2024]

Question 4: What is the name of the file inside the encrypted attachment?

Now, let’s download the suspicious ZIP archive file from the email message and save it to our artefacts folder. If we peek inside of the archive, we’ll see a .lnk (shortcut) file within it.

Very suspicious, indeed! Fortunately, this is enough information to answer Question 4!

Question 5: What is the password of the encrypted attachment?

Let’s jump back to Thunderbird and review the suspicious email sent to the victim. We’ll notice that the sender was kind enough to send us a handy password to open the archive.

Now that we have the password for the ZIP file, we will extract the .lnk file. In the next question, we’ll perform some analysis on this LNK file in the next question.

Question 6: Based on the result of the lnkparse tool, what is the encoded payload found in the Command Line Arguments field?

Now that we have extracted the .lnk from the archive, we’ll parse it and see if we can determine what it does. To do this, we will use the tool suggested in the challenge introduction — LnkParse3.

Within our analysis environment, open up the terminal and use the following syntax to parse the file:

lnkparse NAME-OF-FILE.lnk

Scroll through the output and we’ll see something interesting — an encoded PowerShell command. This is extremely suspicious and definitely requires further investigation.

For now, we only need to submit the encoded command to answer Question 6 before we move on to investigating the victim’s endpoint device.

Task 3 — Endpoint Security

Based on the initial findings, we discovered how the malicious attachment compromised Julianne’s workstation:

A PowerShell command was executed.

Decoding the payload reveals the starting point of endpoint activities.

Question 1: What are the domains used by the attacker for file hosting and C2? Provide the domains in alphabetical order. (e.g. a.domain.com,b.domain.com)

So, we know that a malicious PowerShell command was executed from the execution of malicious attachment we analyzed in the previous task. To determine the impact of the malicious attachment, we’re going to need to analyze the Windows PowerShell event logs.

But first, let’s decode the Base64 encoded payload that we discovered within the attachment. There are a few tools to do this, but for simplicity, I’ll just utilize the Base64 command to decode this in the terminal:

echo "ENCODED STRING" | base64 -d

Let’s note this URL and move on to analyzing the PowerShell logs. We have just a quick detour — remember the note from Task 1?

Note: The powershell.json file contains JSON-formatted PowerShell logs extracted from its original evtx file via the evtx2json tool.

So, rather than viewing the exported PowerShell Windows Event Log (.evtx) file, we are going to rely on JQ, which is a command-line based JSON parsing tool to parse the PowerShell.json.

We will start with the simplest option; parsing the JSON file into the beautified output using the syntax below:

cat powershell.json | jq

Right away, we will see a ton of information but it’s too much output to sift through manually. Let’s filter by events by “ScriptBlockText” so that we can focus on events with statements that we can analyze.

According to Microsoft:

In the PowerShell programming language, a script block is a collection of statements or expressions that can be used as a single unit. The collection of statements can be enclosed in braces ({}), defined as a function, or saved in a script file. A script block can return values and accept parameters and arguments.

Let’s go a step further too. We’ll re-tool our JQ filter to apply sorting by Timestamp, the ScriptBlockText field, and remove duplicate entries:

cat powershell.json | jq -s -c 'sort_by(.Timestamp) | .[] | {ScriptBlockText}' | sort | uniq

While this still returns a lot of output, we’ve filtered to the most relevant output for our search. In particular, there are a couple of interesting lines that are requesting data with different URLs — one uses Invoke-WebRequest and the other that we already found by decoding the Base64 command uses WebClient.

These are the two command and control (C2) domains that we are looking for to answer Question 1!

Question 2: What is the name of the enumeration tool downloaded by the attacker?

We’ll keep with the same JQ output since we actually saw this earlier while looking for the C2 URLs.

The attacker downloaded a tool from a GitHub Repository, but is it an enumeration tool? Let’s do some research to find out.

See the name of the .ps1 file referenced at the end of the command? Navigate to the GitHub repository and we can locate the separate repository for referenced tool!

We’ll do some quick reading through the documentation for this project to discover that the tool does contain some enumeration function using WMI - this confirms that we discovered the correct tool!

Question 3: What is the file accessed by the attacker using the downloaded sq3.exe binary? Provide the full file path with escaped backslashes.

Okay, now we are looking for a specific executable. We’ll keep with using JQ but we need to adjust our scope. What if we grep the output to display only results containing sq3.exe?

cat powershell.json | jq '{ScriptBlockText}' | grep "sq3.exe"

Hey, that’s getting us closer! We found a file that the executable accessed. Now all we need to know is the user account name to add to the front of the path. We’ll use the same command as before but revise the grep to the change directory (cd) command. This should help us understand how the attacker traversed the victim’s directories and disclose a valid profile name.

cat powershell.json | jq '{ScriptBlockText}' | grep "cd"

Here, we’ll find references to a user profile name. Append this profile name to the path we found earlier accessed by sq3.exe to form our answer!

Question 4: What is the software that uses the file in Q3?

To answer this question, look at the file path from the previous question:

The file is a database that stores information for a specific application, the specific application is the answer to Question 4.

Question 5: What is the name of the exfiltrated file?

Let’s pull back and revisit the JQ output for ScriptBlockText that we used in Question 1 and browse through the output again. We’ll stumble across the following line where we can see some evidence of a file being exfiltrated to an external IP address:

Submit the IP address as the answer but also add it to your notes as we may need it again later!

Question 6: What type of file uses the .kdbx file extension?

If you aren’t familiar with this file type, do some quick Google research to determine what application uses it. There is a help center for the application that has a detailed specification page about the file extension.

Question 7: What is the encoding used during the exfiltration attempt of the sensitive file?

Continue reviewing the JQ parsed command output. Following the line we discovered to answer Question 5, we’ll see another interesting item that contains the file encoding used during the exfiltration:

Question 8: What is the tool used for exfiltration?

To answer Question 8, refer back to the previous question’s output that contains the encoding method and look further down the command.

After the data is encoded, we’ll see another command which appears to be using DNS to query the A record of attacker-controlled infrastructure at the $destination variable. Remember that the IP address we found in Question 5 was defined as $destination?

This looks like it might be a living off the land exfiltration technique where targeted data is encoded, split to a character limit, and then exfiltrated though DNS queries to the adversary’s infrastructure by appending the data (the $line variable) to a domain name where it can be reassembled or interpreted by the adversary.

Maybe we will get more information when we move into the network packet capture analysis…

Task 4 — Network Traffic Analysis

Based on the PowerShell logs investigation, we have seen the full impact of the attack:

The threat actor was able to read and exfiltrate two potentially sensitive files.

The domains and ports used for the network activity were discovered, including the tool used by the threat actor for exfiltration.

Question 1: What software is used by the attacker to host its presumed file/payload server?

Now, we are moving into the next phase of our investigation, the network traffic analysis. From the artefact folder, double-click capture.pcapng to open it with Wireshark.

Once we’re in Wireshark, we need a starting point for the next phase of our investigation. Let’s begin by inputting the attacker’s infrastructure IP address that we located in Question 5 of the Endpoint Security section into Wireshark’s filter:

ip.addr==167.71.211.113

That’s a lot of output, so let’s make this a bit more manageable and focus on the HTTP protocol traffic by further adjusting our filter.

http && ip.addr==167.71.211.113

Much more manageable! Let’s focus in on the first HTTP response (33256.) Right click the packet row > Follow > HTTP Stream.

Once the HTTP Stream window opens, we can check out the Server field to determine what application is hosting the web server:

Question 2: What HTTP method is used by the C2 for the output of the commands executed by the attacker?

We found this information when analyzing the PowerShell logs in Endpoint Security Question 1, remember? If not, here’s a refresher:

Since, we know the attacker is exfiltrating the data out and not requesting it in, the method would NOT be GET…

Question 3: What is the protocol used during the exfiltration activity?

Remember back in Question 8 of the Endpoint Security Section (Task 3) we discovered that the exfiltration tool used a specific protocol? This is the answer to Question 3.

Question 4: What is the password of the exfiltrated file?

Since this gets a little complicated, let’s lean on the question hint:

Thanks, THM! So, the working theory here is that we need to locate a password that the victim stored in the file that accessed by sq3.exe in the Endpoint Investigation (Question 3) to “unlock” the exfiltrated file.

So, let’s leverage Wireshark’s search function to search the packets for a keyword. First, press CTRL + F to bring up the find/search bar, then select String, and finally select Packet details so we can search within middle “packet details” window. Now enter sq3.exe into the search box.

Here, we will locate an HTTP GET request packet (42700), but since the attacker took the data and sent it out, we’re looking for a POST request.

If we continue with the find function, there are four hits for sq3.exe. The last one has the same PowerShell command in the text data that we found in the Endpoint Analysis section for Question 3. It feels like we are getting closer!

So, we’ll use 44459 as our starting point for searching POST requests. We’ll need to cut down the noise by filtering HTTP POST methods since we can’t simply just keep searching sq3.exe. We can further narrow our scope by also filtering anything below our starting point frame number.

http.request.method==POST && frame.number > 44459

This gets us down to nine entries. Let’s start analyzing the first entry (44467) and Follow > HTTP Stream:

Well, that’s a big blob of something! Let’s drop it into CyberChef so that we can do some decoding operations and see if we can get something readable. To start, we can go lazy mode and see if the Magic function can do anything for us:

It looks like CyberChef can do some decoding if we apply the From Decimal recipe. Let’s apply it and see what we can find…

Bingo! We found the “Master Password” that the victim stored in plain text— not good!

Question 5: What is the credit card number stored inside the exfiltrated file?

Alright, we made it to the last question! Now that we have a “Master Password” we need to unlock something with it…

Let’s recap what we know so far:

• The exfiltrated file is a type of database that would require a master password. We know what application it is from Task 3 — Question 6.
• From Question 8 of the previous task, we also know that this database was being converted to Hexadecimal in blocks, and exfiltrated over DNS A record queries to the destination IP address of 167[.]71[.]211[.]113
• Each DNS query is sent in the format of an encoded string ($line) appended to bpakcaging[.]xyz.

Below is the evidence from that question for our reference:

PowerShell Reference of the KDBX Exfiltration

So, we know the file, protocol, domain, and IP address. Let’s try to leverage Wireshark to filter out just the packets relevant to this information. To do this, we need to adjust our filter again.

First, I went to Wikipedia to find out the type id for the DNS A Record which is 1. This helps us build our Wireshark query to only look at DNS A records. Then we also input the IP address that the data is exfiltrated to.

dns.qry.type==1 && ip.dst==167.71.211.113

Now, we will see a ton of rows returned but the data matches the format that we expected based on what we learned about the exfiltration method. But it isn’t readable just yet.

So, now we need to figure out how to reassemble this data. We’re going to move it out of Wireshark so we’ll first export this data by selecting all the filtered packets and pressing File > Export Packet Dissections > As Plain Text.

For the purposes of this walkthrough, my output file is called AQuery.txt. When we open AQuery.txt in a text editor, it looks like this:

While helpful, we still need to clean up this data to carve out only the Hex encoded strings that we need. I’m certain there is a better way to do this (alluded to in the question hint) but my approach is to try to transform this data from within the terminal.

To save you some time, I freely admit that there was a lot of stumbling, trial and error, and time spent researching with Google and Microsoft Copilot to come up with command using grep and sed that would work to clean up the data, until at long last, I landed on the below version:

grep -Eo '[0-9a-fA-F]{8,}\.[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}' AQuery.txt | sed 's/\.[a-zA-Z0-9.-]\+\.[a-zA-Z]\{2,\}.*//' | uniq | tr -d '\n'

Here’s the long story short(ish) — The grep command is performing some pattern matching to display only the Hex strings followed by a “domain.tld” and trailing text from our Wireshark output file. Then, sed removes the domain and any trailing text, removes duplicate entries, and concatenates the results into a single line without any delimiters so it’s a long, single line combining all the Hex strings we found being sent to the C2 domain.

But now that we have the required data, we still need to output the file so that we can convert it from Hex into a working database file.

grep -Eo '[0-9a-fA-F]{8,}\.[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}' AQuery.txt | sed 's/\.[a-zA-Z0-9.-]\+\.[a-zA-Z]\{2,\}.*//' | uniq | tr -d '\n' > hexdump.txt

We’re almost there! Now we’ll convert the Hex data to ASCII and save the database as a new output. We’ll achieve this by processing it with xxd.

xxd creates a hex dump of a given file or standard input. It can also convert a hex dump back to its original binary form. Like uuencode(1) and uudecode(1) it allows the transmission of binary data in a ‘mail-safe’ ASCII representation, but has the advantage of decoding to standard output. Moreover, it can be used to perform binary file patching.

xxd -r -p hexdump.txt > database.kdbx

Finally, we can open the reassembled KDBX file! The TryHackMe analysis environment already has the correct application to open this file type and it should automatically be associated.

Once it opens, we are prompted for the Master Password that we recovered in the previous question. Inputting the password unlocks the database and allows us to retrieve the credit card number that the victim stored in their password manager which is now in the hands of the adversary! Time to call the bank, indeed!

Go ahead and input the victim’s credit card number and let’s wrap up this investigation.

Conclusion:

Mission accomplished — We have completed our frighteningly fun investigation of the Boogeyman 1! Using our forensic skills, we learned how the Boogeyman infected the victim’s device with a malicious attachment, collected and exfiltrated data with PowerShell and DNS, and stole credit card data stored in KeePass. Now, let’s wrap this investigation!

A huge thank you to TryHackMe for the seriously fun challenge! I was really impressed with the dimensions of this room as it had three different scopes and a complete narrative. The detail and flow were much closer to a real-world simulation exercise than others I have completed. The escalating difficulty was also really engaging as it started out easy and ramped up as the room went on. This really pushed me out of my comfort zone and forced creativity when it came to the later steps of the Networking Traffic Analysis. I was also excited to have the opportunity to get some hands-on time with JQ as I was familiar with the name but had not encountered it before.

If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Until the Boogeyman returns, stay safe! If you want to continue battling the Boogeyman, be sure to check out my walkthrough of the Boogeyman 2.

TryHackMe — Boogeyman 2 Challenge Walkthrough

Tools & References:

Mailtraip.io Email Headers List: https://mailtrap.io/blog/email-headers/

LnkParse3: https://github.com/Matmaus/LnkParse3

JQ: https://jqlang.github.io/jq/

Microsoft Script Block: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_script_blocks?view=powershell-7.4

Microsoft Learn (WebClient Class): https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-8.0

Microsoft Learn (Invoke-WebRequest): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7.4

CyberChef: https://gchq.github.io/CyberChef/

Wikipedia DNS Types: List of DNS record types — Wikipedia

Linux Man Pages (XXD): https://linux.die.net/man/1/xxd