When we last wrote about Gootloader, we detailed how the threat actors’ use of poisoned Google search results direct people who search for specific, business-related terms (in English, German, French, and Korean) into a network of compromised WordPress websites. Those websites then serve up a malicious file by means of a clever social engineering trick. If a person then double-clicks the malicious file, their computer is then infected with malware that never touches the filesystem, and maintains persistence through a convoluted process in which the malicious code gets stored in the Windows registry.
Since we published the initial research in March, the Gootloader actors have not slowed down their efforts. In this followup to that research paper, we wanted to highlight some of the server-side behavior of the compromised WordPress sites that make up the bulk of the threat actors’ social engineering and malicious SEO efforts. With hundreds of websites hosting the Gootloader code at any given time, we just don’t know how the attackers initially gain access to these websites, belonging to individuals and businesses, but we’ve obtained some of that source code to analyze.
This followup to our coverage will look under the hood, and explain how the malicious code running on the compromised sites gives the threat actors the ability to target a narrow audience of potential victims, as well as produce the polished-looking fake message board pages that purport to offer the unwary visitor exactly what they were originally searching for.
Search engine de-optimization
The first part of the attack involves tricking Google (the apparent primary target, since the poisoned results don’t typically appear in other search engines’ results pages) into indexing the compromised websites as if they were the best source for information on the narrow list of terms the attackers choose to emphasize and promote through search.
This is no rudimentary process, as the search results that deliver Gootloader pages are often the top result for the specific query that leads victims to them.
Take, as just one example, this search query (in the German language) for downloads of MIDI music files. The result in this screenshot points to a website called micbd.com.
If a visitor were to browse to this website not by following the Google search result, but by typing in the domain into the Address Bar manually, they would see that the page belongs to an industry trade organization representing cannabis businesses in the US state of Michigan. It certainly doesn’t seem to have any relationship to the search result for MIDI file downloads in the German language.
However, taking a look at the source code of that page reveals that someone has crafted a large series of search terms (highlighted in green) and embedded them within the website’s front page as links (highlighted in red) that point to nonexistent pages purportedly hosted within the website. None of these links will appear when you browse to the page, but search engines index them, which is how the attackers poison the results. There’s also a JavaScript, about two-thirds of the way down the page, document.getElementById(“a47ec48”), which has also been placed in the webpage by the threat actors.
As we’ve already said, we don’t know exactly how the threat actors gain access to these websites and embed this code into pages on the site, but the malware itself has password stealing functionality, so it’s quite possible that they’re simply using whatever websites they can obtain through their own activity. They may also be obtaining access to phished or otherwise stolen admin credentials for websites from other criminals.
In addition to the malicious SEO terms, the attackers embed some PHP scripting code into the WordPress backend, so that the scripts could conceivably run on any page. One of the malicious PHP scripts the attackers add to the website is a simple PHP command shell, which could serve to preserve the attackers’ access to compromised pages if they lose whatever other access they may have. The attackers perform an HTTPS POST request with a base64-encoded string of commands, which the WordPress installation will then execute in the context of its process on the server. The variable $pposte holds the name of the parameter that gets executed.
The attackers also place a string into the pages that matches this regex filter: /j\$k([0-9]{1,10})j\$k/.
This marker serves as placeholder where the link to a script that will render the malicious page will be inserted later. This marker is later removed from the page source using this command.
preg_replace("/j\$k([0-9]{1,10})j\$k/", ''
Further on, the script defines filters for WordPress events, which trigger the execution of handler functions on certain conditions. For example, the following trigger fires once the WordPress environment has been set up: the invoked code initializes the backupdb_wp_lstat database table at startup.
add_action("wp", "qvc5");
This is part of the code form qvc5() that initializes the backend databases used by Gootloader:
if ($table_prefix < > "backupdb_".$qvc4) {
$table_prefix = "backupdb_".$qvc4;
wp_cache_flush();
$qvc5 = new wpdb(DB_USER, DB_PASSWORD, DB_NAME, DB_HOST);
$qvc5 - > set_prefix($table_prefix);
A Virustotal search for content:”SELECT * FROM backupdb_” gives a couple of files (from interfree.ca) with this error message:
It shows that the criminals are likely using the database backupdb_wp_lstat, which must have been subsequently removed from the server.
The procedure qvc5 also filters on is_404 – for any non-existing subpage.
Likely this is how the Google search results are served: the subpages don’t exist physically on the server (it appears that the attackers don’t control the files and directories on the compromised servers, only the WordPress database contents), but this handler will provide the malicious content served through the pages themselves.
This script is used to filter the content of a post after it is retrieved from the database, but before it is printed to the screen, and inserts the malicious Javascript tag in place of the j$k…j$k markers markers within the source, for example:
add_filter('the_content', 'qvc0');
The following two values hold the content of the output buffer until the header and footer is there, then remove the j$k…j$k markers and inserts the SEO poisoning div element into the most recent 20 posts.
add_action("wp_head", "qwc7");
add_action("wp_footer", "qwc5");
As a result, the malicious code will appear in the SEO-poisoned pages and, additionally, the most recent pages will contain the hidden element. Together, these serve to raise the website’s profile in web search results.
Contacting the mothership
All of these behaviors, so far, rely solely on code installed into the WordPress database on the compromised sites. However, there’s another machine involved in the attack, which we’re calling the mothership. The mothership acts both as a traffic cop, and delivers the malicious code that renders the page that looks like a message board post.
As traffic cop, the mothership only wants to serve malicious code to visitors who have (a) clicked a Google result, in (b) a geographically targeted region of the world, using (c) a Windows browser User-Agent. We’ve observed Gootloader target the US, Canada, Germany, France, and South Korea, delivering different payloads to different regions of the world.
On preparing the requested web page, the malicious event handler hooks build a request to the mothership, reporting the following parameters of the initial request, all in base64 encoded form:
- a: Unique server ID
- b: IP address
- c: user agent
- d: referrer string
The IP address of the source of the request (the address of the victim PC) is used for filtering out the unwanted countries. The referrer string will contain the original search terms as passed on during the click through process.
This will end up in a query that looks like this:
(in this particular case the referrer string will be the base64 encoded value of: “google/?q=cisco_wpa_agreement”)
After that the response from the server is processed.
The mothership response contains two segments: one for the HTML header elements, the other for the body. The two are separated by a <sleep> marker. The header part contains multiple elements, those are separated by | characters. Using the returned content the landing page code will gather the HTML content:
The script generates a blocklist on the fly when the visitor first visits the web page. This functionality blocks the IP address where the request came from (so a researcher, for instance, cannot easily visit the site twice from the same machine). But it doesn’t only block the one IP address; They also block repeat visits by a range of IP addresses in the same subnet as the visitor. 
Rendering the fake forum page
The only visible malicious content in the source code compromised landing page is a simple inserted JavaScript tag, for example:
https://powerstick[.]com/main/?ad94610=1174868
The number that is the value of the parameter (1174868 in the above example) is used in many places in the pages source (for example in the placeholder variable) and may be a unique key for the infected server:
This script tag will invoke the landing page renderer code.
This linked script deletes the original content of the HMTL page:
and replaces it with the fake forum text…
…which contains the download link for the first stage Javascript:
The result will look like a conversation on the blog, with a link of the alleged search term (“kostenlos midi songs herunterladen” in this example), and a seemingly satisfied customer, together with the download link of the first stage JavaScript downloader.
This link will connect to the server that is hosting the first stage download script, which is usually somewhere other than the compromised WordPress site hosting the bogus forum page content.
How the first stage downloader script works
The first stage download script (hosted on links using filenames that include down.php, join.php, thank.php or about.php) simply relays the incoming request to the mothership:
In the samples that we found we observed two mothership addresses, 5.8.18[.]7 and my-game[.]biz (the my-game website is hosted on this IP address). Notably, they refer to the same web location, but only the compromised landing page code refers to it by domain name, and the first stage downloader refers to it by IP address.
The request sent to the mothership will return the first stage downloader Javascript in ZIP packaged form. Because the original referrer string is passed all the way to the mothership, it will receive the original search terms, and returns a Javascript payload with a file name matching these search terms.
As a side effect, we could tell from the observed file names which were the most frequently poisoned search terms for, for example, German victims.
The mothership server plays the central role in the early stages of the infection process: it provides the content that the compromised sites deliver to the victim computer.
This server has served as the mothership throughout the life of Gootloader, starting from the early sightings back in 2018, up to the latest known campaigns. From 2014 until 2018, the domain name belonged to a Russia-based group of videogame players. While the site has been used for malicious purposes these past three years, there’s still a clan of Counterstrike players whose public profile still lists the website.
What can anyone do about Gootloader?
Aside from having a modern endpoint protection tool installed on your Windows computer, there are some mitigations that people can use to try to minimize their risk of being caught up in a Gootloader attack.
Unfortunately, all of them come with some caveats and none of them offer a quick fix for the problem.
Not everyone will be familiar with the visual appearance of the Gootloader fake forum pages, though this is an easy way to recognize the attack before anything has happened on a computer. Tools like script blockers are challenging for some people to use and make the web more inconvenient in general, though they do offer some protection.
The real problem here is how readily the attackers have been able to float their malicious search results to the top of Google searches. Until Google addresses the methods by which the Gootloader threat actors have managed to manipulate their results, the problem seems like it will persist indefinitely.
Indicators of compromise
SophosLabs has published indicators of compromise for Gootloader on its Github page.
