Category: WordPress

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.