Hacked site - encrypted code

Question

Couple days ago I gave noticed that almost all php files on my server are infected with some encrypted code and in almost every file is different. Here is the example from one of the files:

http://pastebin.com/JtkNya5m

Can anybody tell me what this code do or how to decode it?

Answer 1

I am not finished and I don't know whether I ever will.

However my current results: The code itself is quite advanced (from my point of view). The code itself is shellcode http://en.wikipedia.org/wiki/Shellcode that tries to load a payload from a remote server.

The code has at least one level of indirection. At first it looks like those are the server providing the payload: "33db9538", "9507c4e8", "e5b57288", "54dfa1cb" These servers, when appending .com results in fake sites all registered by Maksim A Nesterov in Kiev, Ukraine. However digging deeper it looks like those servers act only as a distraction since later in the shellcode those are replaced by another set of servers:

$arr = array (
        0 => '54dfa1cb',
        1 => '33db9538',
        2 => 'e5b57288',
        3 => '9507c4e8',
      );

Those servers are again under the control of the owner in Kiev. I suspect those may be the servers hosting the payload.

(Note: The names are all parts of a md5 hash and are generated in code)

Now the code gets ugly. I am already dissecting the code a second time and I may be wrong. But from the array above it looks like only the first or second is randomly chosen, not the other two.

Then the script merges a lot of client properties into some large hash with some arbitrary number: http:// 54dfa1cb.com /366666?Fa2q8rOQ86kIwU7ZiX2Hcz0C53nhh8xfGo%252F11suKdoVhXxb98vt%252B95qlKnJaCZYUOzf1RgGHfWjAq%252B5wlthnTuM%253D.MLak6%252BXTvfVJjh2SzlyLbz8B%252F33vqvcSAw%253D%253D.bPf%252Br%252BzSo7QOwUzK.MLak6%252BXTvfVSghudzkePdDdD82Ws.d6q%252F9rrT9PNehFGAzl%252FAbTEd

This does however result in a 404 since I may have overseen something. I forged the request query but the server may still refuse my request. Either the servers I've located are still decoys or I haven't replicated the full request environment correctly. As all the md5 hashed data is sent to the server I would expect it to validate that by recreating parts like USER_AGENT and referrer.

The observable result of this when running it in your code would be adding extra code at the very end of the body or the html (typically body) that does something. The code does not execute when some keywords in referrer or paths are used, e.g admin, google, etc, so the shellcode is not indexed by search engines.

Blind guess: The shellcode will load some binary executable code onto the user's machine and try to execute it.

While I was faking a Firefox User Agent there is no way to properly now what exactly the server expects. It may just react on Internet Explorer to use some known security hole and report 404 on every other case or require a windows operating system, etc.

Do not execute the code to see what happens!

This shellcode was designed for the servers mentioned above and this is no noob work. There is quite an effort in this obfuscation of the code. It has several layers of eval and preg_replace with the e-modifier to resist reverse engineering.

Executing this code in a dummy environment is a security risk as the shellcode could potentially gain access to the machine on which it is running.

Edit: This part addresses your question on how it was possible etc:

(Disclaimer: I have little to no knowledge about encryption, security, hacking etc. I just have some knowledge in PHP programming and always wanted to get my hands on some real world shellcode to understand what and how it does things. Coincidently a machine at home has been infected for quite a long time resulting in stolen logins, etc and I am trying to guess what the attack vector on those logins was, which is nearly impossible for me.)

There are so many possibilities for your issue at hand (attack vectors) that I bet I forgot some and due to lack of experience I am unable to pin the most probable one.

• Depending on how your hoster stores the log in data it may be possible that an attacker obtained the database, shadow file, user account file etc with logins and hashed passwords and were able to perform some sort of attack on it to obtain plaintext passwords (dictionary, brute force attack, etc). It may be even possible that the passwords are stored in plaintext. Unlikely but that did already happen, afaik.

• Your machine might have been compromised. Even with proper AV and firewall drive by infection, email attachments, the use of cracked software or any other entry point may have resulted in a trojan that obtained log in data for your server, email etc. Many people store their passwords in a password manager like firefox or chrome etc, which may be easy to access once malware gained control (http://www.digitaltrends.com/computing/lay-off-chrome-firefox-has-the-same-password-security-flaw/)

• The probably most unprobable way would be some attacker wiretapping your network data by gaining access to your Wi-Fi (I mean beside the NSA which does that already :) ). This way requires monitoring network packets and filter them. I don't know how likely that is.

The ways above require quite some effort and after that you still need to get onto your server and infect your php files.

I think more common ways for your issue are:

• One of your PHP files is vulnerable to code injection (http://en.wikipedia.org/wiki/Code_injection). An attacker was able to execute arbitrary code on your account. This might be done by (but not limited to) careless use of "eval", "create_function" or preg_replace with the e-modifier. (Sidenote: May not apply here but many beginners learning sql and php tend pass script arguments into sql without proper escaping, resulting in (http://en.wikipedia.org/wiki/SQL_injection)

• Much worse but unlikely on professional hosting sites: Your account typically shares a physical or virtual machine with other users. The path to your files on a machine are like /var/www/1234, other accounts may be /var/www/1235 and /var/www/1233 (sorry linux guys if the path is not plausible :)). If a hacker gained access to script files of lets say /var/www/1233 and therefore to the file-system and the server is not properly configured an attacker may use the file-system to access all other file-locations, e.g /var/www/1234 (yours) and /var/www/1235 (some other poor guy). Such scenario is not controlled or influenced by you as you have no point of influence here.

• A very common case is using a CMS, Wiki etc that is not up-to-date. Such systems tend to expose a way to execute arbitrary code on them. Typically a dev detects the issue and patches it. But if you do not check for updates daily or regularly a security issue may go undetected. An attacker now just probably need to do a google search for let's say some CMS got a hole fixed at version 1.5. If you search the web for "CMS 1.4" you will find all sites using the CMS before the hole got fixed. I've read an article how incredible easy it is to use a search engine to locate sites with security holes suitable for injection or finding cms or other types of software where critical files (containing passwords, etc (bad way!)) are publicly visible.

What I would do (and am currently doing, as I have a similar issue): * Remove backdoor code first. * Get a rescue CD (I got avira's, avg's and kaspersky's) boot your machine with one or all of them and do a scan. Clear everything infected. It might be wise to reinstall windows. * If you do not reinstall windows than you will need to repeat the rescue cd part after some days to check, whether new threads were detected, if true, you may have malware that causes a re-infection of the system and then you will need to reinstall-windows anyway. * Keep AV software up-to-date (daily updates) * Perform full scan at least once a week * After you have no malware on the system. Change all passwords on all accounts. * Check whether your php files are infected again. Removing malicious code should be priority 1 but as you might have done that on a possibly compromised machine it may get reinfected there. It's even possible that you infect yourself with the backdoor on your site if you visit it.

As a matter of fact observing the result of an infection is easier than the fact when you got infected. That' like real life. You know when you have a flu but you cannot be sure where and when you got infected.

Again Disclaimer: No security background, just things I would do and things I have observed during my time in the web. If anyone sees obvious flaws in my explanations, please correct them.