Exploit.SWF.Agent.br Pdfka.asd Pidief.cvl TDSS TDSS removal binary planting bios infection blind sqli bootkit bootkit remover browser exploitation com hijacking disassembling dll hijacking drive-by downloads hack online banks heap-spray hijack botnet ibank kernel protection kernel-mode rootkit keylogger malware analysis rootkit detection trojan virus removal

Case study: the Ibank trojan

Alisa Esage
@alisaesage

The article is also available in Russian

E-banking fraud is definitely the most importand cyber threat to date. While the existing banking software is completely missing the point, being vulnerable by design to modern e-banking attacks, the criminals’ methods and technologies continue to evolve. Given that no generic solution to the problem is overseen, but a number of workarounds, the threat can never be overestimated.

Today’s robbery is made in virtual, essentially with the help of malicious programs. Afterwards, victims usually succeed at spotting the trojan which enabled the attack, but the exact technology behind the attack remains obscure.

The present article aims to shed some light at the technology of e-banking fraud by delivering a thorough analysis of a wide-spread spying trojan, targeting at a wide variety of Russian e-banking technologies. As per the author’s knowledge, all the techniques incorporated in the discussed trojan are up to date, top-notch, and equally hazardous to all kids of e-banking solutions in or outside of Russia.

Important to mention, the discussed trojan is only one part of the puzzle. Namely, Ibank is the instrument for only harvesting e-banking credentials and performing automated money transfers, which works out on majority of regularly-protected systems. Howewer, to attack systems with stronger protection, an extra set of instruments is used: a custom VNC technology, allowing to perform manual operations on the victim 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 “swiss army knife” of attakers’ choice.

Before proceeding to the Ibank analysis, let’s outline in brief the general approaches to e-banking fraud, as they were discovered during our investigations.

Typical e-banking fraud schemes

Stealing user credentials

The classical scheme for e-banking fraud consists in stealing full pack of user’s credentials which allows the attacker to control the user’s bank account remotely. Depending on the e-banking architecture, the credentials may include username and password, or username, password and a key file or a certificate file. In case that 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, by no means may it be considered outdated. The Ibank trojan, which is analyzed in the following section, is to the author’s best the most powerful malicious instrument allowing to perform this scheme.

Attack from inside the victim

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

The attack consists in 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 user. All user’s data and cookies are shared in the invisible desktop, thus allowing the attacker to parasitize on the existing e-banking web session by manually performing all the necessary operations. In case that 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.

As a platform for this attack scheme, the Zeus trojan is often used, for which the appropriate connection plugin is available for extra payment. Zeus is preferred by fraudsters also for the reason that it supports a rich choice of advanced plugins, allowing to bypass tokens, one-time passwords, and perform advanced automated transactions.

Automated e-banking manipulations

Automated e-banking manipulations, the so-called “avtozaliv” in Russian cyber criminal slang, allows to automate malicious e-banking transactions by means of modification of the web traffic. In general , it works with any web-based e-banking solutions, as well as with Win32-based solutions implemented in a thin client.

The attack consists in manipulating the e-banking application on the web-site level. The rules for such a manipulation may be hardcoded in the trojan or set in the trojan’s configuration file. As soon the set of rules for a particular e-banking application is established, the attacker does not need to control the infected victims, but only to collect the automated money transfers from them. All the rest is done by the program.

An example of a client-side attack against online banking.

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

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

Ibank: the analysis

Ibank is a wide-spread spying trojan, targeted at a number of Russian e-banking systems. The target systems include:

Ibank is worthy of a detailed analysis due to following reasons:

What is even more important about the Ibank trojan, is that it has been seen widely employed at targeted financial fraud attacks along with the Zeus trojan. Specifically, the Ibank trojan is used to dump access credentials for the target systems discovered on 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 has been discovered in 2006. Initially it was seen implemented as a simple instrument to deliver mass attacks at common users of e-banking systems. Howewer, the trojan quickly evolved to support organized crime, and 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.

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

The trojan consists of two pieces: the small loader, and the main working module, which is retrieved by the loader. The loader is propagated via a classical 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 the technical point of view. Howewer, some of its features betray the author’s deep knowledge of e-banking systems.

Installation and general functionality

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

Команда настройки маршрутизации и часть списка IP-адресов в теле программы

Команда настройки маршрутизации и часть списка IP-адресов в теле программы

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

Being executed, the trojan parasitizes on a system service, such as svchost.exe, services.exe and others (which depends on the trojan’s version), instead of running its own process. Apart from providing general stealthiness, this approach allows the trojan to bypass firewall protection due to default whitelisting of its donor process. Howewer, 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 the core spying functionality, Ibank has the following features:

Spying functionality

Immediately following the installation, the trojan hooks a number of APIs in order to trap target applications’ 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 hardcoded in the trojan’s code.

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

Data harvesting mechanism

In order to locate and grab the user’s data related to e-banking systems, the trojan installs the following API hooks.

Hooked API Purpose
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 e-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) Interception of HTTPS traffic in the Mozilla browser
(opera.dll) Interception of 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=

The hooking procedures for the listed hooks provide filtering and harvesting of data and sending it to the malicious server.

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

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

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

Target systems

For each target system located on the victim, a standalone directory is created, into which all the stolen data is dumped.

Data directory Target applications
C:\Program Files\Common Files\bssrepp “BS-Client”, a e-commerce platform from www.bssys.com
C:\Program Files\Common Files\ibank “iBank”, a e-commerce platform from www.bifit.com
C:\Program Files\Common Files\faktura “Faktura“, a e-commerce platform from www.faktura.ru
C:\Program Files\Common Files\inist “Inist”, a e-commerce platform from www.inist.ru
C:\Program Files\Common Files\wm WebMoney, a web-based payment system www.webmoney.ru
C:\Program Files\Common Files\handy HandyBank, a custom web-based e-banking application from www.handybank.ru
C:\Program Files\Common Files\rfk “RFK”, a e-commerce platform from www.rfc.ru
C:\Program Files\Common Files\sbl Undefined , a custom web-based e-banking Application
C:\Program Files\Common Files\agv “Agava”, a cryptography framework, And “InterBank”, a e-commerce platform www.alpha.ru, www.r-style.ru
C:\Program Files\Common Files\inter “Inter-PRO”, a e-commerce platform from www.signal-com.ru
C:\Program Files\Common Files\kbp Undefined , a custom web-based e-banking Application
C:\Program Files\Common Files\raif Reiffeisen Bank custom e-banking application www.raiffeisen.ru

Listed in the previous table are all the major e-commerce systems available on the Russian market, and deployed by the majority of banks. Thus, it is clear that the Ibank trojan allows 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 e-banking solution.

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

Blocking of antiviruses

Kaspersky antivirus is blocked by sending a legitimate control message to the application window:

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

Blocking of Avira is provided by calling to 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 simple closing 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:

Remote control

The infected computer is controled by commands stated in the configuration file.

The following commands are available:

Command Objective
!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.

Automated e-banking manipulations

As per the Ibank, the “avtozaliv” technology consists in manipulating the HTML code of the banks’ websites according to the set of rules, which is defined in the configuration file. Namely, 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. The name and the purpose of each variable is listed in the table below.

Command Objective
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

In addition, the following options are supported:

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

Conclusions

Last updated: 17.03.2012