Overview

In Hunt Me 2 we’ll be querying ELK for artifacts left by the attacker. We’ll utilize process IDs and Sysmon Event IDs to identify the execution chain and determine what user accounts were targeted and the scope of the impact.

Scenario

Just working on a typical day as a software engineer, Perry received an encrypted 7z archive from his boss containing a snippet of a source code that must be completed within the day. Realising that his current workstation does not have an application that can unpack the file, he spins up his browser and starts to search for software that can aid in accessing the file. Without validating the resource, Perry immediately clicks the first search engine result and installs the application.

Last September 26, 2023, one of the security analysts observed something unusual on the workstation owned by Perry based on the generated endpoint and network logs. Given this, your SOC lead has assigned you to conduct an in-depth investigation on this workstation and assess the impact of the potential compromise.

Note: If you need a refresher on any of the Elastic techniques used, you can view the Hunt Me 1 write-up

Q1

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

Our briefing instructed us that the logs were pulled on September 26th, so we’ll filter for this date in Elastic.

We’ll also sort the timestamp column from Old-New so that the first events appear at the top of the list.

Once filtered, we can check what kind of log sources we have by visualizing the event.provider field.

We can see our sources contain a ton of PowerShell and Security logs. We also have a decent amount of Sysmon logs, which should help in our analysis.

Our briefing has told us that the user downloaded a malicious version of 7zip. One way we can find the download URL is by checking the Zone.Identifier stream of the downloaded file.

Thankfully, Sysmon logs this information in event ID 15, so we’ll filter for that.

There are only four events with this event ID, so we could look through each one fairly quickly.

Instead, however, we’ll apply a couple columns to make the data easy to see. In this case, we can use the file.name and winlog.event_data.Contents fields as columns.

Here we can see an MSI installer that was downloaded from a 7zipp.org site, as we saw in the briefing screenshot.

Q2

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

Sysmon logs DNS lookups with Event ID 22.

We get 212 results, but we’ll start by applying the columns, we can always filter further if needed.

The field names, in this case, are dns.question.name and dns.answers.data.

With these columns set, we can see that the very first result is the malicious website we found in the previous question, so we won’t need to do any more filtering.

Q3

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

We know the downloaded executable was named 7z2301-x64.msi so we will filter for process creation events (Sysmon Event ID 1) that contain the filename.

The filter results in a single event, inspecting the event shows that the msi was launched by msiexec.exe.

Of course, we could have applied columns to the results to see the data at a glance.

Q4

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?

Let’s start by digging into the chain of process execution. We know that the malicious executable was run by PID 2532, so we’ll filter for processes with this PID or PPID.

We get 19 results, and taking a quick glance through them we can already see some very alarming command execution.

In the results, we see powershell used to download and execute powerview.

We can see that the PPID of the malicious powershell execution is 4188, so we’ll add that to our filter to continue investigating this chain of execution.

Our updated query returns 82 hits and many more red flags.

In the results, we can see that a couple powershell scripts were downloaded along with mimikatz.

Scrolling through the results we can see user enumeration among the attacker activities.

Although we have discovered the download and execution of malicious scripts, we will have to keep digging to solve this question.

Checking the PID and PPIDs for these new events, we can see some new ones to add to our filter. The next PPID in this chain that we see is 3988, so we’ll go ahead and add this to our filter.

Our results reveal another PID worthy of investigation, so we’ll add that to our filter and repeat the process.

To clean up the results a bit, we’ll add a filter to ensure the events contain commandline data. This will filter out any events we’re not interested in at the moment.

We can see in the results, a much more clear depiction of the timeline of events.

After the initial executable was run with msiexec.exe, powershell was used to download a powershell script from the 7zipp.org domain.

We can also see another executable named 7zlegit.exe located in the Temp directory, followed by service creation with sc.exe.

We should take note of all of these alarming entries and PIDs for further investigation/documentation.

Q5

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

Looking back at our findings from the previous question, we can see that the executable found in the Temp directory was executed within 5 seconds of the script we discovered.

