Welcome to the August 2022 SCYTHE #ThreatThursday! This edition features a GootLoader emulation based on the write-up from our friends at The DFIR Report.
GootLoader, first seen in 2020, initially gained fame as a multi-staged downloader of GootKit malware, an older well known banking trojan. GootLoader and GootKit are sometimes grouped together but separating the initial delivery and loader from the payload proves useful in detecting and tracking variations in later activity. GootLoader has evolved by diversifying both its payload delivery and payload capabilities. Most recently, GootLoader malware is delivered by a Search Engine Optimization (SEO) Poisoning attack where the threat actor uses SEO tactics to move malicious webpages to the top of search results. GootLoader is a significant threat to enterprise environments because it is specifically designed to deliver additional malware to the target(s).
Our GootLoader sample used a JScript based malware package that has been seen in the wild since 2020. It is a multi-stage downloader often seen being used as an initial access vector in other malware campaigns. The threat actor leverages Search Engine Optimization (SEO) poisoning to move malicious or compromised websites higher in search results, increasing the likelihood of a user to visit the site and download the initial payload. Leveraging a multi-stage technique and loading some components only in memory allows the threat actor to split the functionality of its payload. This can make detection efforts more complex as components are not saved to disk on the victim machine.
JScript files have been a common initial stage since December 2020. More recent reporting from Blackberry, indicates that GootLoader scripts have shifted to masquerading as a legitimate jQuery library. What is of note here is that while the functions have not been redesigned, they have been rearranged to render use of a popular deobfuscation tool obsolete.
Threat actor behavior seen in a February 2022 incident is described in detail by The DFIR Report. After establishing initial access and C2, the threat actor performed discovery via Sharphound to discover attack paths in Active Directory. Credential harvesting via Mimikatz and LaZange was observed on multiple devices, paving the way for lateral movement. Network enumeration is attempted via use of Advanced IP scanner. Persistence was achieved by creation of scheduled tasks. Attempts to evade detection were noted, as most commands were encoded and Windows Defender is disabled. RDP and remote WMI were seen to be the primary methods used to interact with targets of interest after the initial compromise.
Note: this emulation plan does not employ lateral movement.
N/A
This is a Windows operating system specific threat targeting businesses/enterprises using Active Directory. If the compromised device is not connected to Active Directory the GootLoader malware deployed would not execute.
The malicious lure documents used to deliver the malware and their placement in niche online forums could also suggest targeting of legal institutions and property development companies in the United States and Germany.
The threat actor first performs some endpoint recon steps, running common command line tools:
The threat actor downloads and executes SharpHound (BloodHound AD discovery) via a PowerShell encoded command, as seen decoded below:
. c:\users\public\sharphound.ps1; Invoke-BloodHound -CollectionMethod All
Next, the threat actor enumerates the endpoint protection software used on the target.
The threat actor then establishes persistence using a scheduled task.
The threat actor also deletes scheduled tasks used by Defender to prevent it from being reenabled and
Microsoft Defender is disabled by the threat actor using unmanaged PowerShell.
PowerShell is used to create named pipes in memory that match names used by the GootLoader malware.
Mimikatz (a credential harvesting tool) is then deployed and executed via PowerShell.
Lazange (another credential harvesting tool) is also used for targeting credentials.
PSExec is used to simulate enabling lateral movement using WMI on a remote target. In the current emulation plan, this action targets the local endpoint using the hostname command in step four. Note that if the “hostname” step is changed to an assign action specifying a hostname, you can have this step execute on a hostname of your choosing.
The threat actor then downloads Advanced IP Scanner using BITS and installs it for use.
Next, cleanup begins. These steps remove tools and reset configuration settings to sane defaults. If running this on a production machine, you should examine these settings to ensure that any cleanup returns the machine to an identical state.
Cleanup continues by re-enabling Windows Defender and updating the LSA value in the registry.
There are several detection opportunities in this plan, many of which are covered by multiple rules. Where appropriate, a defense-in-depth approach should be taken by layering rules, even though one may cover the procedure in its current state.
Some areas of concentration are PowerShell monitoring and alerting. It is recommended to enable PowerShell Script Block Logging as well as PowerShell Module Logging and PowerShell Transcription where possible.
As previously mentioned, this plan executes SharpHound, an implementation of the domain enumeration tool BloodHound. Though there is detection logic below that relies on host visibility, it is recommended to test or engineer alerts from other telemetry such as network traffic analysis for unusual connections to TCP port 445 and high volume of LDAP traffic, Honey Accounts, and domain controller logs, including Event IDs 5145 and 4662. For further detection coverage, see below for an in-depth mapping of detection opportunities to Sigma. As always, tune the rules to each specific environment.
If any of the alerts are detected in the environment, the response team should determine the depth of the Kill Chain, collect artifacts, and answer the following questions:
Once it has been determined how deep the intrusion goes, containment, eradication, and recovery should begin. After recovery, lessons learned should drive additional courses of action (COAs) to thwart the threat should it return, such as implementing additional security controls. As always, please follow your organization's response plan and evidence retention policies. We also recommend leveraging NIST SP 800-61 Rev. 2.
This Threat Thursday post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.
Christopher Von Reybyton is a summer Intern at SCYTHE. He is currently enrolled at SANS Technical Institute working on a Bachelor’s degree in Cyber Security.
Kristen Cotten and Jake Williams of SCYTHE’s CTI team performed QA.
Chris Peacock assisted with Detection Engineering.
SCYTHE provides an advanced attack emulation platform for the enterprise and cybersecurity consulting market. The SCYTHE platform enables Red, Blue, and Purple teams to build and emulate real-world adversarial campaigns in a matter of minutes. Customers are in turn enabled to validate the risk posture and exposure of their business and employees and the performance of enterprise security teams and existing security solutions. Based in Arlington, VA, the company is privately held and is funded by Gula Tech Adventures, Paladin Capital, Evolution Equity, and private industry investors.