Case study: the Ibank trojan

The classical scheme for online banking fraud consists of stealing the full pack of user credentials which allows the attacker to control the user’s bank account remotely. Depending on the online banking architecture, the credentials may include username and password, or username, password and a key file or a certificate file. If the victim’s bank performs client IP address verification, the attacker will establish a proxy on the victim’s computer and connect through it to fool the verification system on the server.

While this scheme works only on the most weakly protected systems, it should by no means be considered outdated.

This scheme represents a generic approach to attacking online banking systems with enhanced protection (such as irretrievable keys, token-based encryption and so on). Also, this scheme is used to attack lesser-known systems, since it does not require the attacker to have any knowledge of the target system’s internals.

The attack consists of connecting to the victim’s computer via a custom VNC protocol, which allows the attacker to establish a visual connection with an alternate desktop, invisible to the user. All the user’s data and cookies are shared in the invisible desktop, thus allowing the attacker to piggyback on the existing web session by manually performing all of the necessary operations. If the victim’s computer is hidden behind the NAT or otherwise unreachable from the Internet, the supporting trojan can establish a back-connection to the attacker.

The Zeus trojan is often used as a platform for this attack scheme, using the appropriate connection plug-in which is available for extra payment. One of the reasons Zeus is popular with fraudsters is that it supports a rich choice of advanced plug-ins, allowing tokens and one-time passwords to be bypassed, and advanced automated transactions to be performed.

Automated online banking manipulations, the so-called ‘avtozaliv’ in Russian cybercriminal slang, allow online banking transactions to be automated by means of modification of the web traffic. In general, this works with any web-based banking solution, as well as with Win32-based solutions implemented in a thin client.

The attack consists of manipulating the online banking application at the website level. The rules for such a manipulation may be hard-coded in the trojan or set in the trojan’s configuration file. Once the set of rules for a particular banking application has been established, the attacker does not need to control the infected victims, but only to collect the automated money transfers from them.

There are two types of ‘avtozaliv’ technologies: passive and active. The passive technology consists of the replacement of certain HTML form values or GET/POST requests, such as the destination account number, or the amount of money to be transferred. As such, the passive technology allows attackers to substitute a legitimate transaction initiated by the user with a malicious one. The active technology is more self-contained, enabling all the manipulations that are necessary to perform the transfer, including filling in forms or clicking buttons. In such cases, a malicious transaction can be generated from scratch inside the user’s computer.

It should be noted that implementing such automated technology is not really complex, but rather tedious. Such a technology must be custom-tailored for each separate online banking application, and requires deep study of the application’s HTML structure.

The Ibank trojan was discovered in 2006. Initially, it was seen implemented as a simple instrument to deliver mass attacks on users of online banking systems. However, the trojan quickly evolved to support organized crime, and it started to be seen in targeted attacks a couple of years later. The massive propagation of the Ibank trojan was first noted in 2010 by Dr. Web.

Anti-virus vendors assign the following names to this trojan: Trojan.PWS.Ibank, Backdoor.Win32.Shiz, Trojan-Spy.Win32.Shiz, Backdoor.Rohimafo and others. Interestingly, no anti-virus vendor has provided comprehensive Ibank coverage focusing on its online banking fraud functionality – which is a clear sign that vendors currently underestimate the importance of protection for online banking fraud.

The trojan consists of two pieces: a small loader, and a main working module, which is retrieved by the loader. The loader is propagated via a classic affiliate marketing scheme. Namely, the initial HTTP request sent to the malicious server upon successful trojan installation contains the seller ID:

http://servername/knock.php?n=botID&s=seller-N

The trojan dropper is a ~100KB encrypted file (MD5: 53aec556c00f34182a72ba8edfb8fca9), written in C. Ibank runs completely in user mode, and is rather simple from a technical point of view. However, some of its features betray the author’s deep knowledge of online banking systems.

