Overview

This is another medium-difficulty Splunk challenge from TryHackMe. We’re tasked with uncovering the malicious activity that occurred on a compromised endpoint.

Scenario

You are a SOC Analyst for an MSSP (managed Security Service Provider) company called TryNotHackMe.

A newly acquired customer (Widget LLC) was recently onboarded with the managed Splunk service. The sensor is live, and all the endpoint events are now visible on TryNotHackMe’s end. Widget LLC has some concerns with the endpoints in the Finance Dept, especially an endpoint for a recently hired Financial Analyst. The concern is that there was a period (December 2021) when the endpoint security product was turned off, but an official investigation was never conducted.

Your manager has tasked you to sift through the events of Widget LLC’s Splunk instance to see if there is anything that the customer needs to be alerted on.

Happy Hunting!

Q1

A Web Browser Password Viewer executed on the infected machine. What is the name of the binary? Enter the full path.

We’ll start by seeing if we can find any interesting information in the fields. Since we know we’re investigating a Financial Analyst, we’ll narrow our search for the relevant user.

From here, let’s see if there are any odd executables listed.

We can see some odd Images listed in the top 10 and over 1,000 calls to EasyCalc.exe. Let’s put them into a table and look at some additional information such as Company and Description.

With that, we’ve got our answer. We can see that the oddly named 11111.exe has a description of “Web Browser Password Viewer.”

Q2

What is listed as the company name?

We got the company name in the previous output, and it’s worth noting that NirSoft tools, like SysInternals, are widely used by investigators, admins, and threat actors.

Q3

Another suspicious binary running from the same folder was executed on the workstation. What was the name of the binary? What is listed as its original filename? (format: file.xyz,file.xyz)

We’d already seen this file in Q1, but the results are a bit easier to read in a table. Here we can see that IonicLarge.exe is in the same folder as 11111.exe.

Note: Because we filtered for company and description, IonicLarge.exe was not included in our previous table even though it was in the top 10 list.

We can use the OriginalFileName field for the other half of the question.

Q4

The binary from the previous question made two outbound connections to a malicious IP address. What was the IP address? Enter the answer in a defang format.

With the search filtered for the IonicLarge binary, we’ll filter for the DestinationIp field.

We can see there were two outbound connections to a specific IP, and we’ll use VirusTotal to confirm the IP is known to be malicious.

Lastly, we have to defang the IP address either manually or with something like CyberChef.

Q5

The same binary made some change to a registry key. What was the key path?

To get this information we’ll check the TaskCategory field, which confirms that the binary was making changes to the registry.

Note: You could also use EventCode 13 for this.

With the TaskCategory we can make a table of all the registry edits. Moreover, we can use RegEx to extract the relevant portion of the Message field.

Note: It is not necessary to use the rex command, but it does make the table much more concise. If you want to print the whole Message field, use table Message.

We can see the binary was using the registry to disable Windows Defender.

Q6

Some processes were killed and the associated binaries were deleted. What were the names of the two binaries? (format: file.xyz,file.xyz)

The command to kill processes in Windows is taskkill, so we’ll start by searching for commands that included taskkill.

In the results, we can see two similar commands killing a running process and deleting the associated binaries.

Q7

The attacker ran several commands within a PowerShell session to change the behaviour of Windows Defender. What was the last command executed in the series of similar commands?

We already saw the changes made to the Registry, so we’ll search again for PowerShell execution and sort by time.

Q8

Based on the previous answer, what were the four IDs set by the attacker? Enter the answer in order of execution. (format: 1st,2nd,3rd,4th)

We can see the ID values in the previous screenshot, but we can practice using the rex command to make the output a bit more legible.

Explaining the rex usage: We can count the length of the ID and see each value is 10 digits, so we’ll extract a series of 10 digits from each CommandLine entry and assign it to a new field called ID. Then we’ll create a table of ID and Time.

Q9

Another malicious binary was executed on the infected workstation from another AppData location. What was the full path to the binary?

We already saw some other suspicious files in the AppData directory way back in Q1, but here’s a full list.

The only result that is not in AppData\Local is EasyCalc.exe. We also noted earlier that it had a large number of events. Digging further we can see EasyCalc also made some network connections as well as added a trusted CA to the Registry.

Note: Other files under AppData local are also flagged as malicious, for example, Setup.exe’s hash is flagged by VirusTotal.

Q10

What were the DLLs that were loaded from the binary from the previous question? Enter the answers in alphabetical order. (format: file1.dll,file2.dll,file3.dll)

While filtering for EasyCalc, we can set TaskCategory to ImageLoaded, from there we can build our table and see what DLLs were loaded.

Conclusion:

This challenge was a good excuse to practice the rex command. With rex, we were able to extract only the relevant pieces of longer fields like Message. The TaskCategory field also made it easy to drill down into some of the malicious activity, giving us an idea of what to look for within the events.