In his blog post last week, Graham Cluley introduced the Win32/Corkow banking Trojan. The malware, which has been in the wild since at least 2011, has demonstrated continuous activity in the past year, infecting thousands of users. Version numbering of the various Trojan modules is another indicator that the malware authors are continually developing the trojan.
The most common infection vector – drive-by downloads – has been used to spread the malware.
This Russian tool for committing bank fraud shares many characteristics with other malware families with a similar purpose, such as Zeus (also known as Zbot), Carberp, Hesperbot, or Qadars, for example, but also contains some unique functionality.
Several features, like enumeration of smart cards, targeting of dedicated banking applications mostly used by corporate customers and looking for user activity regarding online banking sites and applications, electronic trading platform sites and applications and so forth, all suggest that the attackers are focusing their sights on financial professionals and enterprises, whose bank accounts usually hold a higher balance than those of most individuals.
In this post, we expand on the information mentioned by Graham and provide additional technical details.
As is the case with other banking Trojans (for example Win32/Spy.Hesperbot), the architecture of Win32/Corkow is comprised of a main module and several plug-in modules to deliver specific functionality. Each of Corkow’s plug-in modules is implemented as a Dynamic Link Library (DLL). We will refer to the main component as the ‘core DLL’. Most of the other plugins are embedded in the core module but some are downloaded from the C&C server. In either case, the core DLL will load and run these modules, injecting them into various processes in the system. Table 1 presents the different modules seen in all of the Win32/Corkow samples we have analyzed. Note that not all samples necessarily contain every module.
While the core DLL is responsible for launching every module and for downloading configuration data from the C&C, each plug-in module contains the C&C URLs as well and uploads collected data directly.
As can be seen in the table above, Win32/Corkow contains functionality that one would expect from a typical banking trojan, including keystroke logging, screenshots and HTTP form-grabbing for intercepting log-in credentials to online banking. However, the last three listed modules have caught our attention. The trojan uses two dedicated modules to target Russian banking clients: one for iBank2, a widely-used banking application used by several banks, and one for Sberbank, Russia’s largest bank. The module called ‘DC’ searches for indicators of user activity relating to various trading platform applications and sites, standalone banking applications, banking sites, Bitcoin sites, and software and Google Play developer activity. We’ll describe these modules and the core module more in-depth in the following text.
But before we get to that, let’s take a look at Corkow’s installation procedure and its ‘hardware-binding’ technique.
Win32/Corkow features an interesting and relatively sophisticated installation procedure. The trojan is usually delivered to the victim by a dropper executable that contains the core DLL in its resources. When the dropper is run, the installation is carried out in the following steps:
The dropper decrypts the embedded core DLL and calls its DllMain function, passing it one of three paths as a parameter. This path determines where and how the trojan should be installed. The chosen path depends on whether the trojan is being run under a standard user account or an administrator account. The possible values are listed in Table 2.
When the code of the core DLL is running, it will seek a host file to infect. For this, Corkow will select a legitimate DLL file from the %SystemRoot%\System32 directory that meets certain criteria (the file has to be unprotected; and some specific file names and DLL imports are excluded).
Corkow will then infect the selected DLL file by encrypting itself and writing its encrypted body into the resources section of the host. A decryption stub is also written to the file and added as a new export function, so that the malware’s body will be launchable after installation. The name of the export is also dependent on the installation path.
The infected DLL is then saved to the installation path. Note that the host DLL file in the System32 directory remains unchanged.
A Registry entry is made to ensure the malware’s persistence on the system. Again, the Registry key depends on the installation path and is listed in Table 2.
Table 2 - Possible Installation Paths
There are multiple ways to load a DLL and Win32/Corkow will use one of the three methods listed in the table above. Each of the methods loads a different DLL export, hence the different possible names for the decryption stub written into the host DLL during infection.
As stated above, the Corkow core DLL is written in the host DLL’s resources in an encrypted form and also compressed using aPLib, a popular compression library. The encryption used is XOR with the encryption keystream generated by the multiply-with-carry algorithm and derived from the Volume Serial Number of the C:\ disk volume. This way, after installation the Corkow-infected-DLL is bound to the infected machine and will not run on a different computer. This is one way in which Corkow protects itself against malware analysis.
Core DLL, C&C communication
The main module of Win32/Corkow is responsible for extracting the other embedded modules and injecting them into corresponding processes, and for communication with the C&C server.
Corkow contains a list of URLs to which it tries to connect. The initial HTTP requests sent to the server contain some basic system information, the version numbers of individual modules and a generated bot ID. In this way the key for encrypting the communication (consisting of the C&C domain name and the bot ID) is established. The server will then respond with one of a few commands. The supported commands include:
Download and execute arbitrary executable or DLL
Download configuration for certain modules
Wipe an arbitrary file on the system (by rewriting it with random data)
Uninstall itself, with the option of destroying the system
The last two mentioned commands show that, apart from data theft, Win32/Corkow is also able to cause irreparable damage to the system. When the uninstall command is sent with a specific parameter, the trojan will attempt to delete critical system files and overwrite the Master Boot Record and Master File Table with random data, rendering the system unbootable.
The core DLL also contains the functionality to capture screenshots of the desktop, block specific applications from running and enumerate smartcards installed on the system.
The application-blocking functionality is determined by the bot’s configuration. The trojan iterates through running processes (the standard method with CreateToolhelp32Snapshot is used) in an infinite loop, and if the undesired process name is found, attempts to terminate it. Of course, the chances of success for this method in User Mode are limited. It is most probably used to prevent victims from running banking applications (to check their account balances, and so forth).
Unlike other more sophisticated trojans, Corkow cannot interact with smartcards, only enumerate them. Interestingly, it doesn’t even use common Windows API functions for interacting with smartcards, but instead enumerates all hardware devices (using the SetupDi API) and searches for specific device names.
Targeting dedicated banking applications
The way Corkow targets the iBank2 application is quite interesting. iBank2 is a Java application, so Corkow attempts to capture its data by injecting its own malicious Java class into the Java Virtual Machine running iBank2. To achieve this, the trojan first injects its IB2 module into each newly spawned Java process (java.exe or javaw.exe)
The injected code then uses Java Native Interface (JNI) functions to get the pointer to the running Java VM, attaches itself to it (Figure 2) and loads its malicious Java class inside the VM. Figure 3 shows part of the decompiled Java class. The class contains methods for getting the current balance of the victim’s bank account and making screenshots, and is able to copy key files used to authenticate the user.
Notice that the code supports English, Russian and Ukrainian versions of the iBank2 application.
The Java injection technique described does not exploit any vulnerability in the iBank2 application itself. Other banking trojans that have targeted the Java-based iBank2 platform include Win32/Spy.Ranbyus and Win32/Carberp, although different techniques were used in both those cases.
The SBRF module targets banking applications (Win32 platform) used by corporate customers of Sberbank. Like the iBank2 module, the SBRF module can create screenshots and copy key files for authentication.
This module scans for user activity by searching the following:
Browser history – Corkow runs the 3rd party utility BrowsingHistoryView in order to read the history of Microsoft Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari. The Opera web browser history file is opened directly.
Installed applications – by enumerating files in common installation directories
Last-used applications – by enumerating the corresponding Registry entries
Interestingly, though, the module does not send the full results of the search to the remote server. Instead it parses the data and looks for specific finance-related strings from a defined list. The analyzed sample contained strings relating to banking, electronic trading platforms and stock brokerages, digital currencies (including various Bitcoin software and websites), various payment systems, and Google Play developer activity:
Apart from Russian and Ukrainian banks and software, the list also includes a wide range of banks based in Switzerland, Singapore, Latvia, Lithuania, Estonia, Denmark, Croatia, the United Kingdom, Austria and Cyprus (including some banks that are now defunct).
The bot will then notify the attacker if any of the above-mentioned strings are found on the victim’s system.
Win32/Corkow is an example of the consequences of leaked source code from other banking trojans. During the analysis of the Corkow code, it proved fairly easy to spot various different programming styles and parts that were written by the malware authors themselves and other parts that were literally ‘copy & pasted’ from other banking trojans. While Corkow may be technically less sophisticated than some other malware that we’ve analyzed, it will get the job done.
Furthermore, the perpetrators operating the Corkow botnets apparently have a well-conceived modus operandi with a focus on corporate banking users. We can confirm that several thousand users, mostly in Russia and Ukraine, were victims of the Trojan in 2013.
We continue monitoring the threat and will keep you informed of further developments.
Thanks to Anton Cherepanov for his thorough analysis of this malware.
List of SHA1s