Inside a Black Hole: Part 1

Before going into the details of the complexities of the analysis, another very important question came up: how was this code obtained in the first place? There is no first-hand information available, but putting together some of the observations and connecting the dots could lead to a reasonably strong explanation.

Figure 1. The main clue.

The leading clue was a file named ‘27’ in the files directory. We know from analysis of the backend code that this is the file upload directory, to which new executable payloads can be uploaded for distribution to the infected endpoints.

However, this file was something different. It was not a botnet executable or a keylogger installer, as one would normally expect, but a copy of the infamous C99Shell backdoor, which is a popular choice for hacking into websites. One could argue that this could be an intended payload for some infected systems, but the payload from the file directory is always delivered with an .exe extension and ‘application/x-msdownload’ content type – the system is not set up to deliver a PHP script. The file 27 is a foreign body within the Blackhole code complex.

Additionally, there is a related directory, dir27, which contains an index.php file. All directories in the hosting server contain this file, which displays a standard 404 error message to disable directory browsing. However, unlike all of the other index.php files, this one is not protected with ionCube. Analysis of the code shows that the file was probably created dynamically at runtime, and thus install-time protection was not applicable.

Evidence suggests that the site was hacked by uploading C99Shell. Using it, the attacker gathered all files from the Blackhole home directory. Presumably the hacker did not gain access to files outside this directory (or had no idea about the structure of the set-up, and did not bother to grab other files from the server), as the files outside this home directory (most importantly the MySQL database files) were not retrieved. Having the database could have been a great help in understanding the internals of the operation.

But before reaching this point, there was an initial hurdle to jump. The exploit kit provides the option to upload files, but only after admin authentication. So in order to hack into the server, the attacker had to gain access to the web admin interface. How was this possible? It all became clear after having a quick look at the code: the config.php file contains, among many other general settings, the MD5 hash of the admin password. It is considered to be a safe approach to store only the one-way hash of the password (though even in that case MD5 is not the advisable choice for the hash algorithm), and on authentication the calculated hash of the submitted password is compared with the stored hash. What should not be considered safe under any circumstances is the password itself. Figure 2 demonstrates that using a common password-cracking tool and an even more common password list, a dictionary attack was able to break the password in about 310 milliseconds. Not surprisingly, the password used for the admin interface can be found in just about every password list available on the Internet. To give you a hint, it was as good a choice for a password as 12345 (which is not the actual password, but close enough, the Levenshtein distance from the real one is only 2).

Figure 2. Admin password cracked within a fraction of a second.

So my educated guess for the method of obtaining the source is the following: the attacker identified a Blackhole attack, then traffic or static analysis led to the C&C server. Then came a tricky bit: finding out the login filename leading to the admin interface, which was the guessable adm.php. However, a more easily guessable file (and the one commonly used in exploit kits), stats.php, redirects to the admin page. I have no data to support the suggestion that the attacker knew about this, or could decode Russian, but there were screenshots available of the 1.0.0 version admin panel, which could have given the attacker a clue as to the filenames.

Having figured that out, the attacker could gain access to the admin interface and in somewhere between five and 50 attempts guessed the admin password. After that the attacker uploaded the C99Shell file, directly accessed it in a browser, which gave access to the files within the Blackhole home directory. Mental note: if you maintain a C&C server, use a strong password.

There is also a clue regarding where this particular server was originally located. Blackhole kits use (among others) Java components for downloading the Win32 binaries, and these Java components were linked into the HTML page returned by the server during the attack.

In the specific server set-up (defined in config.php and used in the main downloader generator file, index.php, when dynamically creating the downloader script), the path to this component was set to 195.80.151.59\pub\new.avi.

Storing these JAR files in the /pub directory was common in early 2011 Blackhole attacks. This file was not found in the leaked source for the obvious reason that it was not present in the kit’s home directory.

Despite the .avi extension, the components used this way were in fact JAR files. The actual usage varied during the observed period, with two main tendencies: they were either referenced from the main download HTML page in an <applet> tag, with full URL (the more common approach in the analysed sample set), or from within the encrypted main script, dynamically creating the applet with createElement and assigning the relative or absolute path within the server home to the archive attribute. Server code analysis revealed that in this particular case the URL to the Java component was used from within the encrypted main code – fortunately this time the full URL version was configured.

What was found in all analysed cases was the fact that the JAR was referenced from the same server as the one that hosted the exploit kit, never pointing to an external server. This leads us to the conclusion that the cracked server was in fact 195.80.151.59.

This IP was known to host various malware back in February 2011 (though not Blackhole, but the Phoenix backend was reported), then under domain name tuqidig5.co.cc (and a few others, like dubezov3.co.cc, gube2qome8.cz.cc, cepepeler28.co.cc and dofubuhud57.co.cc were listed with the same IP), registered to a company located in Belize. Nowadays it belongs to a Polish ISP and is unrelated to malware.

