In Part One, I went over some of the more common Wordpress hacks I've seen, and ways to detect them/find where they're hiding. Here, I'm going to look at the second part of the equation: removing the hack without damaging your site. I will also go through some of the more unique hacks I've come across and some basic strategies to make sure you don't get hacked again.
Step One: Back Up Your Data
This is a key step because it's an easy one to forget. It's even easier to regret the choice not to follow it, though; in a digital environment, data is as unique as it is irrepleable - at least, without potentially significant time and effort. So, before you delve into the files in your system, ensure that you make a copy of them somewhere - better safe than sorry, after all.
At this point, you can also do things such as put up a 'Website experiencing techinical difficulties - we'll be back soon' message if you choose to; this is probably a good idea, since people viewing your site before you've cleaned it up are potentially having their systems compromised because of your site. This is never good. Putting up a temporary splash page saying you're working on the site is one way to avoid this.
Step Two: Go Hunting
Some cursory checking of the file system via FTP client (or even SSH client) should show you the date the hack occurred on; just look for the date modified for files that you've determined to be hacked. In Wordpress, the core files will rarely be modified, so it shouldn't be too difficult to find the date of the hack.
At this point is where the manual work comes into play. Depending on the extent to which your site has been compromised and the number of files hit, it may be easier to download a fresh install (of the version of Wordpress your site uses!) and replace the infected files with the ones from the install. This isn't always an option, however; I work on cleaning up the sites of a lot of clients whose sites I've never dealt with until they're hacked. This means that I don't always know the version of Wordpress they're running going in, nor do I know they haven't chosen to do something silly like hack Wordpress core. It's unlikely that they would, but I have no way of knowing, and so replacing the files is not generally something I want to do, despite the backup from step one (you did create a backup as I recommended in step one, right?).
If you've downloaded a fresh install of Wordpress and replaced the infected files, then great! If you don't feel you can do that or there aren't very many files infected, then you are left with option 2: getting rid of the problem manually. This is most often the solution I take; it's about as simple as it sounds. Using your FTP program (you can also use VIM or something similar via SSH client - I prefer not to), and arranging files by date modified to find the infected files more easily, you open each file in a text editor (Text Pad is good for this), then you look for the bad code. It will generally be in the very top or very bottom of the file, or it will be inserted directly before/after the '<body>' tag. Part One of this series deals with what sorts of 'bad code' you might find there; if you can't figure it out, then one easy way to find it is to download a fresh copy of Wordpress, then compare the infected file with its counterpart in the download. Delete the text, save the file, and move on to the next one.
This can be a time-consuming process, but sometimes it's the only thing that can be done. You could also try running a specialized find-and-replace command via SSH client, however I am always leery of this; one slight mistake/miscalculation and you've whacked a good portion of your site (you backed the data up, right?).
Step Three: Make Sure the Problem is Gone
After you've removed the bad code, you need to make sure it's gone. You also should probably consider changing your FTP/SSH password to make sure you don't get hacked again in the future, as well.
I always do a quick scan through the site manually, looking for anything odd; typically I start on the home page, do a 'View Source' on it, scan through where the problem would typically be, then load up a few other pages of the site and do the same - you want to make sure that
- Pages on your site load properly
- The problem is gone everywhere (not just from your home page)
- The site is configured properly (aka, you haven't whacked the wrong thing somewhere)
So to do this, I normally look at a variety of types of pages; normally I view the home page, pages with forms on them ('contact us', etc), pages with specialized galleries, etc, just to make sure that everything is working as it ought.
After I've done this (and not found any problems), I run my grep command from Part One to make extra super-duper sure that everything bad is gone. Then I run a test via http://sitecheck.sucuri.net/scanner/. At this point, if you've picked up nothing, the problem should be gone.
Unique Hacks I've Seen
Commonly, hacks are nothing more than scripts that insert 'bad' code into 'good' files, compromising the site. Sometimes, however, hacks are either manually-done, or just more clever.
default.php
This is a file I've found under the root folder, wp-content, and wp-includes in the same site/same hack. This is not a default wordpress file, and you don't want it on your site.
index.php
A clever hack that I came across recently was one in which the site was scanned and the HTML of its front page was copied, then the index.php file in the main directory (which is normally only a few lines to initialize Wordpress) had the HTML inserted, along with a great deal of malignant code - checks to see if the current page viewer was a bot or not, and to perform different actions based on that. This would have been a very clever hack, since the HTML looked legitimate (because it was), and was mixed with the bad code, however the fact that Wordpress index.php files don't have straight HTML in them was a give-away.
satan.php
This is a more difficult hack because it was buried in the wp-content/plugins/ folder, in its own folder (called in one case BoxTheme and in another case something different). This folder contained two files: plugin.php and satan.php. Having found these files, it took me some time to verify that they were, in fact, files I didn't want anywhere on the server; a google search of their names and some of the inside code helped determine this. This was a manual hack, and the files were placed in a location that, if you didn't know exactly what plug-ins were installed on the site (as I did not), would be very difficult to find. These files are dangerous: they provide backdoor access to your site, almost like a hacker's cpanel, with much the same functionality (file upload, modification, etc).
From what I was able to determine, the hacker in this case gained access through the Wordpress interface (cracked the password), uploaded a new 'theme', then used the uploaded file to get in and do whatever he wanted to. Change your Wordpress password if you find a hack like this.
Don't Get Hacked: Safe Practices
Safe practices could be its own series of blog posts, so I'll stick to some basic ones for the purposes of not getting hacked.
If you've been hacked, change your password.
Actually, this applies to you if you haven't been hacked, but your password is something like 'password', as well. This applies to all passwords for the site; FTP, SSH, MySQL (often linked to FTP), and Wordpress log-in. This is common sense, but a lot of people don't do it. A lot of people get hacked again, too.
Perform regular site back-ups.
You need to be backing up your data regularly. Both databases and your file system are important. You don't need to keep a million backed-up copies, but you do need to have at least one recent back-up.
Keep your install of Wordpress up-to-date.
Wordpress has some security vulnerabilities (just like every other piece of software out there). The good news is that sometimes these are found by the good guys, who then fix the problem. They put these fixes in updates to Wordpress. If you don't keep your install of Wordpress current, you won't get these fixes, and will be subject to hacks that may not have been able to get in otherwise. This applies to plug-ins often, as well. Be sure you perform a database back-up before updating to a new version of Wordpress core or plug-in, though, and keep the old core/plug-in files, just in case something breaks and you need to revert.
I hope this series has been useful to you. Good luck, and good hack-hunting!