GootBot – Gootloader’s new approach to post-exploitation

IBM X-Force discovered a new variant of Gootloader — the “GootBot” implant — which facilitates stealthy lateral movement and makes detection and blocking of Gootloader campaigns more difficult within enterprise environments. X-Force observed these campaigns leveraging SEO poisoning, wagering on unsuspecting victims’ search activity, which we analyze further in the blog. The Gootloader group’s introduction of their own custom bot into the late stages of their attack chain is an attempt to avoid detections when using off-the-shelf tools for C2 such as CobaltStrike or RDP. This new variant is a lightweight but effective malware allowing attackers to rapidly spread throughout the network and deploy further payloads.

Previously, Gootloader was only observed as an initial access malware, after which attackers would load tools like CobaltStrike or use RDP to spread within the network. Campaigns leveraging GootBot for lateral movement constitute a significant change in post-infection TTPs, as this custom tool enables threat actors to stay under the radar for a longer period. GootBot is downloaded as a payload after a Gootloader infection and has the capability to receive C2 tasks in the form of encrypted PowerShell scripts, which are run as jobs. Unlike Gootloader, GootBot is a lightweight obfuscated PS script, containing only a single C2 server. GootBot implants, each of which contains a different C2 server running on a hacked WordPress site, spread throughout infected enterprise domains in large numbers in hopes of reaching a domain controller. At the time of writing, GootBot has no detections listed on VirusTotal. This shift in TTPs and tooling heightens the risk of successful post-exploitation stages, such as Gootloader-linked ransomware affiliate activity.

• The Gootloader group created a novel tool for C2 and lateral movement dubbed GootBot, which is being used in lieu of other traditional post-exploitation frameworks such as CobaltStrike.
• Currently observed campaigns leverage SEO-poisoned searches for themes such as contracts, legal forms, or other business-related documents, directing victims to compromised sites designed to look like legitimate forums where they are tricked into downloading the initial payload as an archive file.
• After an infection, large amounts of GootBot implants are disseminated throughout corporate environments with each containing a different hardcoded C2 server, making it difficult to block.
• At the time of writing, GootBot implants maintain zero AV detections on VirusTotal, enabling it to spread stealthily.
• Gootloader has served as an initial access provider and successful infections have been known to lead to ransomware.

The Gootloader group, which X-Force tracks as Hive0127 (aka UNC2565), has been active since 2014 and relies on a combination of SEO poisoning and compromised WordPress sites to deliver Gootloader. Gootloader infections provide initial access for other threat actors, including ransomware affiliates, and attacks have led to follow-on payloads such as IcedID, Cobalt Strike, and SystemBC.

X-Force observed the group leveraging SEO poisoning as part of its malicious campaigns, which is a method that threat actors use to manipulate search engine results in order to drive users to compromised websites based on the notion that a search engine’s first results are likely to be accurate, safe and legitimate. Hive0127 typically targets online searches for contracts, legal forms or other business-related documents; for example: “Is a closing statement the same as a grand contract?”. Targets are served a compromised website modified to appear as a legitimate forum at the top of the poisoned search engine results page. Within the forum conversation, the targets are then tricked into downloading an archive file related to their initial search terms, but which actually contains Gootloader.

The following graph is an example of how Gootloader may employ GootBot to spread throughout a network. The analysis sections below detail the different stages of infection:

Gootloader infections start with a user downloading an infected archive, containing a significantly obfuscated JavaScript file, which is Gootloader’s first stage. Upon execution, it drops another JavaScript file in a selected subfolder under the %APPDATA% folder with an unobtrusive English filename. Gootloader does not create a new folder in %APPDATA% but rather selects one that already exists. This selection is not random but calculated based on the number of subfolders that are found in the %APPDATA% folder. It is calculated as follows:

Instead of running the second stage directly, Gootloader triggers a scheduled task to run the JavaScript as well as make it persistent.

The scheduled task has the following parameters:

Once the second stage JavaScript executes, it runs a PowerShell script and the third stage, which gathers system information and uploads it to any of its 10 hardcoded C2 servers. Gootloader uses hacked WordPress sites to run their C2 servers, leading to C2 URL paths ending with “/xmlrpc.php”.

Below is an example of an HTTP request from the malware.

The User-Agent is consistent as well as the presumed malware ID, 3B47772CE3.

The malware expects the C2 to respond with data that contains a PowerShell script that Gootloader executes.

The third stage PowerShell script runs in an endless loop giving the actor the ability to make the C2 respond with varying PowerShell payloads.

One of the payloads X-Force observed is GootBot, a new variant of Gootloader. It features very similar capabilities but comes in the form of a lightweight PowerShell script. Unlike the stage 3 PowerShell script, GootBot only contains a single C2 server address.

GootBot’s strings are slightly obfuscated via a replacement key, as seen in the screenshot below:

