A new client approached me: his WordPress blog was behaving strangely: spam was showing up in the RSS feed, but he couldn’t find it in the blog Posts. He had been hacked once before, so perhaps this was more hacking.
I took a look at the files on his server, and quickly noticed a couple of oddities.
Spammer files hidden in plain sight
There was a file in the root folder called
wp-comment-post.php. This was in addition to the standard file with a similar name:
wp-comments-post.php — note the extra
s in the legitimate filename.
The intruder file contained a large block of random characters that began like this:
<?php eval(base64_decode("QGluaV9yZXN0b3J. Clearly it was Base64 encoded.
I ran it through an online decoder to find it was in fact 1640 characters of PHP code that started like this:
@ini_restore("safe_mode");@ini_restore("open_basedir");. That could not be good.
Further rummaging around revealed a folder called
wp-content — a legitimate name for a WordPress folder — but inside the
wp-includes folder where it had no business to be. That folder contained a file named
The oddly named file was the spam payload. It contained 1737 characters of spam links that began with this positioning code:
That CSS would place the enclosed links well off the screen for anyone viewing it with a browser, but an RSS reader would be likely not to obey the positioning, and simply display the links.
Obviously I deleted these clearly intrusive files, but we needed a more thorough cleanup. What other files were infected? What else had been hidden in plain sight?
A clean up action plan
I gave my client an plan for cleanup that included the following actions:
- Back up everything.
- Check the database for spam in any Posts or Pages and clean out if necessary.
- Change the name of the database and table prefixes — in MySQL and in
- Change the username and password for connecting to the database.
- Delete all WordPress files from the server and replace with fresh copies, including the Theme.
- Check that permissions on files and folders were correctly set.
- Create a fresh
wp-config.phpfile with the new connection details, and including the Authentication Unique Keys that were added to WordPress a few versions ago. Older blogs may never have updated this file.
- Check the Users from the WordPress Dashboard: delete the default Admin user and ensure all users changed their passwords.
That’s not a comprehensive list, but it gives an idea of what was required to ensure the spam was gone and that the hackers could not regain entry. It also meant taking the blog offline for a few hours.
The registered spam user
I hadn’t looked at the list of registered Users until I did the cleanup work, but that’s when I found a very suspicious user on the blog. It was a User named ‘Google’.
A thorough cleanup
The cleanup was time consuming, but thorough. It needed to be, in order to get rid of all traces of the hacker, and make sure they couldn’t just get back in with passwords, names or permissions they already had.
It took several hours, from start to finish. It included some preparation and planning time to make sure that all bases were covered, that I had all the passwords and URLs I needed to do the work, and that I was carrying out the steps in a sequence that would be efficient and effective, but minimise down time.
Subscribe to your own RSS feed
I have one final word of advice: subscribe to your own blog’s RSS feed and look at it.
My client had identified the spam in his RSS feed, even though it wasn’t visible on the blog.
You never know when something may happen to your site — with any luck not hacking, but servers can go down, or you may fail to notice you haven’t actually published a draft Post, for example.
Check your blog frequently and catch problems early. And watch out for and apply updates to WordPress plugins, your Theme and the WordPress core files.
Update April 2010: If you’ve read this Post then I strongly suggest you also read Chris Pearson’s How to Diagnose and Remove the WordPress Pharma Hack.