Figure 3. Server config including crucial script names.

It is understandable that malware authors do not have time to write each module from scratch, thus they use the generally available example codes. For instance, it is easy to recognize that this code snippet is a standard MySQL query sequence:

if ( @!_obfuscate_DQgSFjcQI1w8Wxo7GjUTMhwUJhc1BiIÿ( @( “MysqlHost” ), @( “MysqlUsername” ), @( “MysqlPassword” ) ) )
{
   throw new exception( _obfuscate_DRgQDxsMHjgbHQcLKBgoNiQXCgYnGREÿ( ) );
}
   if ( @!_obfuscate_DQsfFxgOEDw_MhIiDiRbORcpFiQqWwEÿ( @( “MysqlDatabase” ) ) )
{
   throw new exception( “unable to select database” );
}
_obfuscate_DQIuEgQHBzM_MTQkFD4YCjILNzcvCCIÿ( “UPDATE Logs SET ExploitID=”._obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ
( $_GET[‘e’] ).”, FileID=”._obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ( $_GET[‘f’] ).”, IPStatus=1 WHERE (IP = inet_aton
(‘”.$_SERVER[‘REMOTE_ADDR’].”’)) and (Redirect=0) and (IPStatus=0) order by DateTime desc limit 1” );
if ( _obfuscate_DQUzJRIPGzAQDgM3EwM5CzEUJgMWKSIÿ( ) == 0 )
{
   exit( );
}

From the messages it is straightforward to identify the key functions, and rewrite the code in this more readable form:

if ( @!mysql_connect( @( “MysqlHost” ), @( “MysqlUsername” ), @( “MysqlPassword” ) ) )
{
     throw new exception( mysql_connect_error( ) );
}
if ( @!mysql_select_db( @( “MysqlDatabase” ) ) )
{
     throw new exception( “unable to select database” );
}
mysql_query( “UPDATE Logs SET ExploitID=”.mysql_real_escape_string( $_GET[‘e’] ).”, FileID=”.mysql_real_escape_string
( $_GET[‘f’] ).”, IPStatus=1 WHERE (IP = inet_aton(‘”.$_SERVER[‘REMOTE_ADDR’].”’)) and (Redirect=0) and (IPStatus=0) 
order by DateTime desc limit 1” );
if ( mysql_error( ) == 0 )
{
     exit( );
}

I could never be sure about mysql_real_escape_string(). It is clear that at that point of the code one of the input sanitizer functions should be present. It could alternatively be stripslashes(), but as it was used in contexts where I felt it was less likely to make sense, I picked the other one.

PHP experts will notice at this point that the code makes no sense this way, the fragment @( “MysqlHost” ) would not compile – clearly something is missing. Good observation, but more on this later…

Some of the function calls use such characteristic parameters that their value reveals the function itself.

As an example, from this code:

_obfuscate_DTg5Dh0xBTxbFg4MARciKw88CwI4FDIÿ( “LastLanguage”, $AuthLanguage, _obfuscate_DSElGBkPOTMkCgoSJD0WDTIyKB0LFiIÿ
( ) + 3600 * 24 * 30, “/” );

it was clear that it has something to do with some variables, a time duration and a path. The logical conclusion is that it is involved in setting a cookie, as this requires these two parameters that are normally not present in function parameter lists together.

setcookie( “LastLanguage”, $AuthLanguage, time( ) + 3600 * 24 * 30, “/” );

Encountering a piece of code like this:

