A while back I had to deal with a compromised web server for some folks. They had some WordPress sites with a vulnerable plugin and found that attackers were putting up malicious web pages for other victims to view. The owners of the sites were understandably upset.
The malicious files names didn’t follow much of a pattern, though I later noticed they shared a common location across the sites. However, they did share a common trait in their content. Basically, the PHP code is compressed and then base64 encoded. The blob of random text is then stuffed into a PHP file which has the following call:
“eval(gzinflate(base64_decode(“BLOB OF TEXT”)));
This decodes the blob, uncompresses it and execute it on the web server. While it obscures what the code is doing (briefly), it fairly screams that something is not right with this file.
First to find any PHP files which use this on your server use:
egrep -r “eval(gzinflate(base64_de” . –include=*.php
That will find the offending files. To see what they did, I copied everything inside the “eval()” statement. Then I dumped into a text file on my laptop in something that looked like this.
$X = gzinflate(base64_decode(“BLOB OF TEXT”));
Instead of displaying it in a browser, I called it from the command line.
The code gets base64 decoded, decompressed and displayed in my console window. Because I removed “eval()” from the code I could see what the attacker was doing without worrying about executing bad code on my system. Or viewing it in my browser.
One thing to note for defense. If your IDS alerts on something sending “eval(gzinflate(base64_decode(” over your network, you have a problem that you need to look into. Some legitimate applications will use something like this, but it shouldn’t be crossing the wire. Only executing on the server. It might end up being nothing, but if an attacker can shove this to your web server you have a issue on your hands.