{"id":25686,"date":"2025-01-16T11:21:08","date_gmt":"2025-01-16T19:21:08","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2025\/01\/16\/news-19409\/"},"modified":"2025-01-16T11:21:08","modified_gmt":"2025-01-16T19:21:08","slug":"news-19409","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2025\/01\/16\/news-19409\/","title":{"rendered":"Gootloader inside out"},"content":{"rendered":"

Credit to Author: Gabor Szappanos| Date: Thu, 16 Jan 2025 17:00:02 +0000<\/strong><\/p>\n

\n

The Gootloader malware family uses a distinctive form of social engineering<\/a> to infect computers: Its creators lure people to visit compromised, legitimate WordPress websites using hijacked Google search results, present the visitors to these sites with a simulated online message board, and link to the malware from a simulated \u201cconversation\u201d where a fake visitor asks a fake site admin the exact question that the victim was searching for an answer to.<\/p>\n

Most of the infection process is driven by code that runs on the compromised WordPress server\u00a0 and another server we have previously named \u201cthe mothership\u201d<\/a> that orchestrates an elaborate and complex dance to dynamically produce a page that seemingly answers the exact question you\u2019re asking<\/a>. Gootloader\u2019s operators make behind the scenes, almost unnoticeable changes to the compromised WordPress sites that cause those sites to load the extra content from the mothership.<\/p>\n

Every aspect of this process is obfuscated to such a degree that even the owners of the compromised WordPress pages often cannot identify the modifications in their own site or trigger the Gootloader code to run when they visit their own pages. At the same time, unless you control one of the affected WordPress sites, it can be very difficult (if not impossible) to get a hold of this code to study it: The modified WordPress database entries and PHP scripts that comprise Gootloader reside only on the compromised server, where security researchers normally cannot access them (barring physical or shell access to the server, itself).<\/p>\n

Sophos X-Ops has previously reported on various aspects of Gootloader<\/a>. However, Sophos X-Ops has reconstructed how Gootloader\u2019s server-side operations function, using breadcrumbs and clues left by both the threat actors (and by other security researchers) published in open-source tools around the internet. We have pulled this collective knowledge together into this report.<\/p>\n

In this post, I\u2019ll explain how I was able to reconstruct how the malicious SEO works; how the landing page code on the initial, compromised website validates visitors then redirects some of them to a second website; how the Gootloader operators use the second website to generate a realistic-looking message board dynamically; how the multi-stage infection process works; and how all of these parts are orchestrated by a \u201cmothership\u201d server, controlled by Gootloader\u2019s operators, to control who gets attacks, and which visitors get bounced back to Google\u2019s homepage.<\/p>\n

Gootloader\u2019s poisoned SEO<\/h2>\n
\"A<\/a>
A list of Gootloader JScript filenames, which correspond to the search query that led victims to download them<\/figcaption><\/figure>\n

Gootloader has been using a virtually unchanged malicious SEO method for nearly eight years<\/a>. When we have done threat hunting in the past, we\u2019ve used our own telemetry to find the key phrases Gootloader used to deliver a malicious JScript file: Gootloader always names these first-stage files to match the search phrase that led the victim into the trap.<\/p>\n

Finding new names for these first-stage downloaders also means discovering new phrases the Gootloader operators are using as lures. It was VirusTotal\u2019s live hunting and retrohunting services that led us to these updated payloads, despite the fact that Gootloader\u2019s creators use code obfuscation to an almost absurd degree. We had to come up with creating threat hunting queries such as the following Yara rule:<\/p>\n

rule gootkit_js_stage1  {  \u00a0\u00a0 strings:  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $a1 = \/function .{4,60}{return .{1,20} % .{0,8}(.{1,20}+.{1,20});}\/  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $a2 = \/function [w]{1,14}(.{1,14},.{1,50}) {return .{1,14}.substr(.{1,10},.{1,10});}\/  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $a3 = \/function [w]{1,14}(.{1,50}) {return .{1,14}.length;.{1,4}}\/  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $a4 = \/function [w]{1,14}(.{0,40}){.{0,40};while ([w]{1,20} < [23][d]{3}) {\/  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $b1 = \/;WScript.Sleep([d]{4,10});\/  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $b2 = \/function [w]{1,14}(.{0,40}) {.{0,40};while([w]{1,20}<([w]{1,14}*[d]{1,8})){[w]{1,14}++}}\/  \u00a0\u00a0 condition:  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 all of ($a*) and any of ($b*)  }<\/pre>\n
While this rule was effective at the time of our research, Gootloader\u2019s operators have subsequently modified the JScript to render this search obsolete. In order to stay on top of these changes, we needed to analyze newer versions of the heavily obfuscated JScript code.<\/p>\n
As part of the obfuscation, the attackers break up the code. Every elementary capability is implemented in a separate function, initially featuring randomly generated variables, then later switching to variable names selected from a dictionary.<\/p>\n
In the example above, $a1, $a2<\/em>, and $a3<\/em> match functions that performed the elementary tasks in the decryptor.<\/p>\n
$a1 matches the function that determines the parity of a number, matching this obfuscated form:<\/p>\n
function dance(expect,support,thin,foot,had){return expect % (magnet+magnet);}<\/pre>\n
$a2 matches the function that returns a substring from a string, matching this obfuscated form:<\/p>\n
function supply(spoke,seed,your,build,charge,carry,sat) {return spoke.substr(seed,your);}<\/pre>\n
$a3 returns the length of a string, matching this obfuscated form:<\/p>\n
function verb(consonant) {return consonant.length; }<\/pre>\n
$a4 implements the main decoder loop: it contains the length of the encoded part (somewhere between 2000 and 4000 bytes), matching this obfuscated form:<\/p>\n
function wave(down){against=kill;hole=\"\";while (against < 2146) {spell=cause(down,against);hole=cool(hole,spell,against); against++; }return hole;}<\/pre>\n
The code used long delays to make dynamic analysis more difficult, extending to hours the time needed to properly run the code.<\/p>\n
Initially, Gootloader used the WScript.Sleep function (matched by $b1) to create this delay. Over time, Gootloader\u2019s creators replaced this with a less recognizable implementation (matched by $b2), like this function, which essentially increments a counter for a very long time:<\/p>\n
function string2(evening6) {  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sky0=25;  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 while(sky0<(evening6*4921)){  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sky0++  \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }  }<\/pre>\n
Even though the code is highly obfuscated, knowing the structure of the code enabled us to create the above seemingly loose Yara rule \u2013 which caught thousands of first stage downloader scripts with zero false positives.<\/p>\n
Once we had the original file names, we had the search terms. With those, we could find the landing pages: The Gootloader operators were successful in manipulating the search results and the compromised landing sites, such that they end up near the top of the search results (even in the first result, as in the example below):<\/p>\n
\"Gootloader<\/a>
Gootloader has poisoned search results in multiple languages, including German, French, and Korean<\/figcaption><\/figure>\n
How did the malicious pages end up at the top of the search results?<\/h3>\n
We were able to learn how the malicious SEO was so effective by inspecting the HTML source of the search landing pages.<\/p>\n
There is a hidden element, the name of which is actually a server ID, used at many places in the code (a47ec48<\/em> in the following example). It starts with the letter \u2018a\u2019 followed by 6 hexadecimal characters:<\/p>\n
<div id=\"a47ec48 \">  ...  <div><script type=\"text\/javascript\"> document.getElementById(\"a47ec48 \").style.display=\"none\"; <\/script><\/pre>\n
\"Source<\/a>
Source of the Gootloader landing pages reveal a number of different search terms and phrases the threat actors wanted search engines to index. The linked subpages (selected with green) don’t actually exist. The injected WordPress code defines a few hooks, one of them is for non-existing pages. This will serve the fake forum discussion, when the victim clicks on the search result<\/figcaption><\/figure>\n
That hidden element had links (selected with green) and the matching targeted search terms (selected with brown):<\/p>\n
This hidden element will not be visible to human webpage visitors. But search engine crawlers see and process it, which tricks the search engines into treating the website as if it provides relevant content on the poisoned search term, thus ranking the site high in the search results.<\/p>\n
Compromised landing page code<\/h3>\n
When security vendor Sucuri wrote up a blog post about an earlier generation of Gootloader<\/a>, it included this screenshot:<\/p>\n
\"<\/a>
A screenshot of the source code from a Gootkit\/Goodloader landing page. Image courtesy of Sucuri Research.<\/figcaption><\/figure>\n
The report (and screenshot) revealed three promising strings:<\/p>\n