We recently had a new client come to us with a rather peculiar issue on their WordPress website: They were receiving unwanted popup advertisements but only when the website was accessed through links posted on FaceBook. Initially we thought that this must be a rogue ad coming through an otherwise legitimate advertising network but it turned out to be a very well crafted and hidden spam injection.

In this post we will review this infection, outline the steps we took to find it, and explain how to prevent your website from falling victim to spam injections.

Identifying the infection

Other than the reported behavior it was a very difficult infection to reproduce.

The ads wouldn’t appear all of the time and were very inconsistent. Some users reported that it would only appear on mobile devices, while others were certain it was displaying for other user agents as well. What is certain is that this behavior is fairly consistent with bogus advertisements.

However, once we clicked on one of the links from their FaceBook page we were greeted with exactly what the client was reporting:

Reproducing the behavior and viewing the symptoms is an important part of the remediation process: It allows us to monitor and inspect the network traffic which might lead us to find out where it originates. It also enables us to confirm that the issue resides on the website itself and not anything on the client’s end such as an infected browser or workstation.

Integrity check reveals injected code

One of the most useful tools in our arsenal for identifying new malware samples is the integrity check: a verification process by which we verify the integrity of the core, plugin and themes.

In this case we noticed that the following file had a mismatched checksum:

• ./wp-content/plugins/really-simple-ssl/rlrsssl-really-simple-ssl.php

With over five million installations the really-simple-ssl WordPress plugin is an enormously popular plugin which helps WordPress website administrators configure their websites to use HTTPS encryption. There are no known vulnerabilities with this plugin ever recorded by WPScan, however just like any other piece of software it can be modified by attackers to make it do things it’s not supposed to do (in this case, unwanted spam popups).

Sure enough, when inspecting the file and comparing it to a known good copy we identified an injected chunk of code:

Let’s take a closer look at this code and see what it’s doing!

Injection analysis

It would be easy to overlook this during a cursory review — there’s no big, ugly encoded chunks of data nor any obfuscation in use as is common with website malware.

However, further inspection reveals it’s doing some questionable things that certainly has nothing to do with helping WordPress website owners deploy SSL/HTTPS encryption.

We can see that it’s probing for suitable directories to upload temporary files using file_put_contents. Most questionable of all, though, is this part right here:

define ('ph_stream', pack ("H*", $wpdb->get_var("SELECT option_value FROM ct_options WHERE option_id=719")));

Similar code was also found in two additional files in the environment:

• ./wp-content/themes/clientstheme/inc/runtime.php
• ./wp-content/mu-plugins/health-check-troubleshooting-mode/health-check-troubleshooting-mode.php

The pack (“H*” string indicates that it’s converting a hexadecimal representation of data to a binary string. The value passed to “pack” is obtained by executing an SQL query by using the $wpdb global variable and grabbing the contents of a very specific database value, namely option_id=719.

Well, that’s weird. I wonder what’s in option_id 719? 🤔

hex2bin in the database

After uploading our friendly neighbourhood database management tool and searching for 719 we came across this questionably named wp_options value with the option name “sticky hash“.

Sure enough it was a huge chunk of hex2bin data. Let’s throw that into a parser so we can actually read it:

The original sample was one big ugly chunk of one-line PHP code but I’ve beautified it so it’s easier to read. There is a lot of code here but this is the most salient part. We can see above that the PHP function inserts JavaScript code which appears to be designed to track visitors and send information about their activity to that cdnregion[.]com server.

Earlier in the file it also includes a handy dandy login stealer:

The function is called when a user attempts to log into the website. If the authentication is successful it retrieves the user’s role from the authentication result, where the pilfered information is ultimately sent to the attacker’s server using the x_send function, including:

• User name
• Password
• IP address
• User role
• User agent string

It also sets a cookie named zPHqaLq to the user with the value of pnkA4FBG240i with a maximum age of 31536000 seconds (or one year) which is likely used to keep track of the users on the site.

Magbo links in hex2bin dump

Referenced a number of times within the hex2bin dump is the string magbo_links:

This appears to be integral to this spam injection. As it turns out, after doing a little digging, Magbo is a “Russian fully automatic system for selling and buying digital goods between anonymous users.” some of which appears to be only available on the dark web using browsers such as Tor.

The code appears to create a mapping between specific URLs and specific ad links. Each key is a URL and each value is a link that corresponds to that URL. The specific details of how the ad links are injected depend on the content of the page being served.

• If the current URL is the root URL (/), the function looks for a specific HTML tag (ie. <p class=”readmore” style=…>) and injects the ad links before that tag.
• If the current URL matches a specific regular expression (specified by the attackers) the function injects the ad links directly into the content.

Some of the spam that we’ve seen associated with this infection includes fake IDs, torrent websites, and – of course – kitchenware. After all, who wouldn’t fancy a brand new crock pot?

Injected JavaScript

We can also see the actual JavaScript that is injected into the WordPress site using the code above:

This is performing a number of critical actions:

• Manipulating iframes within the posts of the website
• Checking to see if the wordpress_test_cookie is present
• Creates a new script element, sets the source to a URL which includes encoded data and appends that to the head of the document

In other words, the code allows the attackers to display the unwanted ads/popups on the website. It also ensures that it is only displaying to actual human visitors (via the cookie check) rather than bots.

There was nothing in the code that specified that the ads should only be displayed from Facebook redirects, so it’s possible that this is specified somewhere on the attacker’s server.

Conclusion

All in all, this is a surprisingly sophisticated injection for something which primarily generates small unwanted advertisements.

Like some of the more creative infections that we have seen, the primary payload is lodged in the database rather than the file structure. Infections with a relatively small footprint within the file system are more likely to go unnoticed by the website administrators. Moreover, concealing the payload using encoding such as hex2bin further stymes the ability of site owners to detect unwanted activity on their website.

The extent to which the malware tracks the users involved in the ad campaign is also a very interesting aspect and it’s not immediately evident why they would even bother doing this.

To mitigate risk, website owners should take precautions to prevent their websites from being compromised in such an attack:

1. Keep your plugins, themes, and website software up-to-date. Enabling auto-updates is a great way to patch vulnerabilities as soon as a fix comes out.
2. Leverage a web application firewall (WAF). The Sucuri firewall can help block brute force, bad bots, and patch known vulnerabilities.
3. Use secure passwords. Credentials for WordPress admin users, FTP accounts, cPanel, and server users need to be long and secure.
4. Employ the principle of least privilege. Only create admin accounts when absolutely necessary, and set appropriate user roles for all other users.
5. Enable 2FA. You can use this to secure your wp-admin area from unauthorized access. Alternatively, you can also protect your dashboard via protected pages.

And if you believe your site has been compromised or injected with malicious scripts, we can help! Reach out to our support team for assistance and we can help get the malware cleaned up for you.