eswrite-wp

I know, I’m boring you all, but for the 1 person who is following this exciting saga with bated breath…

I think I’m in a lot better shape than I thought. Late night led to some faulty conclusions. It turns out the two funny looking databases I see are not suspicious in name at least. The first is from an aborted WP install back in 2009, and contains only default WP stuff. The second is in fact my current database. I’m in the process of using my ISPs web-based tools to snoop through it and see if I find anything suspicious. I did go through and through WordPress’ admin interface remove every user except me. Then I went back to the MySQL/phpMyAdmin interface and verified no rogue/hidden users in the actual database. That’s one less thing to worry about, but my blog users won’t be happy that they have to re-initiate their subscriptions. Oh, well. It was the only way I could think of id’ing a rogue user.

Though I’m still figuring out how to clean-up my database for which I have no recent/useful backup, I thought I’d jot down the “anatomy of the hack” as far as I’ve been able to figure it out.

1. I found and removed a FTP user name I had never created (user name similar to mine, but with some gibberish text after an under-score). According to my ISP, this FTP user had never accessed my site, so assuming the hacker didn’t clean his tracks (simplest assumption), it appears that’s one backdoor for future use.
2. I found and removed a recently added (at or about the time my site went to the white page) is_human plugin folder. I used to have this plugin, but removed it some time ago. This is pretty much the only alteration I can detect via recent time stamps.
3. I found and replaced a base64 infected wp-config.php file. Interestingly, it’s timestamp was not recent at all. As soon as I cleaned this file, my site no longer showed the white page and was up and running.
4. I found another base64 infected file, this time in a theme I wasn’t using. I removed all themes except for the default and my own customized theme. For the latter, I scanned each file, line by line (painful!) to ensure no monkey business. This is tough because though I’ve been editing these files for some time, I derived them from another theme, and hence I’m not quite sure what does and doesn’t belong.
5. I found nested wp-admin, wp-includes and wp-content directories (i.e., wp-admin had a wp-admin sub-directory, etc.) I removed all these.
6. For good measure, I replaced all directories/files that wouldn’t erase content data with what comes in a clean WP 3.3.1 install.
7. Finally, on my ISP’s MySQL control panel, I found 3 databases, at least 2 of which appear to be copies of each other and have unusual naming. In the process of figuring out how best to deal with that, as I linked above.

This is really a very painful and paranoia-filled exercise. Have I looked at everything, cleaned-up everything, changed all that I need to change? Baring a full re-install with complete database loss, I’m beginning to think I will never know.

The hacker has added it.

No kidding. But how? I don’t expect you to figure it out for me, but in all those links posted above, I see nothing that helps me figure it out so I can plug the hole. I did see a FTP user that I didn’t add, but the access log showed no activity, and none of the modified files had time stamps beyond December of last year. The logs are useless. So?

BTW, I also found a nested wp-includes folder inside the — you guessed it — wp-includes folder. I removed this folder (tons of files I didn’t have time to review) and my site is functioning properly.

I’m up and running now after cleaning that bit, but I’ll need to run through the rest of the gauntlet now.