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.
Copyright © 2010 Virus Bulletin
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.
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.
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.
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.
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.
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).
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.
|CryptEncrypt||Grabbing plaintext prior to standard encryption.|
|send, WSASend||Grabbing login/password data from HTTP requests.|
|CreateFile||Trapping user activity related to the following files: self.cer, secrets.key and others.|
|GetFileAttributes||Looking 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).|
|GetWindowText||Getting the edit box value in the window named ‘User registration’.|
|TranslateMessage||Intercepting 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, WSASend||Saving 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.
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 directory||Target applications|
|C:\Program Files\Common Files\bssrepp||BS-Client, an e-commerce platform from www.bssys.com|
|C:\Program Files\Common Files\ibank||iBank, an e-commerce platform from www.bifit.com|
|C:\Program Files\Common Files\faktura||Faktura, an e-commerce platform from www.faktura.ru|
|C:\Program Files\Common Files\inist||Inist, an e-commerce platform from www.inist.ru|
|C:\Program Files\Common Files\wm||WebMoney, a web-based payment system|
|C:\Program Files\Common Files\handy||HandyBank, a custom web-based online banking application from www.handybank.ru|
|C:\Program Files\Common Files\rfk||RFK, an e-commerce platform from www.rfc.ru|
|C:\Program Files\Common Files\sbl||Undefined, a custom web-based online banking application|
|C:\Program Files\Common Files\agv||Agava, a cryptography framework, and InterBank, an e-commerce platform from www.alpha.ru|
|C:\Program Files\Common Files\inter||Inter-PRO, an e-commerce platform from www.signal-com.ru|
|C:\Program Files\Common Files\kbp||Unknown custom online banking application|
|C:\Program Files\Common Files\raif||Raiffeisen Bank custom e-banking application, www.raiffeisen.ru|
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, 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:
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.
The infected computer is controlled by commands contained in the configuration file. Table 3 shows the commands that are available.
|!load||Load and run an executable from the given URL|
|!route||Configure the routing table|
|!inject||Traffic injections configuration|
|!kill_os||Killing 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.
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_url||Target URL to apply the HTML modification|
|data_before||HTML mark (pattern) of the beginning of the code segment to be modified|
|data_after||HTML mark (pattern) of the tail of the code segment to be modified|
|data_inject||The 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.