Recovering a compromised WordPress site using AWS and Bitnami – Part 1

This series is about how I recovered a compromised three+ year old WordPress site, from a medium/bad compromise with no backups. Using Bitnami’s WordPress package and AWS saved me countless hours and I got all the data back. It cost me a few hours of my time and $0.50 of AWS EC2 usage.

Part I – the plan

Recovering a compromised WordPress site can be either very easy, or very difficult depending on the version of WordPress that you have installed, and the severity of the compromise. At the easy end of the spectrum is recent WordPress and good backups. At the harder end is very old versions of WordPress, no  recent backups and a site at a shared hosting provider (no shell access).

This particular site was for a class reunion from several years ago. It was left running because it was hosting some pictures from the event, but was rarely visited. Based on PHP file modification dates, the site was compromised in November, and probably again in December, using two different WP plug-ins. This left behind lots and lots of modified PHP code. There were multiple kinds of PHP damage, which looks like it was done by two different attackers.

In other words, a mess.

Using PhpMyAdmin, I was able to determine that in general the database was touched very lightly, if at all. But the PHP code was unrecoverable. The best plan was to pick the site up and move it to WordPress.com, and abandon the old site (and hosting provider). I decided to pick up the site and move it to WordPress.com so that I wouldn’t have to deal with WP software updates and incompatible plug-ins. Also, the managed hosting company had bumped its rates from around $50/year to over $150/year in the 9 years the site has been running.

But WordPress.com only accepts a WordPress Export File (WXR) as the import source. While stand-alone installs of WP offer many import options, WXR is the only option for WP.com without engaging their $ervices. This broken WordPress was old enough that it didn’t even offer the WXR as an export option. And, I wasn’t sure that I wanted to import the site wholesale until I had a chance to examine it.

This was my plan.

  1. Dump the DB of the infected site in the test SQL dump format. This creates a human readable (and editable) file on my laptop.
  2. Examine and edit the DB dump file to remove any obvious damage. Is it worthwhile to continue?
  3. Install stand-alone WP somewhere. I could use this to examine the site in a sandboxed environment and get a chance at some forensics and to more completely assess the damage. I expected installing a new host and WordPress to take the most time of the entire process.
    1. Import the database ONLY into the sandbox WP install.
    2. Test the sandbox WP site to see if there are any remaining landmines.
    3. Decide if it is still worthwhile to continue.
    4. If there are repairable problems, fix them in the original DB dump file (on the laptop) and clear the sandbox DB.
    5. Lather, rinse, repeat until the site looks OK
  4. When the sandbox site looks OK – save it as a WXR file
  5. Import WXR file into WP.com
  6. Test site.
  7. Drink beer.

 

Advertisements
  1. Recovering a compromised WordPress site – Part 2 (SQL dump and edit) | Thuktun (Message)
  2. Recovering a compromised WordPress site – Part 4 (import into wordpress.com) | Thuktun (Message)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: