Tracking Down a Compromised WordPress Installation Using cPanel/WHM

I recently received an abuse email informing me that an node in my cluster was communicating brute force attacks to WordPress installations across the web.

I regularly check process logs and nothing out of the ordinary was present for the past few weeks but after a bit more digging I found an installation on a node that was running an old version of WordPress and had a theme installed that had been compromised. Obviously keeping your WordPress installation up to date is best practice, but in a real world scenario, users don’t always update or may feel overwhelmed about updating.

I want to share my experience of tracing the offending installation and provide the steps I took to alleviate the problem. These steps are reliant on the fact that you have a cPanel/WHM environment, although all steps could be accomplished directly through a CLI (Command Line Interface).

First it’s essential to verify that in fact WordPress, but more importantly httpd (Apache) is using more CPU/Memory than it should be. Log into your offending node through a CLI and run top. Keep an eye on this for 15 minutes and verify that httpd, is in fact, acting abnormally.

Login to the WHM installation that corresponds to that node and have a look at the Daily Process Log for the past week. Depending on your environment setup, Apache may run as user nobody. If that’s the case, you should see high resource usage from httpd as user nobody.

Great, so now we know that there is definitely some abnormal behavior but we can’t associate that bad behavior to a user on our server at this point. In WHM head to Server Status >> Apache Status. This is a snapshot of currently running Apache threads and the VHost associated with each thread. Refresh this page a few times and look at the threads that are taking a high CPU load. Make note of the Request column on these high usage threads and look for a file that is associated with WordPress (all WordPress files start with the wp- prefix). In my case there were many requests from a single VHost that I knew didn’t normally attract much traffic at all. Once you’ve found the suspect threads, make note of the VHost associated to each of these threads.

Using WHM, login to the cPanel installation of the offending VHost and navigate to the cPanel File Browser. You have a few options at this point, you can either completely delete the WordPress files and upload a fresh copy. Keep in mind, all uploaded files from the user on this WordPress installation are stored in the /wp-content/ folder, so if at all possible don’t overwrite this directory. Alternately, you could upload the updated files and overwrite the existing installation. The nice thing about updated a WordPress installation as a node admin is that you simply upload the updated files then visit and you will be prompted to update the database without having to login as the user.

Once you’ve updated the files and database, head back over to top and Apache Status and monitor these for another 15 minutes. If you tracked down the proper threads and WordPress installation, your resources should be significantly lower.