$good = true;
$i = 0;
while ( $i < _obfuscate_DRAxBQwdBxskCygsEhQtIzAOJBUtNAEÿ( $arr ) )
{
    if ( $arr2[$i] != “*” && $arr2[$i] != $arr[$i] )
    {
       $good = false;
       break;
    }

one could easily guess that it is some sort of array comparison. And the obfuscated function in this case should have to do something with the upper boundary of the comparison, which in the case of arrays logically can be nothing else but count().

There are analyses available [6] that show screenshots of the admin panel. Unfortunately not from the 1.0.2 version, but it was possible to obtain screenshots of both a much newer version (1.2.4) and an earlier one (1.0.0 beta). The overall layout around the Files list did not change enough to make the basic elements unrecognizable.

Figure 6. Layout of version 1.2.4.

Figure 7. Layout of version 1.0.0

This observation helped to determine that in this code snippet:

echo ( “Size” );
echo “:</div> “;
echo _obfuscate_DQkmBwc9GR0BMSMUPCQRJTgaHzcGCxEÿ( _obfuscate_DREhMjIUKiQPLx0kHA0pAw4qDjs DzIÿ
( ( “FilesDir” ).”/”.( $file[‘ID’], $file[‘Title’] ) ) );

_obfuscate_DREhMjIUKiQPLx0kHA0pAw4qDjs DzIÿ should be the built-in function filesize().

As a last resort, when my very limited knowledge of PHP was exhausted, I had to seek external help, and turned to an experienced PHP programmer (who happened to be a former colleague of mine, not unknown to regular readers of Virus Bulletin [7]). He pointed out obvious (to him) mistakes, and made new observations about the missing pieces.

He discovered one of the reasons why the Dezender output is not runnable (apart from the obvious fact that the function names are encrypted). Due to the internals of decryption, the methods for setting and getting the parameters in the config file are completely missing. Thus the previously mentioned database connection code had the form:

if ( @!mysql_connect( @( “MysqlHost” ), @( “MysqlUsername” ), @( “MysqlPassword” ) )

whereas it should be:

if ( @!mysql_connect( @Config::get( “MysqlHost” ), @ Config::get ( “MysqlUsername” ), 
@ Config::get ( “MysqlPassword” ) )

In these cases the decoder either left the method blank, or even worse, incorrectly inserted the upcoming decoded function call(s) found in the same source line.

This created indecipherable monsters in the code:

$res = ->_obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ->_obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ
( “select Sort from FilesInRules where (FileID = “._obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ( $fileID ).”) 
and (RuleID = “._obfuscate_DRkHJz41OylAAiEOLBQJXAMvJgUnIhEÿ( $ruleID ).”)” );

whereas it was supposed to be the more friendly:

$res = db::query( “select Sort from FilesInRules where (FileID = “.mysql_real_escape_string( $fileID ).”) 
and (RuleID = “.mysql_real_escape_string( $ruleID ).”)” );

Looking deeper into this phenomenon revealed that this type of function name omission persists for all public class functions calls when they are called from a file other than the one that defined it.

When it comes to the question of from where a particular malware specimen originated, researchers are in a very comfortable situation. We just flip a coin and if it’s heads, then it’s China; if it’s tails, then it’s Russia. If it lands on the edge, then we conclude government sponsored espionage. But there is a more scientific approach as well.

The first thing to investigate is the code itself. At this point we pretend that we have no information gathered from the Internet and underground forums, and rely only on what we have in our hands. What could have been the most revealing factor – the comments inside the source code – were unfortunately removed when the code was treated with ionCube. Fortunately, enough traces were left though.

The default time zone of the installation is hard-coded to Europe/Moscow. And it is set in adm.php, the admin interface, and not in config.php, where the settings are expected to modify on installation.

The user interface supports two languages, English and Russian, the default being set to Russian. The user interface could support several languages in lang.php. The only alternative language supported in the code with its own code branch is Russian. So the two main options are that it was written by an English speaker for the Russian market or by a Russian person for the international market. The admin interfaces experienced in the wild were set to Russian language each time I tried to access them.

The text and variable names in the English user interface are noticeably (even for a non-native English speaker) incorrect in places. On the other hand (and as far as a non-Russian speaking person can determine), the Russian interface texts are grammatically more correct.

There are two character encodings supported in the code with conversion functions: UTF-8, which is a standard, and Windows-1251, which is a Cyrillic encoding.

And as an additional hint, the date format in the code in all places is set to little-endian (D-M-Y). It applies to the majority of the planet, including Russia. The two notable exceptions are fortunately the other two usual suspects; USA uses middle-endian format (M-D-Y), while China uses big-endian format (Y-M-D).

All the evidence supports the assumption that the development of the Blackhole exploit kit took place in Russia.

I can’t say that this was a great surprise, because the first version of this kit was announced on Russian underground forums, and the author claims to be Russian, but it is always good to support anecdotal evidence with facts that are not as trivial to fake as forum comments.

Figure 8. The latest version was also announced in Russian by the author.

(For a larger version of the image in Figure 8 click here.)

The author of the Blackhole kit is reported to be a Russian individual known by the handle Pauncher. More precisely, when the first version of the kit appeared in 2010, there were three people associated with it. The English translation of the readme file of version 1.0 listed Legacy (sales), Pauncher (programmer) and Naron (founder).

As time passed, only Pauncher remained involved with the development and distribution of the kit.

The announcements of the new versions contain an email address and an ICQ number serving as contacts for the author. The very same contacts are listed for the http://crypt.am site, which provides service for inline crypting of scripts in the following construction:

One-time crypt (5 WMZ) – each crypt worths money
Monthly unlim (50 WMZ) – unlimited crypts count in one month

This service seems to be a spin-off enterprise, logically benefiting from the development of the JavaScript cryptor used in the Blackhole main script.