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.