A long-time client contacted me with a question about their SSL certificate, and said they thought the site "might be hacked."
Well, boy was it hacked. Shell scripts everywhere, and core Wordpress files as well as plugins heavily modified. I think it's all cleaned up now, so I thought put up a quick post about the process while it's still fresh in my mind.
How to know it's hacked?
In this case, it was easy. The site looked fine in the browser, but when I logged in and looked at the files on the server there were quite a few shell scripts which are little php files (in this case) that give the attacked a 'back door' to continue to upload files/etc even if their WordPress access was closed off. Additionally, there were many core files (wp-config.php for example) that had huge chunks of encoded text inserted at the top of the file. Additionally, looking at the transfer logs revealed traffic to weird looking URLs that were definitely not legitimate pages/posts on the site.
How long was it hacked?
This is trickier, since access times can be monkeyed with. In this case, at first glance the oldest of the shell files went back about eight months. There could have been older ones floating around, but that was enough to tell me that odds are I wouldn't have anything in my logs from when the attacked first got in - the logs are only kept for about a month or so.
Cleanup - part one - backups
Sometimes the easiest cleanup is just restoring from a known-good backup and moving on. This wasn't really an option because the site had been hacked for so long, and legit changes and posts had been made during that time. It would've meant restoring the old backup and losing all that work, or somehow redoing it. Not really an option.
I did immediately backup all the files and the database. This is important so you can go back and look at the files/data at your leisure, once the site has been cleaned up. Logs may also be useful to save, but since this was such a long-term breach, I didn't bother with that.
Cleanup - part two - take off and nuke it from orbit
Because the core WP files had been modified, I was concerned that getting them cleaned and secure would be more work than it was worth. The site was running a fairly current version of WordPress and looking at the database, it didn't seem that the attacker had known or cared enough to drop any goodies into database records. So, I decided the best path would be to blow away the whole public html directory, and start with a fresh copy of WP running on the existing database.
At this time I also went in and changed all the user passwords to a new, long password via the database.
After installing the fresh WP, I updated its wp-config.php to use the old sites database and logged in with no problem (using the new password). Then I installed a plugin to change the site to not use the standard login URL, as an added protection against the attacked getting back in via the login somehow.
Cleanup - part three - plugins and themes
Of course, more was needed. The site was now clean, however it wouldn't load due to missing theme and plugin files. I started with the the theme and carefully cleaned the files (more on this process below). Then I moved those into the wp-content/themes directory in WordPress, and make sure the theme was activated in the WP backend. Now the site would load partially in the browser, but was failing during the load. I looked at the error log files and was amused to see 404 errors for traffic trying to access various old hacked urls and shell scripts. But sure enough, the reason the site wouldn't load was PHP dying trying to use a plugin that wasn't set up.
Restoring plugins was the same process the theme - clean the files and put them back. I only did the minimum plugins needed to get the site to load - once the client tests the site, we'll learn if the others were necessary. They didn't seem important.
Cleaning PHP files - plugins and themes
In my experience, most of the people who hack sites like this don't have any real programming skill, they just copy/paste the same sort of junk, and upload shell scripts. And nearly always, that involves giant blocks of obfuscated PHP, which even to a non-programmer is obviously out of place when you look at a file. Of course there's way too many files to manually inspect each file. This is where grep helps you pinpoint the fishy ones.
grep -rl '\\x' * | grep 'php' | more
That grep run from root html directory will find a lot of these. It looks for the '\x' codes that are used extensively in hacked files. Of course, they're also used in legit files, but at least it cuts down on the targets to investigate. You can also grep for 'base64' which is also often used. In the end you need to know both PHP and WordPress enough to read the code and see if it's being used legitimately.
The other thing you can look for is file modification times. If you're looking at plugin that hasn't been updated in a year, and see a few PHP files that were modified last week, you better investigate.
Cleanup - part four - securing and monitoring
So now that the site is up and running, I went in and installed the Sucuri plugin and set it to send notifications to me. That and just looking at the site files now and then for weird new files should give peace of mind that our friend hasn't returned. And they probably won't - there's plenty of softer targets out there now.
But how did it get hacked?
Good question! Because I don't have log files going back to when it probably was breached, it's hard to tell. Odds are it was brute-force attack on the WordPress login. There were three users on the site, and this client historically has used pretty weak passwords. Another possibility is a WordPress vulnerability, I'm not sure how often the core was getting updated. And of course plugins are always a possibility. I told the client to change the password on any other accounts (especially bank/credit card and email) that used the same password. And never user the same password on more than one account, use long passwords, etc etc. We'll see if that happens.
Comments