Last Updated: 20.09.2023 – 16:00 CESTNote: The article below covers a simple case scenario of a hacked WordPress site, with only WordPress files, being tampered with. It’s neither an all-case scenario approach to the problem, nor it is the best way to handle that kind of infection: with some steps like database check being omitted here. See the bottom section of the article for further reading. I also, do not guarantee, that the steps provided below may help one out in his case scenario.
Discovering a hack
Front End Security Discovery
A couple of days ago, a friend approached me that his site went randomly offline. I was like, give me a minute or two and I’ll fix it xD At first, I took a look at his website and I thought, it’s just offline, the debugger is disabled, so, I’ll just log in, I will check the error.log, fix issues, and voila. I expected an auto-update to crash the website.
Later on, I checked the website via mobile phone, and I realized (actually pretty randomly) that in some case scenarios, the site was displaying an awkwardly looking content with Chinese text and some bags for sale, see the images below:
I realized, there was something wrong, and that my first impression, that an auto backup failed was wrong. The above page was displayed only in several rare case scenarios, i.e. browsers w/o any firewall or virus scanner, so I thought this was pretty odd.
Back End Discovery (files)
So, I decided to login to the site via FTP and I found, a bunch of suspiciously looking files and directories under the hood, say:
Manual malware pursuit & cleanup try
Since, the site was, most likely infected and I had no means of accessing the website via wp-admin / wp-login.php and so on. I did the following:
- I logged in via FTP and I manually removed as many infected/suspicious files as possible – to prevent further infections (if any). I did that directly via FTP or Control Panel, w/o downloading the files to my local PC (to prevent potential infection of my local PC – remember not to open these files (if not required) and if you are certain of potential risks involved).
- In some case scenarios, where files couldn’t be removed I checked the server-side logs. Some oddly looking files were being blocked from being accessed. These files that I missed while traversing the FTP, have also been quite suspiciously looking:
- Again, I removed these files manually, I tried enabling the debugger again, and I tried checking the logs, and the site was still inaccessible… I thought I got rid of all the infections, yet nothing has changed.
- Digging further into the files, I discovered that WordPress core files may have been tampered with, so there was not much I could do, but just overwrite everything with the latest core WordPress files.
Temporarily Blocking the site
Enabling Maintenance Mode
The problems described above, and inability to relaunch the site, made me do the following:
- I’ve uploaded latest WordPress core files, overwriting everything (i.e. files, directories) we have had with the latest WordPress files. Note: The FTP client, gives a good info of potential failures, with information of what has been overwritten and what not. I got to the point where I was quite certain no core file would remain infected, as they were simply overwritten.
- I’ve set up a new WordPress install, loading vanilla WordPress within the same directory as the previous one (using separate DB). This gave me the option to log in to a fresh Dashboard and run the updates of all WordPress existing plugins, again reducing the risk of having malicious files on the platform. Hence, after a longer while of fighting with the updates, I got to a point, where the client’s website was accessible from the browser 🙂
- For the sake of visitors, I used the Maintenance Mode plugin to inform them, that we were dealing with some sort of problem here – no details were provided/needed at this point.
Possible Security Penalty
Cleaning up Malware
The above temporary solution gave me some extra time and room for different kinds of work. With WordPress Dashboard being accessible and most likely all files up-to-date, I started proceeding with hardening and checking the site for any remains of the malware. Note: It’s not a problem to run a separate DB on the same WordPress install, as long as you don’t touch the DB of the original site – this gives one an access to the files from the Dashboard of the original install. Also, I’ve run Sucuri Security, Malcare, and iThemes Security plugins one by one with the hope of them removing any remains of malware. Find the results here:
A follow up from the iThemes
Update: A follow up quote from Daniel Knauss from the iThemes. This is a part of the conversation to be found on Linkedin.
IThemes Security is quite different from the others you looked at. It does not have a malware detection tool. The Site Scan feature checks if you have installed software with known vulnerabilities that could be hacked. It also checks if Google has flagged your site for the presence of malware, which indicates you have been hacked: https://ithemes.com/security/site-scan/ You can also use our File Change scanner to look for malware, but this really is not a comprehensive breach detection and cleanup tool. Finding and cleaning up a breach is not a security activity. Security is about prevention, so those hacks never happen, and you never have to do cleanup. So iThemes Security is focused on helping you harden your site and protect your users so you never get malware on your site. It looks like your friend’s hosting account may not be capable of running these scans — if you run into rate limiting you can wait and hope the server fres up, but you really may need more server resources. Here’s a support forum discussion about this: https://wordpress.org/support/topic/exceeded-rate-limit-please-wait-81-seconds/
What was I to do next, I asked myself? The site was up-to-date, and most likely most of the identified malicious files (excluding the potentialy malicious files mentioned by Sucuri) have been removed, while Sucuri (first choice) helped me out by adding an extra layer of protection. So, I gave it a try and I tried enabling the previous version of the website. I edited the wp-config.php file, to load the DB of the original website, to see if it would work now, and it did. Here’s what the site looked like next:
The site seemed to be running properly now. With “everything” up-to-date and an extra hardening applied on top of that. Based on the Sucuri Check, the site was free from Malware and was not blacklisted.
Dealing with an infected WordPress website is a PITA, not only you may have problems fixing the website yourself (as I had), but commonly used Malware Scanners may fail as well. The best way to prevent a malware infection or a hack is to stick to several rules, that improve the website’s layers of protection. The term is called risk mitigation, and with WordPress, one can follow several rules to prevent an infection:
- Keep your site and plugins up-to-date always.
- Enable 2FA.
- Use a plugin to Limit login attempts.
- Use strong passwords.
- Perform regular checks of your website, including security scans, they may fail (as in my case scenario) but they may give you an impression of having problems.
- Use an up-to-date PHP version.
- Use Sucuri Site Check to verify any exisiting malware.
Follow up reading
- WordPress Security
- Hardening WordPress
- Why WordPress Scanners are Worthless
- Codeable Security Experts