CTF Guide: Hunt Me II - Typo Squatters

This CTF is the final challenge of the Threat Hunting module on THM. It follows-up right after Hunt Me I, but the questions guide the investigation much less than before.

You can find the link to Hunt Me II: Typo Squatters here.

We’re given an ELK Stack to perform our investigation, so open the Discover tab, set the date to the date of the incident (September 26, 2023), and let’s get to it! Answers in this guide will be hidden as usual.

Questions#

What is the URL of the malicious software that was downloaded by the victim user?#

We can start by searching for 7-Zip in the logs, as it should yield the download link to the malware:

• *7zip*
• You can also try *7-Zip*, but that doesn’t yield the answer to question 1. Throughout this investigation, the spelling of query terms is very important to figuring out answers, so keep that in mind.

Sort from oldest to newest to see the first occurrences of the term. In the first result, we can see in the message field that there was a download initiated with Google Chrome, and the URL for the malicious software is displayed.

What is the IP address of the domain hosting the malware?#

We now know the domain, so let’s query ES for it:

• <<domain-from-question-1>>

In the second-oldest result, we can see a DNS query for the domain and its dns.resolved.ip.

What is the PID of the process that executed the malicious software?#

From Q1, we have the output file for the malware, so we can query ES for its execution:

• <<file-from-question-1>>

In one of the early results, we see the command that executes the malware. Expand its details to see the PID.

Following the execution chain of the malicious payload, another remote file was downloaded and executed. What is the full command line value of this suspicious activity?#

Going back to the query in Q1, there are some more commands executed after the initial download of the payload. Highlighting the process.command_line column will reveal the other suspicious command executed.

The newly downloaded script also installed the legitimate version of the application. What is the full file path of the legitimate installer?#

Several of these results have the same process.command_line value, but we want to see the entry which logs the content of the file. Highlight the message column to differentiate the results.

One entry has the Invoke-WebRequest command, which actually links to the legitimate version of 7-ZIP, and contains the OutFile path that we need.

What is the name of the service that was installed?#

We can follow the execution chain from the original malware, to solve this question, but we can simply query ES for service installation events. The Windows Event ID that corresponds to this event is 4697¹:

• winlog.event_id: 4697

There are only two results, but when the winlog.event_data.ServiceName column is highlighted, we can figure out which one is our answer.

The attacker was able to establish a C2 connection after starting the implanted service. What is the username of the account that executed the service?#

From the entry above, we have the binpath of the service, so let’s search for it as a running process:

• 7zipp.exe

Highlight the parent process (to ensure that it was started by Windows Services), and the ParentUser to find our answer.

After dumping LSASS data, the attacker attempted to parse the data to harvest the credentials. What is the name of the tool used by the attacker in this activity?#

If you search for the attacker-controlled IP in (Q2)[#q2], you would see other tools from that location being referenced:

• X.X.X.X

Researching some of these tools online, it becomes obvious which one of these is the answer.

What is the credential pair that the attacker leveraged after the credential dumping activity? (format: username:hash)#

As part of some lessons in the Threat Hunting module on TryHackMe, there were example queries to check for potential credential dumping. This query in particular is to detect Mimikatz usage, so let’s test it on these records:

• winlog.event_id: 1 AND process.command_line: (mimikatz OR DumpCreds OR privilege\:\:debug OR sekurlsa\:\:)

We do find Mimikatz usage, and see Pass-The-Hash attacks² executed against several users. The first user who’s targeted is our answer.

After gaining access to the new account, the attacker attempted to reset the credentials of another user. What is the new password set to this target account?#

To change the password of a user, usually the net.exe command is used, so we can query it:

• process.name: net.exe

There are a few attempts to change the password of user anna.jones. From the previous question, we noticed mimikatz.exe being run from Anna’s account, so we can assume this account was compromised.

Anyway, we can see the new password being set from these records.

What is the name of the workstation where the new account was used?#

From the results of Q8, look at the host.hostname field when the anna.jones account runs Mimikatz commands.

After gaining access to the new workstation, a new set of credentials was discovered. What is the username, including its domain, and password of this new account?#

We know the workstation, the compromised user, and we’re looking for credential details, so we can try a general search for all three terms:

• host.hostname : "<<answer-from-question-11>>" AND user.name: "anna.jones" AND password

From these results, we see a process to add anna.jones to the AD Recovery domain group. The process uses an administrative account to do so, and displays the domain, username, and password in plaintext.

Aside from mimikatz, what is the name of the PowerShell script used to dump the hash of the domain admin?#

In this case, we can craft a similar query to the previous question, except replace “password” with “hash”:

• host.hostname : "WKSTN-02" AND user.name: "anna.jones" AND hash

Looking at the code repo referenced in the results, the tool displayed is confirmed to be a valid alternative to Mimikatz.

What is the AES256 hash of the domain admin based on the credential dumping output?#

In the results from the previous query, we’re actually able to see the PowerShell output and resulting hashes

This hash will fall under the aes256_hmac field of the output.

After gaining domain admin access, the attacker popped ransomware on workstations. How many files were encrypted on all workstations?#

It was at this point that I realized that for all my previous answers, I didn’t have to explore the attack chain sequentially, starting from the malicious process in Q3. To prove this answer though, it is necessary, so I’ll show the entire chain from the start.

The process executing the malware in Q3 has a process.pid of 4248. For the next event, we have to search for events with a process.parent.pid of 4248:

• process.parent.pid: 4248

We can observe that it executes a suspicious DLL, and we rinse and repeat the actions. See which new processes are spawned, then search for their child processes. Here’s the next few in the chain:

Looking at the screenshot above, we see that the attacker downloads their software 7zipp.dll to C:\Users\anna.jones\Downloads\ multiple times, and just slightly alters the name each time. One such name is 7zip.dll, and rundll32.exe is executed on it, so let’s check which processes it spawns:

• process.name: rundll32.exe AND 7zip.dll

Looking through the results of the previous query, you might notice that this is the main PowerShell process we’ve seen throughout this investigation running malicious commands. One interesting binary that we haven’t seen yet is bomb.exe, which is again downloaded from the attacker’s domain.

Query bomb.exe to try to deduce what it does:

• process.name: bomb.exe

It creates a lot of File created events, so let’s filter on those.

Each file seems to be a regular system file with .777zzz appended to it, so it’s highly likely that all these results signify a file encrypted by the malware. So all we need to do is count the number of results, and this is our final answer for this challenge.

Conclusion#

I wouldn’t say that this challenge was difficult, but the way I answered the first 14 questions was mostly based on intuition. I wasn’t directly linking chained processes to figure out the answers.

Before I even got to the last question, I had already seen bomb.exe alongside other search results, and I assumed that it was manipulating the files in some way. But just using intuition, it became hard to definitively prove that bomb.exe was dropped by the attacker, encrypted files, executed from a compromised account, and kicked off by the initial malware drop.

It was only through diving through the attack chain, PID by PID, that each of the above statements could be reliably proven.