My colleague Jorge Mieres recently found a C&C server of a botnet based on a malicious program called Ice IX. As announced on several user forums, Ice IX is a bot created using the source code of ZeuS 2.0.8.9, which became publicly available in May. The author of the new bot says the program includes substantial enhancements, which should be interesting to those cybercriminals who steal money from users with the help of banking Trojans.
Figure 1. Description of the bot
As you can see in the screenshot, the description of the new program focuses on the enhancements allegedly introduced into the ZeuS original code. These included bypassing firewalls, bypassing proactive protection provided by security products, and protection from detection by trackers. The latter obviously refers to the ZeuS Tracker <https://zeustracker.abuse.ch>, which has been making cybercriminals’ life difficult. The program’s author charged $600 for a version of the bot with a hardwired URL that the bot must connect to after infection (i.e., the C&C address), and $1800 for a version without a hard-coded C&C address.
Unfortunately, we were unable to obtain a sample of the enhanced Ice IX version – possibly, because nobody had purchased it. Most likely, this version included a mechanism that was similar to that implemented in ZeuS beginning with version 2.1. Here is how it worked in ZeuS: the bot included a key that was used in combination with the current date to generate 1020 domain names each day. The bot searched through this entire list, trying to find its C&C server.
At the same time, someone has apparently tested the base version of the bot kit. These samples were analyzed for differences from the original ZeuS samples used as the basis for the Ice IX bot.
I must confess, I had expected more. The author advertized the programs as something special, and in addition, there was a comment in the thread that the author deserved credit for bypassing proactive detection, since it was an important improvement, concluding that this was no doubt a completely new bot, much better than ZeuS… In fact, however, it was all a bunch of lies. There were no major improvements compared to ZeuS 2.0.8.9 – the version which became publicly available.
Here are the differences I was able to identify:
2). The ZeuS 2.0.8.9 bot can be launched with the following arguments: -f, -n, -v, -i. I won’t go into the discussion of what each of them means. Let me just mention the key –i: if ZeuS 2.0.8.9 sample is launched with this key, a window with some information about the bot will be displayed:
Figure 2. ZeuS 2.0.8.9 information window
The author of Ice IX simply removed the fragment processing this key from the code. Consequently, Ice IX sample does not support this argument.
Figure 3. The function in ZeuS which reads data from the registry
When a value needed to be read from the registry, it was done as follows:
Figure 3a. Calling the function which reads from the registry in ZeuS
In the Ice IX sample, there are some changes in the places where the function is called. The API function RegOpenKeyEx was removed from the function that reads registry data:
Figure 4. The function in Ice IX that reads data from registry
As a result, whenever a value needed to be read from the registry, the API function RegOpenKeyEx was called first to open the registry key (e.g., HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE) before calling the actual registry read function:
Figure 4a. Calling the function to read from registry in Ice IX
I admit that some antivirus products may possibly detect ZeuS based on the presence of the above registry read function. It is quite probable that this essential function is present in all ZeuS samples regardless of version; it is also possible that its code uniquely identifies this entire malware family. Why not, after all? In this case, modifying this function (e.g., removing RegOpenKeyEx) would help to prevent the detection which depends on it.
I didn’t test all antivirus products on Ice IX samples, so I cannot say whether any product would fail to detect them because of this change. I only scanned the sample with KIS 2012 using old antivirus databases dating back to June, when nothing was known as yet about Ice IX. As the bot was runnung, KIS 2012 detected dangerous activity and blocked the program’s execution. No wonder: given the long history and extensive functionality of ZeuS, there are quite a few criteria based on which KIS/KAV can detect this malware family’s malicious code.
Now, let’s move on to the significant changes that distinguish Ice IX from ZeuS 2.0.8.9 at least to some extent.
Let’s look at the way in which the “@” character is used. It is placed before the URL (e.g., @/login.osmp.ru/) to tell the bot to make screenshots when the user visits any addresses matching the mask specified every time that the user left -clicks the mouse, and then to send the screenshots to the cybercriminal. This is a mechanism that allows the cybercriminal to reconstruct the data entered by the user on the website using the virtual keyboard. Other symbols also define specific actions to be performed by the bot. All that the author of Ice IX did was to assign different characters to the same functions: the letters “N”, “S”, “C” and “B” have replaced “!”, “@”, “-“ and “^”, respectively.
id=TEST_WIN_XP_B5DF77116522DF69&hash=DC0D2CAB39D49FC3D5E467501A2682C5
id is the bot’s identifier calculated using the same algorithm as in ZeuS 2.0.8.9. It is used for the bot’s direct communication with the C&C.
The identifier is the computer’s name with a unique 16-digit hexadecimal number added to it. From the C&C viewpoint, both the computer name and the 16-digit number can be arbitrary. This identifier is encrypted using the RC4 algorithm (which ZeuS uses all the time to encrypt data) in combination with an S-box that is also hardcoded into the bot. The MD5 checksum is calculated for the encrypted data and sent as a hash variable. Since the bot identifier can be arbitrary (at the most it needs to meet the COMPUTERNAME_16CHARSHEXNUMBER format), the only data needed to obtain the configuration file is the S-box – it is needed to encrypt the bot identifier. But wait a minute. The configuration file is also encrypted using the same RC4 algorithm with the same S-box. Without the S-box, the configuration file is useless, a meaningless sequence of bytes. The really valuable stuff is inside the file.
So in the end it all comes down to this:
The question is: what is it that is supposed to make trackers’ life more difficult? And the obvious answer is “virtually nothing”. It might perhaps take an extra half hour to run a sample, make a dump, and identify the changes made to known code. And that only is one is going to do the analysis and mass-download different bots’ configuration files. However, there is an easier way: getting the parameters of the POST request from an infected computer’s traffic, which is a matter of a few minutes. With all the hype, you wouldn’t believe it!
There is a saying about sports that can be applied to this situation: It takes one athlete with a 9-meter jump to win the Olympics not 9 athletes with 1-meter jumps. Same here: it doesn’t matter how many times and on how many values are encrypted using the same algorithm and the same key – with the same source data, more iterations of encryption will not result in a significantly stronger encryption algorithm. But apparently, this is not what the cybercriminal was after, and this entire business is fraud, plain and simple. Somebody decided to make some easy money by selling supposedly enhanced malware with functionality that is already publicly available.
Dmitry Tarakanov is a malware researcher at Kaspersky Lab.