Malware authors, with some notable exceptions, tend to design their malicious code to hide from sight. The techniques they use help their malware stay on the victim’s website for as long as possible and ensure execution. For example — obfuscation techniques, fake code comments, naming conventions for injections that deploy SEO spam, redirect visitors to malicious third party websites, or steal credit card information from eCommerce stores.

To combat malware and keep WordPress websites safe from threats a variety of different security software has been developed in the form of plugins or extensions.

But, what if the security software itself is tampered with? This could allow malware to stay present even when measures have been put into place to protect the environment. This is exactly what we recently found in one such compromised environment.

In this post, we’ll reveal how attackers compromised a website and tampered with the existing Wordfence plugin to plant malicious website backdoors and evade detection.

Contents:

• Modifications in wordfence.php
• Wordfence plugin evasive techniques
• Removal of important warnings
• Malicious activity via code removal
• Plugin update prevention
• Resolution steps
• How to prevent malware

The first clue: modifications in wordfence.php

Whenever we perform malware removal on our client’s website environments we are always on the lookout for new, previously undetected samples.

Attackers are enhancing their malware all the time and we uncover new variants for existing malicious PHP, JavaScript, and other scripts on a daily basis. We maintain one of the best libraries of web-based malware in the world. Always checking for new samples “in the wild” is one of the ways that we do that.

Furthermore, one of the best ways of uncovering these new samples is through an integrity check – that is, comparing the file hashes of the files on the server to known good copies.

When we checked the hashes of the plugin files on this one particular website we found two very interesting modifications:

./wp-content/plugins/wordfence/wordfence.php
./wp-content/plugins/wordfence/lib/wordfenceScanner.php

Let’s investigate what was amiss.

Wordfence plugin evasive techniques

With over 4 million active installations the WordFence WordPress plugin is without a doubt one of the most popular security plugins in use today. It’s an excellent security suite with lots of features like malware scanning, brute force protection, 2FA, and more.

Like any other plugin, though, it can be tampered with if the attackers are able to gain a foothold into the environment. At the end of the day plugins are just code, and code will do whatever it’s told to do.

In this case, the attackers had accessed the compromised website and modified the WordFence plugin files themselves to conceal multiple malicious backdoors within the environment.

Let’s take a look at what was added to the wordfence.php file:

The WordFence plugin stores a lot of information within the WordPress database; that includes warnings issued to the website administrator to alert them to any potentially malicious files injected into the environment.

In the code displayed above we can see references to multiple database entries used by WordFence including the following warnings/notifications:

$requiredTables = array(
        "{$wpdb->prefix}wfnotifications",
        "{$wpdb->prefix}wfissues",
        "{$wpdb->prefix}wfpendingissues",
        "{$wpdb->prefix}wfconfig",
    );

The code within the WordFence evasion malware deletes these notifications from the WordPress database entirely if the issue is deemed a severity of “over 49” or happens to be a known malicious file. This functionality essentially prevents the site admin from being warned of any malware present on the site.

Removal of important warnings

Naturally, after seeing this code the first thing I wanted to check is if it actually worked. I had already determined that there were three backdoors within the file structure that (under normal circumstances) WordFence would surely issue warnings for:

./wp-includes/class-wp-customize-request-menus.php

./wp-content/plugins/simple-custom-post-order/assets/index.php

./wp-includes/Requests/Transport/PMA.php

(While not malicious per se, the Adminer tool is popular to abuse among attackers.)

Sure enough, no warnings were generated at all from the plugin:

(The paths skipped here were not related to the lack of warnings present)

The modification of the wordfence.php plugin file was successful at preventing security warnings from being generated for backdoors present within the environment.

Malicious activity via code removal

When attackers modify victim environments they are almost always adding unwanted code, whether in the form of backdoors, malicious payloads, seo spam injections or other malicious contents. We occasionally see malicious scripts which nuke entire file structures from orbit or drop database tables purely out of spite, however it’s not very common for attackers to intentionally remove code as part of their operations.

The other Wordfence plugin file that we saw modified was interesting in that attackers had intentionally removed legitimate functionality from the Wordfence plugin, further neutering its ability to operate normally.

Specifically, lines 405-432 from this file:

./wp-content/plugins/wordfence/lib/wordfenceScanner.php

We can see that (among other things) the ability of Wordfence to issue the following warnings were removed:

- This file appears to be installed or modified by hacker to perform malicious activity
- File appears to be malicious or unsafe

Plugin update prevention

Simply updating Wordfence would fix this issue immediately — but of course the attackers had already thought of that.

The malware was found to contain another interesting feature: it prevents the site administrator from seeing that their WordFence installation is out of date. It also prevents the plugin from being patched or updated at all through the familiar wp-admin dashboard:

Notice the version number in this screen capture: 7.6.2. At the time of investigation, the most up to date version for the Wordfence plugin was 7.7.1 — but the site admin would be none the wiser.

This malicious behavior was accomplished by (ab)using the site_transient_update_plugin database table functionality, which essentially tells WordPress that the plugin is up-to-date and there’s no update available.

Interestingly enough, we have seen this behaviour before in some other WordPress/WooCommerce credit card skimming malware as well.

Resolution steps

My next step was to replace the Wordfence files with fresh, known-good copies and see if that would fix the issue.

Sure enough, once those files were manually reinstalled the plugin returned to normal operating behaviour. Upon conducting a brand new security scan Wordfence now properly issued warnings for those backdoors as expected:

Moreover, the plugin then displayed as out of date, and — interestingly — also indicated that the website administrator had already enabled auto-updates for WordFence which the malware was clearly able to circumvent:

Fortunately, in this example we did not identify any actual malicious payload; only backdoors.

It’s not uncommon for attackers to wait for days (or weeks) after planting their backdoors before detonating their payload; this increases their chances of maintaining access to the compromised environment in the event that the website owner restores a recent backup. We were able to remediate the issue in time before any further malicious activity occurred.

How to prevent Wordfence evasion malware

For WordPress environments we previously published a helpful guide on hardening WordPress environments.

Some of the more notable suggestions include:

• Use 2FA on your administrator panel
• Use additional wp-config.php security implementations such as disallow_file_edit and disallow_file_mods
• Keep your website software up to date and fully patched
• Employ a website firewall to shield the website from attacks

Additionally, with this particular malware, it would be helpful to have a file integrity monitoring service that resides mostly outside of the environment itself, like our server side scanning solution. This way, it’s possible to see if any website files have been tampered with.

Conclusion

It’s always important to remember that there is no 100% security solution. Anyone who tells you otherwise is either a liar or a fool. Security is something that most website owners tend not to want to worry about, and it’s pretty common for users to just install a security plugin and hope for the best: “set it and forget it“.

Regardless as to what security solutions you choose to employ we at Sucuri always recommend defense in depth; that is, take every possible avenue to stymie the attackers’ ability to compromise your environment.

Website security is about risk reduction, not risk elimination. You as a website owner need to determine the level of risk you’re willing to take, balanced by the level of inconvenience caused by whatever security implementations you choose to use.

Security plugins are only one part of keeping a website safe and secure. As we can see in this example, if attackers are able to find a way into the wp-admin dashboard (or compromise an FTP/SFTP account) they can directly modify files to their choosing if further precautions are not taken. So, you’ll want to take steps to secure all aspects of your website’s environment to prevent malware.