I'm just curious, what thid he/she install (listed the php files in the github repo).
It would be nice to know what those php files do. Any help demistifying/decoding/ the php files is much appreciated.
This is fairly straightforward ratware. Is there anything in particular you wish to know about how it operates?
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.
> 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.
Is privilege escalation that easy/common? Thinking esp of the number of shared hosting providers out there, if a user account is compromised they don't assume the entire server is compromised.
Now ok, www-data isn't any old user account, but the same principle applies?
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
Rather than trying to undo the damage (will you ever be 100% sure you caught everything?) why not create a new site (edit: as in a new VM/box/image from scratch) and import your data fresh.
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 :)
One problem is that a truly full cleanup of a hacked website should in theory include manual cleanup of all clients' caches (not really practical). Otherwise, malicious index.html (for example with JavaScript that sends cookies to an attacker) could remain cached by the clients forever.
That is assuming the cracker did not go further than the website's folder.
From my own experience, when one of my sites with username www-data was hacked (default apache installation), the client-side malware JS was injected into .htaccess file and added to ALL folders www-data had write access to.
What I am saying is, assume the worst, what other data could the cracked unix account do on the system.
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.
I have been there too. When it happened to one of our clients I Googled the site URL and found some script kiddie had boasted of his antics on Twitter. A bit more Googling and I had his mum's house (he lived there, presumably there was a basement). I was wanting to take matters further, as in get the police to arrest the guy and get him prosecuted for criminal damage. However, my 'superiors' told me to just restore the backup and leave it at that.
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.
I had dealt with a similar hack recently and documented it [1]. The difference is mine was in Wordpress. There was a simple file called post.php that evaled anything that was sent in the post var. Have you found out how your server was hacked in the first place ? Check your Apache logs for errors hackers are usually careless when it comes to errors or warnings.
I'm at work otherwise I would be wasting a good few hours deobfuscating that code. So far I've decoded two files which for the most part seem the same but the line counts are different
Edit: So far php_display seems to allow the attacker the ability to download a file. In common.php at at least.
I used to work for a web hosting company and we saw this kind of attacks ALL the time.
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.
Best answer I've seen so far. The takeaway from the guys on the front lines is usually that a full server compromise is rare and that FTP creds were stolen from a client via malware. The result is a simple drive-by that is relatively easy to clean up.
At the risk of not adding much of substance to this conversation, I do feel compelled to point out how happy (giddy, even!) it makes me to see so many people jump right on this and investigate, and in part just for the hell of it.
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.
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)
Follow your access log and find out how those files got written/requested. in order to solve the problem you need to identify it first. you probably need to check your permissions as well, prevent apache process from writing to your website root, it should only be able to write to "sites/default/files".
Thanks for your comment.
I will advise my client to take a proper hosting instead. "Getting hacked" was only one of the many trouble we had (and I advised for other hosting in the past already).
After checking en.php (Sorry didn't have time to check more files) I found two ip's. You could use unphp to deobfuscate the code a bit but You'll have to do a lot of it by hand which should not be that hard.
[+] [-] patio11|12 years ago|reply
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.
[+] [-] porker|12 years ago|reply
Is privilege escalation that easy/common? Thinking esp of the number of shared hosting providers out there, if a user account is compromised they don't assume the entire server is compromised.
Now ok, www-data isn't any old user account, but the same principle applies?
[+] [-] jfoster|12 years ago|reply
[+] [-] woutersf|12 years ago|reply
I am interested in how it operates. Is it as simple as : "It runs the remote php file and adds whatever html?" or is there more to it?
I find similar functions in all the files (error_404/http_request_custom/getUseragent/getReferer/convertIpToString/getIp)
[+] [-] Kinnard|12 years ago|reply
[+] [-] wernerb|12 years ago|reply
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!
[+] [-] crypt1d|12 years ago|reply
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
[+] [-] crypt1d|12 years ago|reply
The code uses a curl to [removed]
html source code of the link shows another obfuscated javascript code: http://pastebin.com/1WLYMp0E
EDIT: I removed the curl link to as it might be some unpatched exploit
[+] [-] joshvm|12 years ago|reply
Edited to include variable replacement. I think there are some catches with things like ${sgasklgna} but it largely works. Just needs prettifying.
[+] [-] michaelmior|12 years ago|reply
[+] [-] rschmitty|12 years ago|reply
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 :)
[+] [-] mixedbit|12 years ago|reply
[+] [-] alandarev|12 years ago|reply
From my own experience, when one of my sites with username www-data was hacked (default apache installation), the client-side malware JS was injected into .htaccess file and added to ALL folders www-data had write access to.
What I am saying is, assume the worst, what other data could the cracked unix account do on the system.
[+] [-] dageshi|12 years ago|reply
http://afick.sourceforge.net/
Then you do have a reasonable idea of what's actually been modified after the fact.
[+] [-] woutersf|12 years ago|reply
[+] [-] msantos|12 years ago|reply
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.
[+] [-] msantos|12 years ago|reply
... a dirty example (I apologise in advance)
[+] [-] michaelmior|12 years ago|reply
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.
[+] [-] Theodores|12 years ago|reply
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.
[+] [-] ibrad|12 years ago|reply
[1]: http://idiallo.com/blog/2013/11/fixing-3-year-old-hack
[+] [-] johnnyfaehell|12 years ago|reply
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.
[+] [-] juanrossi|12 years ago|reply
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.
[+] [-] themodelplumber|12 years ago|reply
[+] [-] mercer|12 years ago|reply
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.
[+] [-] rawb92|12 years ago|reply
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)
http://pastebin.com/PkJFTeGs
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)
[+] [-] woutersf|12 years ago|reply
[+] [-] slang800|12 years ago|reply
[+] [-] freshyill|12 years ago|reply
[+] [-] level09|12 years ago|reply
[+] [-] woutersf|12 years ago|reply
[+] [-] aleem|12 years ago|reply
As others have noted, a compromised shell can never be trusted again and you should re-deploy from scratch.
[+] [-] cbg0|12 years ago|reply
[+] [-] mechazawa|12 years ago|reply
125.89.44.28 <- Chinese 62.122.75.2 <- Polish
[+] [-] unknown|12 years ago|reply
[deleted]