February 28, 2014 at 12:44Win32 / Corkow banking Trojan analysis
Earlier, we wrote about the complex banking malware Win32 / Corkow , which is used by cybercriminals to steal online banking data. This malware has been in active use since 2011 and has shown continued activity last year, infecting thousands of users. Various versions of Win32 / Corkow modules were discovered, which also indicates a continuous development cycle for this tool.
Attackers used a typical method of distributing malicious code via drive-by download. We indicated it in our report for 2013 and mentioned that it is the most common method for delivering malicious code that is used by attackers today. Case withWin32 / Corkow only confirms this data. In this post, we will publish the technical details of the analysis of this malicious program, indicate the banks that Win32 / Corkow is aimed at, and also describe its other features that were not mentioned in the first post.
General information
As with other banking Trojans, for example, Win32 / Spy.Hesperbot, Win32 / Corkow consists of a main module and several plugins that implement the corresponding features. Each such plugin or module is made in the form of a DLL library. In fact, most of the other plugins are embedded in the main DLL, while others are loaded from the controlling C & C server. In any case, this core DLL will inject other modules into the processes running on the system. The table below shows the various modules that we saw in all analyzed Win32 / Corkow samples. Please note that not all malware samples contain each of these modules.
Despite the fact that the core module “Core DLL” is responsible for launching other modules to execute and load configuration data from C&C, each of these modules contains its own list of C & C-servers for downloading data directly there.
As you can see in the table above, the Win32 / Corkow malicious code contains features that are typical of banking Trojans, including a keylogger, a screenshot capture module and web form grabber to steal authentication data from online banking. Nevertheless, the last three modules implement functions that can not often be found in banking Trojan programs. Win32 / Corkow uses two separate modules to compromise the iBank2 RBS application and the Sberbank application, which is used by corporate users to access their account. The last DC module is used to search for indicators of user activity in relation to the following types of information:
The
Win32 / Corkow installation has an interesting and relatively complicated installation procedure. The trojan is usually supplied to the victim as a dropper executable, which contains the main Core DLL in the resource section.
Fig. Installing a dropper in the system.
When the dropper is launched, it installs itself in the system using the following steps:
Possible ways to install malicious code.
There are many ways to load DLLs into the OS, and Win32 / Corkow can use one of the three methods described above. Each of these methods loads the DLL through an export call with different names. All these names belong to a function that decrypts the main body of malicious code from the resource section.
As we indicated above, the main Corkow DLL is written to the resources section of the original system DLL in encrypted form, in addition to this, aPLib compression is applied to it. For encryption, XOR is used with the key, which is formed from the data of the Volume Serial Number of drive C: using the multiply-with-carry algorithm. After installation, the infected Corkow library binds to the infected computer and cannot be launched on another computer. Thus, malicious code protects itself from analysis by virus analysts.
Core DLL and work with C&C
The main Win32 / Corkow module is responsible for extracting its other modules and introducing them into the corresponding processes, as well as working with the C & C server. The malicious code contains a list of URLs that it is trying to contact. The initial HTTP request that is sent to the server contains basic information about the system, the version of certain modules, and the Bot ID. At the same stage, a key is selected to encrypt subsequent messages with the server, which is based on the C&C domain name and Bot ID. The server then responds using one or more commands. The following are listed commands.
The last two commands indicate that in addition to data theft, Win32 / Corkow can cause serious damage to the OS. When the server sends the bot a command to remove itself from the system, it can pass a special parameter that tells the bot that the system needs to delete the critical system file and overwrite the MBR or NTFS MFT with arbitrary data. After such operations, the system becomes unbootable.
The Core DLL also contains features for capturing desktop screenshots, blocking the launch of certain applications and listing smart cards installed in the system. The blocking policy for launching applications is determined by the configuration of the bot. Malicious code in an endless loop enumerates processes running on the system through CreateToolhelp32Snapshot, and then tries to terminate the processes specified in the configuration. This process termination occurs from user mode, so the chances of a successful completion are limited. This practice is probably used by malicious code to prevent the user from launching banking applications, for example, to check the balance of their account.
Unlike other , more complex trojans, Corkow cannot interact with smart cards, but only lists them. Interestingly, to obtain information about smart cards, the malicious code does not use the Windows API, but instead lists the physical devices of the cards (using the SetupDi API for this ), further searching for the given device names.
Compromise of individual banking applications
We already wrote that Corkow is aimed at compromising the iBank2 RBS system. iBank2 is a Java application, in turn, the malicious code tries to access the data of the system of this online banking system by introducing its own malicious Java class into the Java virtual machine, in the context of which iBank2 works. To accomplish this task, Corkow embeds the IB2 module (see above) in each Java process created (java.exe or javaw.exe).
Fig. Malicious Corkow code that injects itself into created Java Virtual Machine (JVM) processes.
The implemented code further uses the Java Native Interface (JNI) functions to perform the necessary operations: obtaining a pointer to a working JVM, injecting it into it, and loading a malicious Java class. The figure below shows part of a decompiled Java class. This class contains methods for obtaining the current balance of the victim’s bank account, a code for taking screenshots of the desktop, and a code for copying key files, which is used to authenticate the user in the online banking system.
Fig. The malicious Java class used to attack iBank2. It can be seen that the code supports the English, Russian and Ukrainian versions of the iBank2 application.
The described Java code injection method does not rely on any vulnerability in the iBank2 application. We have observed other banking Trojans that are aimed at compromising this RBS, for example, Win32 / Spy.Ranbyus and Win32 / Carberp , both use different methods to achieve their goal. The SBRF module is used to compromise the banking application of Sberbank (Win32 platform). Like the IBank2-oriented module, the SBRF code can create screenshots and steal key files that are used to authenticate the client.
DC
module This module recognizes user activity by searching for the following information.
An interesting fact is that malicious code does not send complete search results to a remote server. Instead, he analyzes the data and tries to find certain lines that could identify the application for working with finances. The analyzed Corkow sample contains lines related to banking and trading platforms, as well as digital currencies (including websites and software related to Bitcoin), various payment systems and identification of possible developer activity for Google Play (Google Play developer activity).
Fig. Various financial applications and websites targeted by the Corkow DC module.
You can see that in addition to software and websites focused on Russian and Ukrainian banks, the list contains a wide range of banks from Switzerland, Singapore, Latvia, Lithuania, Estonia, Denmark, Croatia, the UK, Austria and Cyprus (including some banks that no longer work).
Conclusion
malware Win32 / Corkow is an example of how attackers can exploit the leaked source codeCarberp. Corkow’s analysis makes it fairly easy to detect various programming styles, in particular those parts of the code that were written by the authors of the malware themselves or those that were copied from other malware. Despite the fact that Corkow can be technically less complex than some other malware that we analyzed before, it contains all the necessary features to steal user confidential data.
The criminals who operate the Corkow botnet seem to have a well-thought-out plan of action, with particular attention to users of online banking systems. We can confirm that several thousand users in Russia and Ukraine in 2013 were already victims of this malicious code.
Prevention of infection
Often, users are interested in how to protect themselves from infection with such malicious programs, so here we will give some recommendations.
Attackers used a typical method of distributing malicious code via drive-by download. We indicated it in our report for 2013 and mentioned that it is the most common method for delivering malicious code that is used by attackers today. Case withWin32 / Corkow only confirms this data. In this post, we will publish the technical details of the analysis of this malicious program, indicate the banks that Win32 / Corkow is aimed at, and also describe its other features that were not mentioned in the first post.
General information
As with other banking Trojans, for example, Win32 / Spy.Hesperbot, Win32 / Corkow consists of a main module and several plugins that implement the corresponding features. Each such plugin or module is made in the form of a DLL library. In fact, most of the other plugins are embedded in the main DLL, while others are loaded from the controlling C & C server. In any case, this core DLL will inject other modules into the processes running on the system. The table below shows the various modules that we saw in all analyzed Win32 / Corkow samples. Please note that not all malware samples contain each of these modules.
Despite the fact that the core module “Core DLL” is responsible for launching other modules to execute and load configuration data from C&C, each of these modules contains its own list of C & C-servers for downloading data directly there.
As you can see in the table above, the Win32 / Corkow malicious code contains features that are typical of banking Trojans, including a keylogger, a screenshot capture module and web form grabber to steal authentication data from online banking. Nevertheless, the last three modules implement functions that can not often be found in banking Trojan programs. Win32 / Corkow uses two separate modules to compromise the iBank2 RBS application and the Sberbank application, which is used by corporate users to access their account. The last DC module is used to search for indicators of user activity in relation to the following types of information:
- trading platform applications;
- trading platform sites (browser history);
- individual banking applications;
- banking sites (browser history);
- Bitcoin sites
- Android application development tools.
The
Win32 / Corkow installation has an interesting and relatively complicated installation procedure. The trojan is usually supplied to the victim as a dropper executable, which contains the main Core DLL in the resource section.
Fig. Installing a dropper in the system.
When the dropper is launched, it installs itself in the system using the following steps:
- Decrypts the main DLL located in the resource section and executes it through a call to the DllMain function , passing it one of the paths as an argument. This path determines how and in what location on the volume the trojan should be installed. The path you choose depends on which account the dropper was launched under, a regular user or administrator. Possible installation paths are shown in the table below.
- When the main DLL code is executed, it searches for a system file for infection. To do this, Corkow searches by a certain criterion for a legitimate DLL from the% SystemRoot% \ System32 directory. The search criteria include the insecurity ( SfcIsFileProtected ) of the desired library and some specific file names, as well as the absence of certain imports from the DLL.
- Next, the malicious code infects the selected DLL by encrypting its body and writing this encrypted data to the resource section of the selected DLL. The function (stub) of the decryption of the body is also written to the file and its address is added to the export table. The name of this export also depends on the installation path.
- The infected DLL is saved at the selected installation path. Note that the original DLL in the system32 directory remains unchanged.
- Malicious code installs the appropriate registry key to ensure code survivability after a reboot. The registry key also depends on the installation path, which are listed in the table below.
Possible ways to install malicious code.
There are many ways to load DLLs into the OS, and Win32 / Corkow can use one of the three methods described above. Each of these methods loads the DLL through an export call with different names. All these names belong to a function that decrypts the main body of malicious code from the resource section.
As we indicated above, the main Corkow DLL is written to the resources section of the original system DLL in encrypted form, in addition to this, aPLib compression is applied to it. For encryption, XOR is used with the key, which is formed from the data of the Volume Serial Number of drive C: using the multiply-with-carry algorithm. After installation, the infected Corkow library binds to the infected computer and cannot be launched on another computer. Thus, malicious code protects itself from analysis by virus analysts.
Core DLL and work with C&C
The main Win32 / Corkow module is responsible for extracting its other modules and introducing them into the corresponding processes, as well as working with the C & C server. The malicious code contains a list of URLs that it is trying to contact. The initial HTTP request that is sent to the server contains basic information about the system, the version of certain modules, and the Bot ID. At the same stage, a key is selected to encrypt subsequent messages with the server, which is based on the C&C domain name and Bot ID. The server then responds using one or more commands. The following are listed commands.
- Reboot the system.
- Download and execute an executable or DLL.
- Refresh bot.
- Download the configuration file for individual modules.
- Destroy an arbitrary file on the disk (overwriting it with arbitrary data).
- Remove yourself from the system (with the ability to disable the system, i.e. disrupting its operation).
The last two commands indicate that in addition to data theft, Win32 / Corkow can cause serious damage to the OS. When the server sends the bot a command to remove itself from the system, it can pass a special parameter that tells the bot that the system needs to delete the critical system file and overwrite the MBR or NTFS MFT with arbitrary data. After such operations, the system becomes unbootable.
The Core DLL also contains features for capturing desktop screenshots, blocking the launch of certain applications and listing smart cards installed in the system. The blocking policy for launching applications is determined by the configuration of the bot. Malicious code in an endless loop enumerates processes running on the system through CreateToolhelp32Snapshot, and then tries to terminate the processes specified in the configuration. This process termination occurs from user mode, so the chances of a successful completion are limited. This practice is probably used by malicious code to prevent the user from launching banking applications, for example, to check the balance of their account.
Unlike other , more complex trojans, Corkow cannot interact with smart cards, but only lists them. Interestingly, to obtain information about smart cards, the malicious code does not use the Windows API, but instead lists the physical devices of the cards (using the SetupDi API for this ), further searching for the given device names.
Compromise of individual banking applications
We already wrote that Corkow is aimed at compromising the iBank2 RBS system. iBank2 is a Java application, in turn, the malicious code tries to access the data of the system of this online banking system by introducing its own malicious Java class into the Java virtual machine, in the context of which iBank2 works. To accomplish this task, Corkow embeds the IB2 module (see above) in each Java process created (java.exe or javaw.exe).
Fig. Malicious Corkow code that injects itself into created Java Virtual Machine (JVM) processes.
The implemented code further uses the Java Native Interface (JNI) functions to perform the necessary operations: obtaining a pointer to a working JVM, injecting it into it, and loading a malicious Java class. The figure below shows part of a decompiled Java class. This class contains methods for obtaining the current balance of the victim’s bank account, a code for taking screenshots of the desktop, and a code for copying key files, which is used to authenticate the user in the online banking system.
Fig. The malicious Java class used to attack iBank2. It can be seen that the code supports the English, Russian and Ukrainian versions of the iBank2 application.
The described Java code injection method does not rely on any vulnerability in the iBank2 application. We have observed other banking Trojans that are aimed at compromising this RBS, for example, Win32 / Spy.Ranbyus and Win32 / Carberp , both use different methods to achieve their goal. The SBRF module is used to compromise the banking application of Sberbank (Win32 platform). Like the IBank2-oriented module, the SBRF code can create screenshots and steal key files that are used to authenticate the client.
DC
module This module recognizes user activity by searching for the following information.
- Running processes.
- Browsing History - To access the browsing history of Internet Explorer, Mozilla Firefox, Google Chrome, and Safari browsers, Corkow launches a third-party application, BrowsingHistoryView . In the case of the Opera browser, the history file opens directly.
- Installed applications - by listing files in the appropriate directories of installed applications.
- Last used applications - by listing the relevant registry keys.
An interesting fact is that malicious code does not send complete search results to a remote server. Instead, he analyzes the data and tries to find certain lines that could identify the application for working with finances. The analyzed Corkow sample contains lines related to banking and trading platforms, as well as digital currencies (including websites and software related to Bitcoin), various payment systems and identification of possible developer activity for Google Play (Google Play developer activity).
Fig. Various financial applications and websites targeted by the Corkow DC module.
You can see that in addition to software and websites focused on Russian and Ukrainian banks, the list contains a wide range of banks from Switzerland, Singapore, Latvia, Lithuania, Estonia, Denmark, Croatia, the UK, Austria and Cyprus (including some banks that no longer work).
Conclusion
malware Win32 / Corkow is an example of how attackers can exploit the leaked source codeCarberp. Corkow’s analysis makes it fairly easy to detect various programming styles, in particular those parts of the code that were written by the authors of the malware themselves or those that were copied from other malware. Despite the fact that Corkow can be technically less complex than some other malware that we analyzed before, it contains all the necessary features to steal user confidential data.
The criminals who operate the Corkow botnet seem to have a well-thought-out plan of action, with particular attention to users of online banking systems. We can confirm that several thousand users in Russia and Ukraine in 2013 were already victims of this malicious code.
Prevention of infection
Often, users are interested in how to protect themselves from infection with such malicious programs, so here we will give some recommendations.
- Use in work Windows 7+ x64 . 64-bit up-to-date versions of Windows starting with Windows 7 are much less sensitive to the main infection vector of drive-by download (remote code execution), as they contain special technologies for protection against exploitation.
- Regularly update your OS (enabled by default) and software. Microsoft regularly updates the system libraries of its programs, including ASLR support for them. Some drive-by download exploits take advantage of non-relocatable ASLR modules (e.g. some versions of the .NET Framework, Office) to create stable ROP chains that can be used to bypass DEP within one or more versions of Windows / Office. Regular updates will protect against many exploits, including such.
- Take advantage of Admin Approval Modeand in no case disable UAC, and also do not work under the built-in Administrator account (when UAC is powerless). When UAC is enabled, Windows generates an auxiliary access token for a user account that is a member of the administrators group. This additional token is used to represent the user in the system and contains a disabled Administrator group (Deny SID), which allows you to approve or deny actions introduced by programs that require administrator rights. Malicious programs contain LPE exploits for bypassing UAC or installing kernel-mode restrictions bypassing the OS (user-mode restrictions escape), but such methods work only on out-of-date (outdated) OSes on which they do not install updates in a timely manner. The practice of using 0day LPE / RCE exploits for malicious code,
- Use a security / AV product to protect your OS. This will allow you to control operations at the file system level, data transferred from the Internet, as well as other transactions conducted in the OS. Today, many of these products contain built-in protection against exploits. For example, the latest version of ESET Smart Security 7 contains a special HIPS setting called the "Exploit Blocker" and allows you to timely detect the actions of exploits in applications.
- Use browsers that support sandbox and other technologies that restrict tab processes in their actions. Even if the exploit contains browser code using the RCE vulnerability, while in an isolated process, it will not be able to perform basic functions, for example, load a payload from a remote server or dump its file into a file system.
- To date, the most secure solution is to use Windows 8+ x64 with integrated OS-level SmartScreen and active EMET in the system, which is configured to protect the browser, especially 32-bit. Note that by default, most browsers work in 32-bit compatible mode (Google Chrome & Mozilla Firefox do not have 64-bit options; the latest Internet Explorer 11 starts its processes as 32-bit by default). The practice of using an AV product in this configuration is also necessary, since it will allow you to track down attempts to "land" malicious code in the OS based on antivirus signatures and heuristics. SmartScreen allows you to perform similar actions due to replenished Microsoft blacklist-base.
- Note that no standalone-app or in-browser RBS system can resist the attack of malicious code or ensure the integrity of its code in memory if the OS itself is compromised. When you compromise the OS, you automatically compromise all applications running on your system, including applications for working with online banking or your browser. Almost any malicious code contains on-the-fly process code modification mechanisms (runtime-patching / injection), which the application cannot cope with to ensure its integrity. Systems like HIPS will help you track this behavior of malicious code.