Overview

The boogeyman is back, and we’ve been tasked with analyzing a malicious document, analyzing its payload stages, and analyzing a memory capture of the infected endpoint.

Scenario

After having a severe attack from the Boogeyman, Quick Logistics LLC improved its security defences. However, the Boogeyman returns with new and improved tactics, techniques and procedures.

Maxine, a Human Resource Specialist working for Quick Logistics LLC, received an application from one of the open positions in the company. Unbeknownst to her, the attached resume was malicious and compromised her workstation.

The security team was able to flag some suspicious commands executed on the workstation of Maxine, which prompted the investigation. Given this, you are tasked to analyse and assess the impact of the compromise.

Q1

What email was used to send the phishing email?

We can get the sender’s email by analyzing the contents of the file. One way to do this easily is to use grep.

Q2

What is the email of the victim employee?

We can repeat the command from Q1 and change the grep to search for “To:”.

Q3

What is the name of the attached malicious document?

Same as before, this time we’ll grep for the word Attachment and add the -i so the search is not case sensitive.

Q4

What is the MD5 hash of the malicious attachment?

We’ll export the attachment from the email and run md5sum on the file.

Q5

What URL is used to download the stage 2 payload based on the document’s macro?

For this assignment, we’ve been provided with two tools, Volatility and OleVBA.

OleVBA parses OLE and OpenXML files (Word, Excel) and detects VBA macros. It extracts the commands and reports on its findings.

You can read more about olevba here - https://github.com/decalage2/oletools/wiki/olevba

We can see that OleVBA discovered commands to download a file from boogeymanisback[.]lol and executed the file with wscript.exe.

Furthermore, we can see that the file was saved to C:\ProgramData\ and, although the file was originally named update.png, it was saved as update.js.

Q6

What is the name of the process that executed the newly downloaded stage 2 payload?

We analyzed the results in the previous question and discovered the process used to execute the payload.

Q7

What is the full file path of the malicious stage 2 payload?

We discovered the full path used to download and execute the file in Q5.

Q8

What is the PID of the process that executed the stage 2 payload?

For this question, we’ll need to analyze the memory capture with Volatility.

We’ve been provided with a copy of Volatility 3, so we won’t need to worry about profiles.

We can view available Windows plugins by running the command: vol -f <memory/dump/file> windows.

We’ll start by running the pstree plugin to get an easy-to-read view of the process tree that was running on the compromised endpoint.

We can see Word was executed followed by wscript and updater.exe.

The question has asked us for the PID of the process that executed the stage 2 payload, so we’re looking for the PID of Wscript.exe

Note: If you are unsure of the meaning of a column, check the first line of the volatility output for column headers.

Q9

What is the parent PID of the process that executed the stage 2 payload?

We can see the PPID in the output of pstree.

Q10

What URL is used to download the malicious binary executed by the stage 2 payload?

To determine what URL was used by stage 2, we’ll need to extract the javascript file.

To use the dumpfiles command we’ll need to determine the address of the file. We can use filescan for this. Of course, we’ll also grep the output for the term update, case insensitive, to narrow down the results.

Aside from updater.exe which we’ve already seen in the suspicious chain of process execution, we can see one file named update[1].png.

This file is located in AppData and INetCache. The inet directory holds a cache of files, and we discovered that the original name of this file on the malicious server was update.png.

With that knowledge, we’ll extract the file and see if it is the javascript file we’re looking for.

As mentioned, we’ll need to copy the address and supply it to the dumpfiles plugin.

A quick check of the file type with the file command confirms that it is a plaintext file.

We can now read the file and discover what the stage 2 payload contained.

We can see that the attacker set a location to C:\Windows\Tasks, downloaded a file, and named it updater.exe.

We can also see that the attacker used wshell.run to run a command to modify the registry.

Q11

What is the PID of the malicious process used to establish the C2 connection?

Knowing that updater.exe is the next stage of the malware, we’ll check for network connections used by this executable.

To do so, we’ll run the netscan plugin and grep it for updater.exe.

We can see multiple connections to 128.199.95.189 were created by this executable.

We can also see the PID associated with the process in our netscan results.

Q12

What is the full file path of the malicious process used to establish the C2 connection?

We already discovered where this executable was saved when we analyzed the javascript file.

However, we can confirm this by using the cmdline plugin to view command history.

Q13

What is the IP address and port of the C2 connection initiated by the malicious binary? (Format: IP address:port)

We discovered this in Q11.

Q14

What is the full file path of the malicious email attachment based on the memory dump?

We can use the filescan plugin to determine the full path of the file and use grep to filter out all the other noise. Note: the filepath is missing the drive letter, so just prepend C: to the path

Q15

The attacker implanted a scheduled task right after establishing the c2 callback. What is the full command used by the attacker to maintain persistent access?

We can extract the updater.exe file with dumpfiles as we did previously and check VirusTotal and other online tools to see if we can find any information about what task was created.

We can see that the malicious executable is likely Sharpire, a C# version of Empire.

Researching Sharpire and its scheduled tasks provides some hits but nothing fruitful.

The hint suggests to search for strings associated with scheduled task creation, so we’ll have to resort to grepping the entire memory dump for the command.

The output of the grep was a bit messy, so we’ll clean it up by using strings instead of cat.

And there we have it, the task created by the attacker!

Reading through the output we see that there is also a string that reads “Schtasks persistence established using listener http stored in HKCU:\Software\Microsoft\Windows\CurrentVersion\debug with Updater daily trigger at 09:00”.

Google searching for this phrase results in some information about the C2.

https://securitydatasets.com/notebooks/atomic/windows/persistence/SDWIN-190319024742.html