Case study: the Ibank trojan


Alisa Shevchenko

eSage Lab, Russia
Editor: Helen Martin


Alisa Shevchenko sheds some light on the technology of online banking fraud with an indepth analysis of the Ibank trojan which targets a wide variety of Russian online banking technologies.

Online banking fraud is one of the most important cyber threats to date. This article aims to shed some light on the technology of online banking fraud by providing a thorough analysis of a prevalent trojan which targets a wide variety of Russian online banking technologies. To the author’s knowledge, all the techniques incorporated in this trojan are up to date, and hazardous to all kinds of online banking solutions both in Russia and elsewhere.

It should be noted that the trojan discussed here is only one part of the puzzle. Namely, the Ibank trojan is only the instrument for harvesting banking credentials and performing automated money transfers on the majority of systems with regular protection. However, to attack systems with stronger protection, an extra set of instruments is used: a custom VNC technology, allowing manual operations to be performed in a stealthy manner, and tools to bypass enhanced security measures such as tokens and one-time passwords. Both of the latter may be plugged into the well-known Zeus trojan – the attacker’s ‘Swiss army knife’ of choice.

Before proceeding to the Ibank analysis, let’s briefly outline the general approaches to online banking fraud, as we discovered during our investigations.

Typical online banking fraud schemes

1. Stealing user credentials

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.

2. Attack from inside the victim

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.

3. Automated online banking manipulations

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.

Ibank: the analysis

Ibank is a widespread trojan, targeted at a number of Russian online banking systems. The targeted systems include:

  • Universal e-commerce platforms, widely deployed by Russian banks to provide online banking functionality;

  • The custom online banking solutions of specific banks (web-based as well as standalone applications);

  • The WebMoney system (the Russian equivalent of PayPal);

  • A number of government-licensed cryptography solutions, which provide generic encryption and key management support to e-commerce platforms.

Ibank is worthy of a detailed analysis for the following reasons:

  • It is the number one banking trojan, based on the number of target systems;

  • It is the first trojan targeted at Russian banks, and the only all-purpose one;

  • Ibank is widespread, and is actively being propagated. According to the Kaspersky Virus Watch service, the lab adds from five to 20 signatures daily for this trojan.

What is even more important about the Ibank trojan is that it has been seen widely employed in targeted financial attacks along with the Zeus trojan. Specifically, the Ibank trojan is used to dump access credentials for the target systems discovered on an infected victim, while the Zeus trojan represents a volatile all-purpose tool to provide general data harvesting and remote control functionality on the victim.

General information

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:


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.

Installation and general functionality

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:

  • A simple backdoor is available, allowing the infected computer to be controlled through a short list of commands.

  • A powerful mechanism is available to filter or modify web traffic. This can be used to automate financial transactions via the web, as well as to mask the modified bank account summary.

  • The victim’s routing table can be reconfigured at the attacker’s command. This may be used to channel traffic for specific websites through malicious gates.

  • The trojan runs a SOCKS proxy on a random port, which may be used to bypass client IP address checks during authentication with stolen credentials.

  • A number of anti-virus programs are blocked: Kaspersky, Avira, AVG and CA HIPS.

Spying functionality

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:

  • Intercepting keystrokes in the context of browsers, specific processes, specific windows and edit boxes;

  • Intercepting web traffic from browsers to grab HTTPS plaintext;

  • Copying key files and certificates;

  • Exporting certificates from browsers, optionally using storage password brute-forcing;

  • Matching HTTP requests by a pattern to extract important data, such as login, password and session ID;

  • Harvesting the browsing history;

  • Retrieving deleted and restored files (.chk).

Data harvesting mechanism

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.

Hooked APIPurpose
CryptEncryptGrabbing plaintext prior to standard encryption.
send, WSASendGrabbing login/password data from HTTP requests.
CreateFileTrapping user activity related to the following files: self.cer, secrets.key and others.
GetFileAttributesLooking for the file signature ‘iBKS’ (which is the signature of a specific online banking software key file).
vb_pfx_import(sks2xyz.dll)Grabbing the files prv_key.pfx and sign.cer.
RCN_R50Buffer(FilialRCon.dll)Grabbing plaintext prior to custom encryption (product-specific).
GetWindowTextGetting the edit box value in the window named ‘User registration’.
TranslateMessageIntercepting of keyboard keys in the context of the following modules: cbsmain.dll, intpro.exe, isclient.exe, java.exe and others.
PR_Write(nspr4.dll)Intercepting HTTPS traffic in the Mozilla browser.
<API exported by the ordinal> (opera.dll)Intercepting HTTPS traffic in the Opera browser.
Send, WSASendSaving the POST request data: name, pass, login, password.
HttpSendRequest*Saving the HTTP request data matched by the following pattern: action=auth&np=&PHPSESSID=,IW_FormName=fmLogin&IW_FormClass=TfmLog,CryptoPluginId=AGAVA&Sign=.

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

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:

  • Vb_pfx_import is exported from the sks2xyz.dll module, which is part of the Factura e-commerce solution deployed widely at various Russian banks including Sberbank;

  • The RCN_R50Buffer function is exported from the FilialRCon.dll, which is the part of the custom online banking solution deployed at Raiffeisen Bank.

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.

