One piece of advice that often appears in closed message boards used by Russian cybercriminals is “Don’t work with RU”. This is a kind of instruction given by more experienced Russian criminals to the younger generation. It can be interpreted as: “don’t steal money from people in Russia, don’t infect their machines, don’t use compatriots to launder money.”
“Working with RU” is not a great idea where cybercriminals’ safety is concerned: people from other countries are unlikely to report an incident to the Russian police. In addition, online banking is not very popular in the RU zone – at least, it is much less popular than in the West. This means that the potential income from operating in the RU zone is lower than in other zones, while the risk is higher. Hence the rule “Don’t work with RU”.
As always, there are exceptions to the rule. A rather prominent banker Trojan – Lurk – that is the subject of this paper has been used to steal money from Russian residents for several years.
We have written about this banker Trojan before. It caught our attention almost as soon as it appeared because it used a fileless spreading mechanism – malicious code was not saved on the hard drive and ran in memory only. However, until now no detailed description of Lurk had been published.
What Makes the Trojan Different
The Lurk banker Trojan is in a league of its own when it comes to malware designed to steal money from bank customers:
- Lurk has existed and actively evolved for over five years, but it works selectively – only on those computers where it can steal money. In the more than five years that it has been active, about 60,000 bots have been registered in the C&C, which is not a huge number.
- Lurk is a versatile banker Trojan – it can steal money not only from the iBank 2 system that is used by many Russian banks but also from the unique online banking systems of some large Russian banks.
- Lurk actively resists detection: its developers work hard to minimize detections of their Trojan, while targeted attacks make it difficult to get new samples quickly.
- Based on the methods of internal organization used in the malware, its feature set and the frequency with which it is modified, it can be concluded that a team of professional developers and testers is working on the project.
This is not to say that the Trojan is particularly well written: we have seen and analyzed banker Trojans with much higher code quality. Moreover, our analysis of Lurk has shown that several programmers with different levels of qualification have worked on the code. The developers clearly made some bad choices in places, which have remained unfixed for years (needless to say, we are not going to alert the developers to their mistakes). It is worth noting that the malware writers are developing their product: we see that the quality of code has improved over time and the solutions chosen by the developers have generally improved. What sets Lurk apart is that it is highly targeted – the authors do their best to ensure that as many victims of interest to them as possible get infected without catching the attention of analysts or researchers. The incidents known to us make us believe that Lurk is successful at what it was designed for: we regularly receive reports of thefts from online banking systems and forensic investigations after the incidents reveal traces of Lurk on the affected machines.
The cybercriminals are interested in the following types of organizations:
- IT organizations working in telecommunications field;
- mass media and news aggregators;
- banks and financial organizations.
Compromised computers of IT and telecoms companies provide the cybercriminals behind Lurk with new transfer servers through which traffic goes to the attackers’ servers. Media and news aggregator sites, particularly those visited by accountants, are used to infect a large number of users from Lurk’s ‘target audience’. Banks and financial organizations are of interest to the cybercriminals in connection with their main goal – stealing money.
We won’t comment on the reasons behind the malware authors’ attempts to get a foothold on the machines inside security agencies (these organizations are also among those targeted by Lurk).
The Trojan’s targets appear to include Russia’s four largest banks.
The well-known technique of drive-by downloads is used to distribute the Lurk banker Trojan. In addition, the cybercriminals distribute the Trojan via compromised websites with legitimate software and across corporate networks – using the psexec utility.
Infecting Using an Exploit Pack
Lurk is distributed primarily using the infamous Angler exploit pack (cybercriminals call it XXX). With this method of distribution, users don’t have to do anything in particular for their computers to become infected.
Angler is rightfully considered the flagship of exploit packs: exploits for new vulnerabilities are nearly always first implemented in Angler and only later make their way into other exploit packs (or perhaps are just borrowed’). Exploits for zero-day vulnerabilities are also often implemented in Angler, making the exploit pack particularly dangerous.
Preparation for infecting new victims with Lurk is usually performed as follows:
- A website that is of interest to the target audience is selected. This can be a message board for accountants, a news portal, etc.
The website is infected by stealthily placing a link on it that leads to the exploit pack’s landing page. If it proves impossible to infect the site, a malicious link is placed into the materials of some ‘affiliate program’ that are shown on the site.
- Users visiting the site are redirected to the exploit pack’s landing page without their knowledge. Angler attempts to exploit some vulnerability in the software installed on the user’s computer, which should result in the execution of Lurk’s downloader – mini.
Curiously, the link to the exploit pack’s landing page is either placed for a short time or is regularly placed and removed. For example, we have seen the message board of a well-known magazine for accountants become infected. A malicious link appeared on the message board on weekdays for exactly two hours at lunchtime. Of course, we detected the anomalous activity and notified the owners of the resource. However, by the time they read our letter the resource was clean again and they could not identify the infection. At the same time, during the period when the malicious link was shown on the message board, the Lurk owners managed to infect several new user machines.
Infecting via Compromised Websites
The second method of infection that the cybercriminals used extensively is the distribution of malicious code via legitimate websites. Apparently, this distribution method involves providing infected files to users in the RU zone only, while other users get clean files.
Infecting Machines across a Corporate Network
The scheme whereby one computer in an organization is initially infected is very popular among cybercriminals. Even if the infected machine itself is of no interest to the attackers, the computer is on the same network and on the same domain with other computers containing information that the Trojan’s owners want. In such cases, the psexec utility developed by Mark Russinovich is used to distribute the malware across the network. A special mini dropper is then used to execute the Trojan’s main module on other computers on the same network. This method can result in dire consequences for the organization, since the security of a computer containing data of interest to the cybercriminals essentially depends on that of the least protected computer on the network that is under attack.
The Trojan consists of several modules that have reasonably rich capabilities. The main Lurk modules are:
- mini module;
- prescanner module;
- core module (the bot’s kernel),
- core_x64 module (64 bit version of the kernel);
- mini_x64 module (64 bit version of the mini module).
The mini Module
In the first stage of an attack involving the Angler exploit pack, a vulnerability found in the user’s software is exploited and the mini module of Lurk banker Trojan is downloaded and executed. As mentioned above, the user can download the malicious file from a compromised website; another possibility is infection over the local network.
By Lurk standards, mini is a small program (100-400 KB). Its main function is to download and execute two other main Lurk modules. The address of the server used by mini is hardcoded in the program’s body. Modules are downloaded using standard GET requests. The modules downloaded by mini are encrypted, with different encryption algorithms used. The prescanner module is encrypted using the simple “xor-next” algorithm. Other modules are encrypted using the BlowFish algorithm (ECB Mode), the pseudo key for which is hardcoded into mini. The real key is created from the hardcoded pseudo key using a sequential search for one character (a brute force attack).
To avoid having to download additional modules every time mini is executed, the Trojan saves these modules in a separate encrypted file located in %APPDATA% folder. The contents of the storage is encrypted with the Blowfish algorithm, using a key that depends on the time the Windows folder was created. In addition to a plugin’s name and body, the storage file includes a list of checksums of the names of those processes in whose context the plugin is to be executed. This information is used by mini to determine which process a plugin should be injected into: for web injection modules, this is a browser process; for the ibank module, it is Java.exe, in whose context the online banking system operates.
The prescanner module
According to the operating logic of mini, the second stage of the attack is to load the prescanner module. The module is a dynamically loaded library with only one exported function – Prescan.
The cybercriminals need prescanner to make their attacks as narrowly targeted as possible. If a machine does not match the specific rules of prescanner and no online banking systems have been found on it, the module reports this to mini and the latter decides not to try to achieve persistence on the machine. In this way, the Trojan’s developers try to avoid attracting the attention of law enforcement agencies and anti-malware product developers. The following fact supports this idea: every time a new bot is registered by the C&C, a unique identifier – bot number – is assigned to the bot. In the more than five years that the banker Trojan has existed, only about 60,000 bots have been registered by the C&C.
Prescanner performs two main tasks:
- collecting information about an infected system;
- grabbing passwords from FTP clients found on the user’s machine.
After collecting information about the machine and checking whether its rules are observed, prescanner sends a report to its command server. In the cases that we have seen, the C&C used by prescanner was the same as that used by the mini downloader.
If it is decided that a machine is unsuitable for a Lurk attack based on the analysis performed, mini and prescanner modules terminate and uninstall themselves. If prescanner has made the decision to ensure persistence on the machine, it reports this to the mini downloader, which in turn downloads and executes the core module – the bot’s main body.
The core module
Core is the main module of Lurk. Its main functions are:
- network interaction with the C&C;
- executing commands received from the cybercriminals;
- logging keypresses (keylogger function) and recording video from the infected system’s screen;
- maintaining the encrypted data storage and Lurk settings;
- downloading, installing and executing the Trojan’s additional modules.
The core module is a communication channel of sorts between all the other malware modules and the command server. The C&C servers used for mini and for core are different. Core does not have a hardcoded command server address. The address of its command server is calculated using DGA – theDomain Generation Algorithm. Among other DGA input parameters, the Trojan’s authors use exchange quotation data received from Yahoo Finance. This means that the data used to generate C&C addresses cannot be known to security experts in advance. As a result, it is impossible to predict the addresses generated by Lurk.
After successfully establishing a connection, data collected by the malware and the results of executing commands are sent to the command server every five minutes, with requests for new updates and commands. All communication between the core module and the C&C is encrypted – core and C&C exchange data is in the JSON format.
The function of intercepting data entered on the keyboard is implemented in the core module in the newer versions of Lurk (starting at least from 8.9773). Keypresses are intercepted only in the context of windows that have specific words/phrases in their names. The list of these words/phrases is received from the C&C.Intercepted data is sent to the command server during the next communication session (every 5 minutes).
The main part of Lurk’s storage is located in the system registry, but some additional data belonging to the storage can be saved as a file on the hard drive. As a rule, files are used to store a large but logically uniform volume of data, such as video captured from the screen or code for web injection. But in any case, links to these additional files are always present in the main part of the storage, which is located in system registry.
The bot’s additional modules (plugins) are downloaded by the core module to those computers the malicious program deems most suitable. Those modules that are required on a specific computer to steal money are downloaded to that computer.
The Lurk modules currently known to us are listed in the table below.
|A set of .class-files designed to introduce changes into the normal operation of iBank 2 systems, in order to steal money.
|An administrative applet for iBank 2 systems modified by cybercriminals, designed to steal credentials and key files from iBank 2 systems.
|This plugin is used to inject malicious applets into the iBank 2 system. These applets (along with other tools) are used to steal money from the user.
|This plugin is designed to organize web injections into the pages of remote banking systems.
|An auxiliary module whose main task is to ensure other Lurk modules are loaded into the contexts of the processes iexplore.exe, firefox.exe, chrome.exe, opera.exe, jp2launcher.exe, java.exe before these processes are actually launched.
|This plugin provides remote access via VNC to the infected computer (for remote control over the infected computer).
|This plugin ensures that RDP is enabled on the infected computer.
|Bot plugin loader at a high Integrity level (required for rdp-plugin-x86 and lsa-plugin-x86).
|The loader of mini. It awaits an IPC message with the name <LurkDll>, after which it loads mini with the help of LoadLibrary(). It is used in the mini launch process while escalating privileges.
|The plugin for grabbing administrator and/or domain accounts (the well-known program mimikatz is used).
We will now look at three bot modules (plugins) in more detail – they are the modules w3bank and ibank.dll – the two workhorses of the Lurk Trojan that are directly involved in stealing money – and the module_vnc module that makes it possible to remotely control the infected system using the VNC protocol.
The w3bank module
The w3bank module is designed for attacks on remote banking systems. Its main task is to perform injections into the user’s browser.
The ibank module
The ibank module is designed to steal money in iBank remote banking systems.
This module runs in the context of a Java virtual machine. When a Java applet is started, it is checked to see whether it belongs to the iBank 2 system. If this remote banking system is launched, a request is sent to the C&C asking if the applet should be blocked or allowed to run. If an “allow to run” command arrives in response, a set of Java-class files is sent to replace the original classes of the iBank applet.
The infected applet enables the cybercriminals to stealthily replace the data in payment orders, leaving the original information in the printouts.
The module_vnc module
The module_vnc module provides the ability to remotely control an infected system using the VNC protocol. When this happens, the remote node gains full access to the system: it can see the image displayed on the screen, send and receive any files or data, including data from video/audio input devices, use the software installed on the machine and install new software.
This module also makes it possible to launch browser processes with the following parameters:
Mozilla Firefox: -profile
Google Chrome: –user-data-dir=
Internet Explorer: -nomerge
Each time Mozilla Firefox and Google Chrome are launched a new browser user profile is created. This helps hide the Trojan’s activities from the legitimate user, who will not be able to see any trace in the history of visited sites. This also helps create a separate session on a website, parallel to an already open session. In particular, this makes it possible to log in a second time to the site the legitimate user is working with, and perform actions in a parallel session that will not affect the user’s session.
Stages of a Lurk attack
As a result, the Trojan’s typical attack sequence is as follows:
- The user’s computer is infected by exploiting a vulnerability;
- The mini module is launched on the infected computer;
- mini downloads the prescanner module and launches it;
- prescanner steals the user’s FTP credentials;
- If an analysis finds that the infected computer is unsuitable, mini and prescanner silently terminate themselves.
- If the infected computer is of interest to the cybercriminals, the attack continues.
- If the attack continues, mini downloads and launches the core module, the bot’s main body.
- core connects to the bot’s C&C server, receives commands from the cybercriminals and executes them.
- core receives the bot’s additional plugins.
- core spies on the user: intercepts data entered from the keyboard, and captures the video stream from the screen of the infected system. Capturing is only performed for windows with specific keywords/phrases in their names. A list of keywords is received from the C&C and is primarily determined by the financial interests of Lurk’s owners.
- Using additional modules (ibank, w3bank), Lurk steals money from remote banking systems.
Example of an Attack on a Bank
During our research, we detected a Lurk attack on a major Russian bank that was using the w3bank module to perform web injections. We were able to obtain the scripts of the injections.
The files of the infection scripts have identical names for different remote online banking systems (content.min.js), but a different GUID, as the latter is generated in a random fashion.
This script intercepts the authentication information entered into the remote banking system. When the user logs in to the remote banking system, their username and password are intercepted. After successful authentication, a parallel session is created that is hidden from the user and in which Lurk scans the banking pages and searches for the card holder’s name and the phone number linked to the card. The malicious script collects all the information required to make a payment in that online banking system. This information is then sent to the C&C server whose address is identical to the network address of the server communicating with the core module.
In response, the C&C server may send a script to be executed in the browser context. We were unable to obtain such a script for this research.
The C&C server may also register an automated payment that will be executed the next time the user logs in to the online banking system.
The Trojan’s creators have made an effort to protect their creation from researchers, and especially to protect Lurk from an in-depth analysis, or, at the very least, greatly hinder such analysis. However, despite all the difficulties of analyzing the Trojan, Lurk is quickly detected by modern anti-malware solutions.
It’s not only anti-malware companies that are countering Lurk; the manufacturer of the iBank 2 system, BIFIT, is also taking measures to combat the attacks launched against its product. The company has implemented methods to counteract banking Trojans in its iBank 2 software and investigated their effectiveness. The BIFIT research shows that of all the protection tools implemented in iBank 2, only control over the bank’s server is effective against Lurk; all the other measures implemented in iBank 2 were successfully bypassed by the Lurk creators, testifying to their professionalism.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.