by woutersf on 4/30/14, 8:53 AM with 97 comments
by patio11 on 4/30/14, 10:13 AM
browser.php is an amusing one for reversing obfuscation tricks, if anyone wants practice.
You should treat the server as compromised and rebuild from metal, by the way. I know that is annoying as heck but they clearly got code execution and you can therefore assume they had root if they wanted it and that any attempts to detect whether they did are useless because their rootkit makes the box lie to you about its current state.
by wernerb on 4/30/14, 9:15 AM
Here is what main.php does: http://www.unphp.net/decode/3aaa2bc88be0e162fc3ca8786a2f8f82...
Found the following url somewhere: 78.138.127.174/2701dfbvcxff.php
Use http://ip-lookup.net/index.php to get to some abuse email addresses and inform them that the ip is involved in hacking.
Anyway this was just my quick glance, good luck!
by crypt1d on 4/30/14, 9:48 AM
I took the first function and decoded the first bytes of hex, which gave the infamous eval(gzinflate(base64_decode( function. Then I used http://www.whitefirdesign.com/tools/deobfuscate-php-hack-cod... to decode rest and got a group of variables with hex data that were being grouped together like this eval($xwq2ay . $xq9mar . $xb4jym . $xm0hy3); (full version available here - http://pastebin.com/7V951cRK
Decoding this hex gave me another set of preg_replace functions, which were doing the same thing pretty much. And then again the same, except two preg_replace were being called. Eventually I got something like this http://pastebin.com/JP1eukca
The hex stored in $a and $b are just a clever way of masking gzinflate(base64_decode( so I took the rest of the data, put it into the decoder and finally got to some proper code - http://pastebin.com/A0G290cE
by joshvm on 4/30/14, 11:53 AM
import re
a = open('test.php')
line = a.readlines()
# Replace hex values with ASCII, regex to find the \x values and a lambda to replace each match individually
def decoder(char):
return char[2:].decode("hex")
unhex = re.sub("\\\\x[a-f0-9][a-f0-9]", lambda m: decoder(m.group()), line[0])
# Replace ${"GLOBALS"}["foo"] = "bar"
for match in re.findall('\${"GLOBALS"}["[a-z0-9]+"]="[a-z0-9]+"', unhex):
variable = re.findall(r'"(.*?)"', match)
pattern = '\${\${"GLOBALS"}\["'+variable[1]+'"\]}'
unhex = re.sub(pattern, variable[2], unhex)
unhex = unhex.replace(match+";", '')
# Replace $bar = "foo"
for match in re.findall('\$[a-z0-9]+="[a-z0-9]+"', unhex):
replace = re.findall(r'"(.*?)"', match)[0]
pattern = re.findall(r'\$[a-z]+', match)[0]
unhex = unhex.replace(pattern, replace)
# Chuck in newlines
unhex = unhex.replace(";", ";\n ")
b = open('out.php', 'w')
b.writelines(unhex)
Edited to include variable replacement. I think there are some catches with things like ${sgasklgna} but it largely works. Just needs prettifying.
by rschmitty on 4/30/14, 9:56 AM
If I was hacked and files were placed on my server, including a 'web shell' I would be very afraid I don't catch everything and it just gets re-hacked.
Unless this is just a pure curiosity adventure in deobfuscation... then nevermind :)
by msantos on 4/30/14, 4:01 PM
Create a full snapshot of the machine for forensic analysis later. Then follow @patio11 advice and rebuild from the metal up.
That's the only sure way you have a "clean" machine, then sieve through‎ the snapshot and try and find the hacker's entry point.
by michaelmior on 4/30/14, 12:22 PM
Aside from decoding the escaped characters, there's a bunch of simple regex replacements to remove all the random variable usage and then a pass through PHP_Beautifier to fix the formatting.
by Theodores on 4/30/14, 10:50 AM
I have to say that I was impressed by the way the hack worked, in this incident and others, I felt that I was up against a far superior adversary.
by ibrad on 4/30/14, 9:34 AM
by johnnyfaehell on 4/30/14, 9:19 AM
Edit: So far php_display seems to allow the attacker the ability to download a file. In common.php at at least.
Edit : https://github.com/icambridge/help_me_clear_this_up/blob/mas... what I've deobfuscated.
by juanrossi on 4/30/14, 12:38 PM
Most of the cases was because of old CMS versions, but in same others the computer uploading the files was infected and the FTP credentials were stolen (Change your user/password and analyze ftp logs).
I would also check the database and do a clean install of the CMS.
The server could be compromised but I don't think this is the case.
by mercer on 4/30/14, 7:12 PM
It's infectious!
I'm here because I share many of the interests of the people here, and I'm convinced that a big reason why I started 'hacking' more and more over the past years, in part just for the hell of it, is because of the enthusiasm I find in comment sections for links like these.
Some links show me tricks I didn't know or tools/libraries/frameworks I haven't used before. Some make me curious to try different programming languages. Some articles go way over my head but make me strive harder to get better at whatever it is the article is about. And some, like this one, make me want to code or tinker just for fun.
I just wanted to say that once, and this seemed like an appropriate moment. Move along.
by rawb92 on 4/30/14, 3:06 PM
Our website and 2 of our client websites have been compromised like this in the last couple of weeks and they are all across different hosting providers (Zen Hosting and Unlimited Web hosting)
Here is a link to the code we found injected into the index page on our FTP and my attempt at decoding it.. interestingly enough it does relay to javaterm.com as the authors comprimsed site does as well..
We are fairly certain it wasn't achieved through our code as one of the sites is literally 6-7 pages of static html content.
From what we can tell it only ever effects the index page in the root of a servers FTP. In my case all of the shells were deleted(Looking from the FTP logs there were 2-3 uploaded all with different names)
by woutersf on 4/30/14, 9:14 AM
by freshyill on 4/30/14, 1:33 PM
by level09 on 4/30/14, 10:03 AM
by aleem on 4/30/14, 10:33 AM
As others have noted, a compromised shell can never be trusted again and you should re-deploy from scratch.
by cbg0 on 4/30/14, 9:16 AM
by mechazawa on 4/30/14, 9:34 AM
125.89.44.28 <- Chinese 62.122.75.2 <- Polish
by jetzz on 4/30/14, 9:24 PM
by marlin on 4/30/14, 12:22 PM
by MisterBastahrd on 4/30/14, 10:13 AM
by marlin on 4/30/14, 12:42 PM
google reveals several posts about this one
by gcb0 on 4/30/14, 3:11 PM
by javaboy on 4/30/14, 9:15 AM
by DonaldDerek on 4/30/14, 11:56 AM