This blog post was authored by Hasherezade and Jérôme Segura
On November 23, we received an alert from a partner about a resurgence of Gootkit infections in Germany. Gootkit is a very capable banking Trojan that has been around since 2014 and possesses a number of functionalities such as keystroke or video recording designed to steal financially-related information.
In this latest campaign, threat actors are relying on compromised websites to socially engineer users by using a decoy forum template instructing them to download a malicious file.
While analyzing the complex malware loader we made a surprising discovery. Victims receive Gootkit itself or, in some cases, the REvil (Sodinokibi) ransomware. The decision to serve one or the other payload happens after a check with the criminal infrastructure.
Gootkit attacks observed in Germany
Security researcher TheAnalyst was the first to publicly identify an active campaign in November using a sophisticated loader that was eventually attributed to Gootkit, a banking Trojan not observed in the wild for some time. Germany’s Computer Emergency Response Team CERT-Bund later confirmed that German users were being targeted via compromised websites.
Around the same time, we started receiving reports from some of our partners and their ISPs about Gootkit-related traffic. We were able to confirm Gootkit detections within our telemetry that were all located in Germany.
After a couple of days, we remediated over 600 unique machines that had been compromised.
Fake forum template on hacked websites
The initial loader is spread via hacked websites using an interesting search engine optimization (SEO) technique to customize a fake template that tries to trick users to download a file.
The template mimics a forum thread where a user asks in German for help about a specific topic and receives an answer which appears to be exactly what they were looking for. It’s worth noting that the hacked sites hosting this template are not German (only the template is); they simply happen to be vulnerable and are used as part of the threat actor’s infrastructure.
This fake forum posting is conditionally and dynamically created if the correct victim browses the compromised website. A script removes the legitimate webpage content from the DOM and adds its own content (the template showing a link to a file to download).
There is a server-side check prior to each visit to the page to determine if the user has already been served the fake template or not, in which case the webserver will return legitimate content instead.
Fileless execution and module installation
The infection process starts once the victim executes a malicious script inside the zip archive they just downloaded.
This script is the first of several stages that leads to the execution of the final payload. The following diagram shows a high level overview:
Stage 1 – The first JavaScript
The first JavaScript is the module that has to be manually executed by the victim, and it has been obfuscated in order to hide its real intentions. The obfuscation consists of three layers where one decodes content for the next.
The first stage (a version with cleaned formatting available here) decodes the next element:
The decoded output is a comma-separated array of JavaScript blocks:
There are four elements in the array that are referenced by their indexes. For example, the element with the index 0 means “constructor”, 1 is another block of JavaScript code, 2 is empty, 3 is a wrapper that causes a call to a supplied code.
Block 1 is responsible for reading/writing registry keys under “HKEY_CURRENT_USER\SOFTWARE\<script-specific name>”. It also deobfuscates and runs another block of code:
This fragment of code is responsible for connecting to the C2. It fetches the domains from the list, and tries them one by one. If it gets a response, it runs it further.
The above downloader script is the first stage of the loading process. Functionality-wise it is almost identical in all the dropped files. The differentiation between the variants starts in the next part, which is another JavaScript fetched from the C2 server.
Stage 2 – The second JavaScript (downloaded from the C2)
The expected response from the server is a decimal string, containing a pseudorandom marker used for validation. It needs to be removed before further processing. The marker consists of “@[request argument]@”.
After conversion to ASCII, the next JavaScript is revealed, and the code is executed. This JavaScript comes with an embedded PE payload which may be either a loader for Gootkit, or for the REvil ransomware. There are also some differences in the algorithm used to deobfuscate it.
The downloaded code chunk is responsible for installing the persistent elements. It also runs a Powershell script that reads the storage, decodes it and runs it further.
Stage 3 – The stored payload and the decoding Powershell
The authors diversified the method of encoding and storing the payload. During our tests we observed two ways of encoding. In one of them, the PE is stored as a Base64 encoded string, and in the other as a hexadecimal string, obfuscated by having certain numbers substituted by a pattern.
The payload is usually stored as a list of registry keys, yet we also observed a variant in which similar content was written into a TXT file.
Example of the payload stored in a file:
The content of the file is an obfuscated Powershell script that runs another Base64 obfuscated layer that finally decodes the .NET payload.
Example of the Powershell script that runs to deobfuscate the file:
Below we will study two examples of the loader: One that leads to execution of the REvil ransomware, and another that leads to the execution of Gootkit.