Target systems

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

Data directoryTarget applications
C:\Program Files\Common Files\bssreppBS-Client, an e-commerce platform from
C:\Program Files\Common Files\ibankiBank, an e-commerce platform from
C:\Program Files\Common Files\fakturaFaktura, an e-commerce platform from
C:\Program Files\Common Files\inistInist, an e-commerce platform from
C:\Program Files\Common Files\wmWebMoney, a web-based payment system
C:\Program Files\Common Files\handyHandyBank, a custom web-based online banking application from
C:\Program Files\Common Files\rfkRFK, an e-commerce platform from
C:\Program Files\Common Files\sblUndefined, a custom web-based online banking application
C:\Program Files\Common Files\agvAgava, a cryptography framework, and InterBank, an e-commerce platform from
C:\Program Files\Common Files\interInter-PRO, an e-commerce platform from
C:\Program Files\Common Files\kbpUnknown custom online banking application
C:\Program Files\Common Files\raifRaiffeisen Bank custom e-banking application,

Table 2. A standalone directory is created for each target system located on the victim.

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,,, links.log.

Blocking of anti-virus solutions

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);

Network connectivity

The trojan performs the following network-related activities:

  • Immediately following installation, a SOCKS server is started on a random port.

  • Next, the trojan informs the malicious server of the victim’s summary: username, computer name, SOCKS port number.

  • The configuration file is then received from the server.

  • After the data is harvested, it is sent to the gate.php script at the malicious server via a POST request.

  • Upon receiving the command, the trojan may download and run a custom executable.

Remote control

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

!loadLoad and run an executable from the given URL
!routeConfigure the routing table
!injectTraffic injections configuration
!kill_osKilling of the infected system by writing trash to the disk’s first sectors and deleting of important system files

Table 3. The available commands in the configuration file.

Automated online banking manipulations

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.

set_urlTarget URL to apply the HTML modification
data_beforeHTML mark (pattern) of the beginning of the code segment to be modified
data_afterHTML mark (pattern) of the tail of the code segment to be modified
data_injectThe replacement code

Table 4. The name and purpose of each variable.

In addition, the following options are supported:

  • G or P – to modify the behaviour of the set_url variable to process GET or POST requests, respectively;

  • L – to dump the matched HTML code to a log file instead of performing the replacement;

  • D – to set replacement periodicity.

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


Malware-based online banking fraud techniques are currently well developed, and the tools are readily available on the black market. Existing technologies allow automated or semi-automated fraud to be performed on an infected client, which allows massive attacks to be performed.

A deep understanding of online banking system internals is not required to perform targeted attacks, and many of the current security measures can successfully be bypassed by attackers’ tools.

Any online banking solution is vulnerable to current attack technologies, as long as it runs on an insecure operating system.



Latest articles:

VB2018 paper: Office bugs on the rise

It has never been easier to attack Office vulnerabilities than it is nowadays. In this paper Gabor Szappanos looks more deeply into the dramatic changes that have happened in the past 12 months in the Office exploit scene.

VB2018 paper: Tracking Mirai variants

Mirai, the infamous DDoS botnet family known for its great destructive power, was made open source soon after being found by MalwareMustDie in August 2016, which led to a proliferation of Mirai variant botnets. This paper presents a set of Mirai…

VB2018 paper: Hide’n’Seek: an adaptive peer-to-peer IoT botnet

This paper presents a thorough analysis of the inner workings of Hide’n’Seek, a peer-to-peer IoT botnet discovered in January 2018. With an exploit table that can be updated in memory and modular in its approach, Hide’n’Seek gives us a glimpse of…

Botception: botnet distributes script with bot capabilities

Researchers Jan Sirmer and Adolf Streda describe the branch of the Necurs botnet that they have been monitoring, the changes it has undergone in the course of a year, and present an analysis of the next stage of the attack: Flawed Ammy.

VB2018 paper: Since the hacking of Sony Pictures

Minseok (Jacky) Cha describes various attacks in Korea which occurred after the Sony Pictures hacking incident and which are suspected to be the work of the same group, the Lazarus Group.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.