Though we could investigate the executable based on this information alone, let’s take it a step further and expand our filter.

To do this, we’ll adjust our filter to include file creation events (Sysmon Event ID 11).

Note: To keep the results tidy, we’ll add this filter as an OR statement with the process.command_line filter. This will ensure our results will only contain commandline execution or file creation events.

Our results confirm that the 7zlegit.exe was created by the same PID that is associated with the downloaded script.

Although the file creation events don’t contain file hashes, we can grab the hash from the process creation event and investigate it with a tool like VirusTotal.

We can see the OriginalFileName in the Sysmon event is listed as 7zipInstall.exe, the Company is listed as Igor Pavlov, and the results on VirusTotal seem to confirm that this is the legitimate binary.

Q6

What is the name of the service that was installed?

Now that we’ve uncovered the file creation event, we’ll remove the Event ID 11 results from our filter so we can focus on process execution.

We already noted the sc.exe execution earlier, but we’ll take another look at it now.

We can see the name of the service created in the commandline data.

Q7

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?

We know the name of the service executed, the associated executable, and its full path, so there are a number of ways we could go about determining which user ran the service.

We’ll adjust our current filter so we can keep the result in context with the other events we’ve discovered.

To do this, we’ll include events that were executed by services.exe.

The first few results precede the malware execution, so we can ignore those.

Scrolling down to the service creation event, we can see the service execution immediately following the events we discovered previously.

Inspecting the details of the service execution shows us the user account associated with the event.

Q8

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?

Looking through the attacker’s activities that we’ve discovered, we can see a couple powershell script downloads and executions.

Invoke-NanoDump.ps1 and Invoke-PowerExtract.ps1 are used to dump lsass and parse credentials respectively.

Knowing the purpose of these tools, their close proximity in timestamps, and the matching PPIDs, we can safely say that these were the tools used to attempt harvesting credentials.

Q9

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

We can see mimikatz execution shortly after the powershell scripts were run.

Inspecting the command arguments tells us that the attacker executed a PassTheHash attack (sekurlsa:pth).

We can read the credentials from the event’s commandline data.

Q10

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?

Following the execution chain we’ve already filtered, we can see a call to the net command and Set-DomainUserPassword.

We can see the attacker attempted to set the same password with both Cmd and PowerShell.

Q11

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

We’ll pivot and start a new query for this user name.

We can see that the user account was being used on the WKSTN-02 machine.

Q12

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 don’t have much to work with other than the username, hostname, and timestamps, so we’ll start by making a filter to view powershell execution.

There are only 56 events returned for this query and glancing through them we can see more powershell scripts and executable downloads.

Not too far down the list do we see execution of the Get-DomainGroupMember cmdlet followed by user credentials being set.

Q13

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

Following the powershell execution we found in the previous question, we can see more enumeration being done by the attacker.

Not only does the attacker run Get-DomainGroupMember to look for Domain Admin accounts, but we see the attacker execute Invoke-Sharpkatz immediately after.

Q14

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

Scrolling through the events, we can see the ntlm hash that the attacker used for the Domain Admin account that they discovered.

If we search for this hash, we should find an event that contains the command output where the attacker first discovered this hash.

We also know that his command would be before the attacker attempted to log in with the account, so it should be at, or near, the top of the events (when sorted from oldest-newest).

Analyzing the first packet, we can see the matching string was located in the powershell.command.invocation_details.value field.

Reading through this event we can see the aes256 hash.

Q15

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

Looking through the various command executions, we’ve noticed (or should have) an executable named bomb.exe.

We can see this was also among the final activity of the anna.jones user as well.

The name itself is rather alarming, so let’s filter for events that were created by that executable.

Checking the Event IDs related to these events, we can see 83% were Event ID 11 (file creation).

We’ll filter for Event ID 11 and see if this is indeed the culprit.

The results are a clear indicator of a ransomware attack.

Each file has been appended with the 777zzz suffix.

The total number of returned events tells us how many files were affected, but we can confirm this with another query.