Installation Protection Mechanisms of Phoenix Exploit's Kit

As part of my research within Websense Security Labs, I collaborate with a group of researchers tasked with profiling exploit kits.  This helps us refine the analytics used in ACE, our Advanced Classification Engine.  In this post I want to cover the installation of Phoenix Exploit's Kit.  I'm not going to tell you how to install and use it, but I will cover some of the more interesting aspects of installation.  Specifically, I want to cover how the developers protect their code from being reverse engineered and how the developers have attempted to keep researchers from poking around in installed kits.  

To begin, let's have a look at the installer for the kit.  Like many exploit kits, this one is PHP-based but unlike most kits, the installer is actually obfuscated.  This is probably an attempt by the developers to make it harder for security researchers to understand how to install the kits, especially if there is no 'readme.txt' file included in a kit.  Typically, exploit kits come with some sort of installation and or revision documents which come in the form of a 'readme.txt' file or 'notes.txt'.  Without the readme file, it can be difficult to install a kit unless you reverse engineer the installation process.  Most of the time, the reverse engineering of kit installation is pretty easy because the PHP code is not obfuscated. 

Here is a look at the obfuscated code in the PHP installer:

Looking at this code, we can see that it's Base64 encoded and a ZLIB compressed stream of data.  The PHP script uses an 'eval' statement with 'gzuncompress' and 'base_64decode' functions to decode the stream of data.  For us to get the clear text code, we can use a simple substitution trick along with the PHP CLI so that we can then analyze the installer's code. To do this, we simply need to replace the 'eval' with a 'print' and run the install.php script on the command line. 

Here is a snippet of the deobfuscated install.php script:

Looking at this code, if you're like me, you might think that the interesting thing about it is the variable declarations with long base64 encoded streams.  It actually turns out that each one of those variables is holding obfuscated PHP code for the page for which the variable is named.  For example the '$config' variable holds the base64 encoded 'config.php' file and the '$activate' variable holds the 'activate.php' code, which we will get to in a bit.  This is where things get interesting, as far as protection mechanisms go.  The reason that the PHP code for each of these scripts is held in a variable is because the page names actually get randomized for each installation!  This helps to prevent security researchers from easily finding and possibly viewing statistics about the site hosting a Phoenix Exploit's Kit.  Prior to the version being analyzed here, Phoenix came with standard page names so once the exploit page was found, it was easy to find the statistics page and try to break in to view stats from that particular installation. 

Here is what the install looks like when it's visited from the browser:

As you can see, when viewing the installer from the browser, there is really nothing special about it.  You get to choose the language of the installation instructions, either English or Russian. And on the next page you have a form to fill out for various resources.  I'm not going to show you this form for the reason that it contains sensitive information.  However, I will show you the result after filling out the form so that you can see the randomized page names and what has to be done to activate the kit.

This is a look at my current working directory before the install of Phoenix Exploit's Kit:

Here is the same directory after the completion of the install script:

As you can see, the install script contains just about everything needed to install the kit.  It extracts the necessary scripts and randomizes the file names, and thus the purpose of the file.  If you have a look at the code in each file, you can begin to figure out the purpose of each file.  The thing to notice and realize from here is that each installation creates unique names for each of the pages.  Again, what this means is that a researcher can't find statistics for an installed kit after finding the page serving up the exploits.  Rather, for any given kit installed in the wild, it's anybody's guess as to the names used for statistics and other pages used by that kit! 

Regarding the installation we've been examining, at this point the kit isn't at all usable because it doesn't yet contain the exploits.  To obtain the exploits, the purchaser of the kit must contact the developer to activate their kit.  The "installation success" page explains this: "To activate this installed copy of Phoenix Exploits Kit please send the following activation string to the author."

Here is a screen shot of the installation success page:

In summary, we can see that the developers of Phoenix Exploit's Kit are working on not only protecting their exploit code from being recognized, but also their installations.  This makes it difficult for researchers to further dissect and understand how the kit works, especially if a researcher comes across just the install script.  It also makes things more difficult for others who want to study and report on the statistics found from individual installations of Phoenix by randomizing the page names used in the kit installations.