October 7, 2024
For this task, we’ve been charged with analyzing an endpoint compromised by a malicious email attachment. We’ll utilize ELK to hunt through Windows Event Logs for indicators of enumeration, malicious activity, and data exfiltration.
On Friday, September 15, 2023, Michael Ascot, a Senior Finance Director from SwiftSpend, was checking his emails in Outlook and came across an email appearing to be from Abotech Waste Management regarding a monthly invoice for their services. Michael actioned this email and downloaded the attachment to his workstation without thinking.
The following week, Michael received another email from his contact at Abotech claiming they were recently hacked and to carefully review any attachments sent by their employees. However, the damage has already been done. Use the attached Elastic instance to hunt for malicious activity on Michael’s workstation and within the SwiftSpend domain!
What was the name of the ZIP attachment that Michael downloaded?
We’ve been told that the initial compromise took place on September 15th, 2023, so we’ll start by limiting our Elastic queries to events on that day.
With our results limited, we can see we have 7,635 events on this date.
We’ll start by checking what log sources are in this dataset.
To do this we’ll open the first event and look at the available fields.
We can see that the event.provider is listed as “Microsoft-Windows-Security-Auditing” for this event. This indicates that we’re looking at Windows event logs. We can also see various other information, such as the hostname of the device, version of Windows, etc.
Knowing that the source of the event is listed under the field “event.provider”, we can use ELK’s visualization tool to see a list of all sources.
To do this we’ll select event.provider from the left pane’s menu. With it selected, we’ll open the visualize tool.
Once the visualize tool is open, we’ll change the graph type to Table and the Horizontal Axis/Rows to a value equal to or greater than the total number of items. Note: Once you have the table graph, set the horizontal axis value to 5 + the value of Other. In our case, that is 22.
The table clearly shows all existing log sources in our dataset. We can now see that there are many PowerShell and Security logs, as well as some Sysmon logs.
Because we have Sysmon logs, we can begin our search for the downloaded file by filtering for Sysmon file creation events (event ID 11).
With the filter in place, we can apply columns to help us quickly decipher the events.
To do this, start by filtering the fields in the left-hand pane for the word file and click the + sign when hovering over file.name.
We can follow the same process for file.directory and process.executable to give us more context as to where the file was created and by what process.
By default, ELK will display the events in reverse chronological order. Meaning that events are presented from Newest -> Oldest. We’ll change this sorting to be from Oldest -> Newest.
To do this, click the timestamp column in the query results and select “Sort Old-New”.
Looking through the results, we can see an email file (.eml) created at 18:40:54.017.
Shortly after, at 18:41:00:069, we can see the creation of a zip file.
Furthermore, we can see that the file was located in Michael Ascot’s path and was created by Outlook.exe.
Looking beyond the zip file, we can also see other very telling and alarming file creation events. Including a ps1 script, another zip, and the use of robocopy on two files. These should all be documented for further investigation.
What was the contained file that Michael extracted from the attachment?
We can start by searching for the name of the zip file in our data.
We’ll add another column for event.code so we can quickly see what type of activity is related to our results.
Our results show 12 matches. The first three are event ID 11, correlating to the file creation events we already investigated. The following two events are Event ID 15 which represents FileCreateStreamHash.
The description of this event, per Microsoft’s documentation, is: This event logs when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream.
We can also note that the time that this .pdf.lnk.lnk file was accessed was only 11 seconds after the creation of the .zip.
What was the name of the command-line process that spawned from the extracted file attachment?
We’ll start by looking at more of the details around these FileCreateStreamHash events. Expanding one of the events for the .pdf.lnk.lnk file, we can see that Explorer’s PID is 3180. Since this was used to open the file, we’ll filter for events with this value as a PID or PPID.
Scrolling through the results, we see a single event following the event ID 15 entries; a process creation event for Powershell.
What URL did the attacker use to download a tool to establish a reverse shell connection?
Let’s expand the event details and view the process commandline.
Given the contents of the process.command_line field, we can see clear evidence of malicious powershell execution.
The attacker downloaded a powershell script from github and executed it.
What port did the workstation connect to the attacker on?
We can see the complete powercat command in the discovered powershell execution and we can look up the script on github if we need more information on the switches.
What was the first native Windows binary the attacker ran for system enumeration after obtaining remote access?
With the discovery of the malicious powershell execution, we’ll pivot our query to investigate the PID associated with the powershell execution.
We can see that the associated PID is 3880.
We’ll take this time to clear up our columns and replace them with ones relevant to process execution.
To remove a column, click the X when hovering over the field name in “Selected fields” on the left-hand pane.
We want to see powershell execution, so we’ll apply columns for process.name, process.pid, process.parent.pid, process.command_line, and process.parent.command_line
In the results, we can see two new PIDs, 6492 and 9060. We’ll add these to our current filter.
The output shows numerous commands executed from the powershell process with PID 9060.
Based on the output we can see the attacker used multiple tools to enumerate the system.
What is the URL of the script that the attacker downloads to enumerate the domain?
Back in Q1, we noted multiple suspicious files / file creation events.
Among those files were a couple of powershell scripts.
Let’s circle back to those files and have another look at those.
Among the results, and one that was a red flag earlier in the investigation, is PowerView.ps1.
PowerView is a well-known tool in the PowerShellEmpire toolkit and is used for enumeration.
With that, let’s filter for events containing the string PowerView.ps1 to see what we get.
We get over 200 results but checking the event IDs we can see they are all powershell events (aside from the file creation).
We could start by checking the first event or applying a new column to help us quickly look for any interesting information.
Because we are dealing with event logs from two different sources (PowerShell and PowerShell Operational) we’ll opt to apply the “message” field as a column. This way we don’t have to worry about fields that may not be present in both event types.
And with that, we can see an obvious download of the file from github.
What was the name of the file share that the attacker mapped to Michael’s workstation?
Unfortunately, there are no results for Event ID 5142 which logs when a network share object has been added.
We know, however, that the attacker is using powershell for execution, so we’ll filter for process creation events spawned by PowerShell.
We can see many of the activities we’ve previously discovered, such as the execution of systeminfo, whoami, etc.
One noteworthy new finding, however, is the use of net.exe to add a mapped share.
We can see that the attacker mapped the share to drive Z:.
What directory did the attacker copy the contents of the file share to?
We can see the following command uses Robocopy on . (the current directory) and copies it to a directory named exfiltration.
We can also apply a new column for process.working_directory so that we can quickly see where the commands were executed. This makes it clear that the robocopy was used to copy the contents of the mapped Z drive.
What was the name of the Excel file the attacker extracted from the file share?
We discovered file-creation events that were spawned by Robocopy earlier in the investigation.
We can, however, take it a step further by altering our current filter to include file creation events.
With this filter applied, we’ll add a column for file.name and file.directory.
We can now see that after robocopy was executed, two new files were created in the Downloads\exfiltration directory.
What was the name of the archive file that the attacker created to prepare for exfiltration?
Among our output in Q10, we can see that net.exe was used to remove the mapped drive, after which a new zip file was created in the exfiltration directory we discovered earlier.
What is the MITRE ID of the technique that the attacker used to exfiltrate the data?
Following the creation of the zip file, we can see that nslookup was being used from within the exfiltration directory.
Nslookup is a DNS tool, and judging by the commandline, it is being used to exfiltrate data over DNS.
We can see what looks like an encoded portion of data followed by a suspicious domain.
Checking the MITRE ATT&CK Framework we can see this correlates to the Exfiltration Over Alternative Protocol technique.
Note: you can read more about this technique here: https://attack.mitre.org/techniques/T1048/
What was the domain of the attacker’s server that retrieved the exfiltrated data?
We took note of the domain used in this exfiltration in the previous question.
The attacker exfiltrated an additional file from the victim’s workstation. What is the flag you receive after reconstructing the file?
Looking at the nslookup events, we can see that each piece of encoded data is the same length.
We can surmise that this is base64 encoded data (the == on the final nslookup event also indicates base64)and is being broken up into fixed-length chunks.
On a brief aside, we can also look for events containing the malicious domain to see if we can find the powershell command responsible.
Sure enough, we can see powershell execution, converting data to base64 and splitting it into 30-character chunks before exfiltrating with nslookup.
Scrolling down, we can see two changes in the pattern.
Not only does the length of the encoded data change, there is a 15-second gap before the final two queries.
This suggests that the shorter length marks the end of the first file, followed by the exfiltration of a separate file 15 seconds later.
We can take the encoded portions of the final two events and decode them in cyberchef to uncover the final flag.
Previous post
Next post