I’ve just been cleaning up the aftermath of an exploited WordPress install. I officially hate wordpress – this particular install had been updated a few mere weeks before, but an exploit had clearly got out for that version, and therefore – havoc.
On going through the files, database, changing all the passwords etc etc, I got to the point where I was actually quite impressed by what this automated attack had done.
Firstly, exploited files were stored in both /wp-content and elsewhere – traditionally, when you ugrade WordPress, you tend to overwrite everything but the wp-content directory, .htaccess file, and wp-config.php file; the wp-content directory stores uploads, so an upgrade to WordPress wouldn’t automatically overwrite the compromised files.
Secondly, everything was Base64 encoded – once you’ve got the hang of what they’re doing, it’s fairly simple to search for “gzinflate(base64_decode” or some such string, but a typical search for ‘Viagra’ or some such spam word will never show in a search of the source code.
Thirdly – and this one is fairly obvious – every output was hidden by inline CSS, either via “display:none;” or “height:0 width:0” etc. so as not to alert the blog owner.
The really clever bit which got me was the fact that browsing via a normal browser wouldn’t make the spam show up. You had to spoof a Googlebot user agent to see the damage (oh, and turn off CSS as well).
When was the last time *you* checked your site for spam? Google this to find out – ‘site:yourdomain viagra’