Skip to main content

Cleaning up a hacked wordpress site


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.





Labels:

Comments

Post a Comment

Popular posts from this blog

Another VI tip - using macros, an example

God I love VI. Well, actually, vim but whatever. Here's another reason why. Suppose you need to perform some repetitive task over and over, such as updating the copyright date in the footer of a static website. (Yes, yes I know you could do a javascript thing or whatever, just bear with me.) Of course you could just search and replace in some text editor, changing "2007" to "2008" (if you're stupid) - and you'll end up with a bunch of incorrect dates being changed, most likely. What you need to do is only change that date at the bottom. And suppose that because of the formatting, you can't use the "Copy" part of the string in a search replace - perhaps some of the pages use "©", some spell out "Copyright" etc. This is where vi macros come in handy. A macro in vi is exactly what you expect, it records your actions and allows you to play them back. To start recording, press q followed by a character to use to "stor...
6 comments
Read more

Using FIle FIlters in FileZilla

Here's a handy tip for situations when you want to download a large number of files - but only of a certain type. For example, perhaps you want to download all the PHP files from a largish website, scattered through many subdirectories. Perhaps you're making a backup and don't want any image files, etc. FileZilla (still the best FTP in my opinion) has a handy feature called filename filters - located under the Edit menu. Here you can set various filters that filter out files based on their filename. Took me a minute to figure that out - you're saying show only PHP files, rather you're saying filter out files that do not have ".php" as their suffix. For some reason, that seems a little backwards to me, but whatever. It works quite well. You can also check whether the filter applies only to files, only to directories - or both. In this example, you'd want to check only files, as otherwise you won't see any directories unless they happen to end in...
1 comment
Read more

Great google article

Over on Maximum PC - there were a few things I didn't know you could do with the various Google apps. One is uploading files to google docs - any file. Which ties in well with my previous post about storing passwords - I uploaded a copy of my password safe file to google docs as a backup. Can't hurt, right? Also, I wasn't aware that you could set up forms in google docs that act as surveys, and then store the results in a google docs spreadsheet. This is a little alarming, as a decent amount of my work involves coding up custom surveys similar to this...
1 comment
Read more