Similar to Gootloader, the bot starts by sending a GET request to its C2 server, requesting PowerShell tasks. The first beacon has the following HTTP headers added by the malware:

As a response, GootBot expects a string consisting of a Base64-encoded payload, and the last 8 characters being the task name. It then decodes the payload and injects it into a simple scriptblock before executing it in a new background job using the “Start-Job” Cmdlet. This allows the PowerShell payload to be run asynchronously and without creating a child process, potentially resulting in less EDR detections.

The following screenshot shows the deobfuscated code running the C2 task.

By default, GootBot beacons out every 60 seconds, however, this can be changed by setting a specific string containing “asz” to the child jobs’ information attribute. The same applies to the working directory path, which can be changed with the “asx” signal string.

Once the bot receives a task from the C2, the next loop iteration will start by querying the task result, for every child job requested by the C2 server. If the job has been completed, it will return the job results. If it has not been completed yet, it will send the string “E1”, or the string “E2” if the job cannot be found. The job results are then concatenated for all requested tasks using the following format:

The resulting string is Base64 encoded and obfuscated via a modulo-based algorithm which is similar to a technique observed in previous Gootloader JavaScript samples.

This time, GootBot sends a POST request to its C2 server. If the data is larger than 100,000 chars it is split into multiple requests, formatted as follows:

Again, the bot expects a response containing the next task.

GootBot was also designed to be spread laterally throughout the environment. Once an initial host is infected, GootBot receives a number of scripts enumerating the host as well as the domain. X-Force also observed several scripts using different techniques to spread the embedded GootBot payload to other hosts. GootBots’ C2 infrastructure can quickly generate large numbers of GootBot payloads to be disseminated, each with a different C2 address to contact. These are deployed by lateral-movement scripts in an automated fashion, which may also lead to hosts being reinfected multiple times.

Lateral-movement scripts make use of WinRM in PowerShell, either via WMI or the “Invoke-Command” Cmdlet. Other examples include copying payloads via SMB and the use of WinAPI calls to SCM (Service Control Manager) in order to create remote services and scheduled tasks.

In some cases, GootBot also uses exfiltrated credentials to spread:

Figure: Lateral movement via WinRM Invoke-Command

Figure: Lateral movement via SCM

GootBot has also been shown to use environment variables to store encrypted strings, which further decreases the scripts’ size. In addition, GootBot may also be deployed using a technique to spoof the PowerShell processes’ arguments by creating a new process before writing the malicious script to the processes’ standard input.

GootBot also runs a reconnaissance script as one of its first tasks. It contains the unique GootBot ID for the host.
The following information is pulled together, and returned to the job handler:

• Domain user name
• OS (from registry key)
• If 64bit architecture (checking for x86 dir and also size of int ptr)
• Domain controllers:

• From registry
• From ENV var
• Using [System.DirectoryServices.ActiveDirectory.DomainController]::FindAll

• Running processes
• SID
• Local IP address
• Hostname

The data is formatted with the specified ID. See example data below with ID “FDA8970BA3”:

A Gootloader infection may quickly lead to the deployment of additional tools such as Cobalt Strike, SystemBC and domain compromise scripts including Kerberoasting attacks. Other observed behavior is the exfiltration of the following sensitive information:

• LSASS process dump. Dumped using Procdump or the Minidump functionality of “comsvcs.dll”
• Registry hives SAM, SYSTEM, SECURITY

In addition, Gootloader infections are also known to result in ransomware.

The discovery of the Gootbot variant highlights the lengths to which attackers will go to evade detection and operate in stealth. This is a highly effective malware that allows attackers to move laterally across the environment with ease and speed and extend their attacks. In addition, Hive 0127’s usage of large clusters of compromised WordPress domains makes it increasingly difficult for defenders to block malicious traffic. As Gootloader frequently serves as an initial access provider, awareness of these evolving TTPs and tools is important to mitigate the risk of impactful post-exploitation activity.

• Ensure anti-virus and associated files are up to date
• Organizations should ensure that script block logging is enabled within their enterprise and monitor the relevant Windows event logs for signs of compromise
• Monitor for execution of JavaScript files within downloaded ZIP archives
• Monitor for scheduled tasks using wscript.exe to execute JavaScript files using short names (*~1.JS)
• Monitor network traffic for suspicious HTTP requests to URLs ending with “xmlrpc.php”:
• Suspicious cookie value: <BOT_ID>=<If user is admin: 0/1>
• Suspicious content format: <BOT_ID>=[sX<<random_int>><packet_seq_number>]<data>
• Monitor for lateral movement via WinRM, WMI or SCM
• Disable or monitor the “Start-Job” Cmdlet within your environment.

For more information on X-Force’s security research, threat intelligence and hacker-led insights, visit the X-Force Research Hub.