During installation, the trojan executable is dropped into the system directory (c:\windows\system32) under a random name. At the same point, a number of IP addresses are blocked by the trojan by calling the route command to configure an illegal gateway for each listed IP address. The list of blocked IP addresses is initially hard-coded in the trojan’s code, and refers to a seemingly random list of targets.

The trojan’s startup at boot time is enabled by modification of the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit.

When executed, instead of running its own process the trojan parasitizes a system service, such as svchost.exe, services.exe or others (the service depends on the trojan’s version). Apart from providing general stealthiness, this approach allows the trojan to bypass firewall protection due to the default whitelisting of its donor process. However, the trojan does not try to hide other evidence of its presence in the system, such as the files and the opened port.

Apart from its core spying functionality, Ibank has the following features:

Immediately following installation, the trojan hooks a number of APIs in order to trap the target application’s data. As soon as a target application signature passes through the hook, the grabber procedure is initiated to collect all the available data related to that application, such as specific key files, certificates, logins and passwords, or simply all of the keyboard input. The data is immediately archived and sent out to the malicious server whose address is hard-coded in the trojan’s code.

In general, Ibank performs the following types of grabbing activities:

In order to locate and grab the user’s online banking data, the trojan installs a number of API hooks, as shown in Table 1.

The hooking procedures for the listed hooks provide filtering and harvesting of data, which is sent to the malicious server.

Note that some of the hooked functions represent custom software APIs (undocumented) rather than Windows APIs:

Similarly, the undocumented browser functions are hooked to intercept SSL plaintext: namely, the PR_Write function of Mozilla and the unnamed function of Opera.

Another point to mention is the trojan’s ability to intercept data from Java applications via the TranslateMessage hook.

A standalone directory is created for each target system located on the victim. All the stolen data is dumped into this directory (Table 2).

All the major e-commerce systems on the Russian market are listed in Table 2. These are deployed by the majority of banks. Thus, it is clear that the Ibank trojan can be used to steal user credentials from almost any Russian bank.

In some cases the credentials are extracted from the underlying cryptographic provider, such as Agava software, rather than from the online banking solution.

The harvested data is saved into the appropriate files and archives before being sent to the malicious server: pass.log, keylog.txt, ctunnel.zip, keys.zip, links.log.

Kaspersky Anti-Virus is blocked by sending a legitimate control message to the application window:

FindWindow (“____AVP.Root”);
PostMessage (^, 466h);

The blocking of Avira is provided by calling its own legitimate function, which is exported from one of the product DLLs:

RegQueryValue (“SOFTWARE\\Avira\\AntiVir PersonalEdition Classic”, “Path”);
LoadLibrary (“avipc.dll”);
GetProcAddress (“AvIpcCall”);
GetProcAddress (“AvIpcConnect”);
AvIpcConnect (“avguard01”, 1388h); 
AvIpcCall (...); // turn off Avira

AVG is killed by the simple closing of the application process and dumping trash to the product’s driver file:

CreateFile (“%systemroot%\\system32\\drivers\\avgtdix.sys”);
WriteFile (^, VirtualAlloc (GetFileSize (^)));
OpenProcess (“avgtray.exe”);
TerminateProcess (^);

Finally, CA HIPS is turned off by sending a legitimate control code to the product’s driver:

CreateFile (“\\.\KmxAgent”);
DeviceIOControl (86000054h);

The trojan performs the following network-related activities:

The infected computer is controlled by commands contained in the configuration file. Table 3 shows the commands that are available.

In Ibank’s case, the ‘avtozaliv’ technology consists of manipulating the HTML code of the banks’ websites according to a set of rules defined in the configuration file. The configuration file contains a set of variables which define the location and the replacement data for the piece of HTML code to be modified.

In addition, the following options are supported:

After receiving and parsing the configuration data, the trojan saves it in the HKEY_LOCAL_MACHINE\Software\Microsoft\option_9 registry key.