Win32 / Corkow Banking Trojan Analysis
Earlier we wrote about the sophisticated banking malware tool Win32 / Corkow , which is used by cybercriminals to steal online banking data. This malware has been in active use since 2011 and has shown continuous activity last year, infecting thousands of users. Various versions of Win32 / Corkow modules were discovered, which also indicates a continuous development cycle of this tool.
Malefactors used a typical method of distribution of a malicious code through the drive-by download. We pointed it out in our 2013 report and mentioned that it is the most common way to deliver malicious code, which is used by cybercriminals to date. The case of Win32 / 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 targets, and also describe its other features that were not mentioned in the first post.
')
General information
As in the case of other banking Trojan programs, for example, Win32 / Spy.Hesperbot , Win32 / Corkow consists of a main module and several plug-ins that implement the corresponding features. Each such plug-in or module is designed as a DLL. In fact, most other plugins are embedded in the main DLL, while others are loaded from the C & C server manager. In any case, this main DLL will inject other modules into the processes running on the system. The table below shows the different 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 for execution and loading configuration data from C & C, each of these modules contains its own list of C & C servers to load data there directly.
As can be seen in the table above, the Win32 / Corkow malicious code contains features that are typical for banking Trojans, including a keylogger, a screen capture module, and a web form data grabber to steal online banking authentication data. Nevertheless, the last three modules implement functions that can be infrequently encountered in banking Trojan programs. Win32 / Corkow uses two separate modules to compromise the iBank2 RB and Sberbank application, which is used to access its account by corporate users. The latest DC module is used to search for indicators of user activity in relation to the following types of information:
Installation
Win32 / Corkow has an interesting and relatively complex installation procedure. The trojan is usually delivered to the victim in the form of an executable dropper file that contains the main Core DLL in the resources section.
Fig. Installing the dropper in the system.
When the dropper is launched for execution, it installs itself into the system using the following steps:
Possible ways to install malicious code.
There are many ways to load a DLL library in the OS and Win32 / Corkow can use one of the three methods described above. Each of these methods loads a DLL through an export call with different names. All these names belong to the function that decrypts the main body of the malicious code from the resources section.
As we indicated above, the main Corkow DLL is written to the resources section of the original system DLL in an encrypted form, besides this, aPLib compression is applied to it. For encryption, XOR is used with a key that is generated from the C Volume: Volume Serial Number data using the multiply-with-carry algorithm. After installation, the infected Corkow library is tied to the infected computer and cannot be run on another computer. Thus, the 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 integrating them into the relevant processes, as well as working with the C & C server. The malicious code contains a list of URLs with which it is trying to contact. The initial HTTP request that is sent to the server contains basic system information, the versions of certain modules and the bot ID 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 with one or more commands. Listed below are such 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 delete itself from the system, it can pass a special parameter that will tell the bot to remove the critical system file in the system and overwrite the MBR or NTFS MFT with arbitrary data. After such operations, the system becomes unloaded.
The Core DLL also contains features for capturing desktop screenshots, blocking the launch of certain applications and listing the installed smart cards. The application launch blocking policy is determined by the bot configuration. The malicious code in an infinite loop enumerates the 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 success 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 his account.
Unlike other , more complex Trojan programs, Corkow does not know how to interact with smart cards, but only lists them. Interestingly, the malicious code does not use the Windows API to retrieve information about smart cards, but instead lists the physical devices of the cards (using the SetupDi API for this), then searching for the specified device names.
Compromise of certain banking applications
We have already written that Corkow is aimed at compromising the iBank2 RB System. iBank2 is a Java application, in turn, the malicious code tries to gain access to 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 operates. To accomplish this task, Corkow injects module IB2 (see above) into each created Java process (java.exe or javaw.exe).
Fig. Malicious code Corkow, which implements itself in the created processes of the Java virtual machine (JVM).
The embedded code further uses the Java Native Interface (JNI) functions to perform the necessary operations: getting a pointer to a working JVM, embedding in it, and downloading 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 used to authenticate the user in the online banking system.
Fig. 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 method of implementing Java code does not rely on any vulnerability in the iBank2 application. We also observed other banking Trojans that are aimed at compromising this DB, for example, Win32 / Spy.Ranbyus and Win32 / Carberp , both use different methods to achieve their goal. The SBRF module is used to compromise Sberbank’s banking application (Win32 platform). Like the IBank2 oriented module, the SBRF code can create screenshots and steal key files that are used for client authentication.
DC module
This module recognizes user activity by searching for the following information.
An interesting fact is that the malicious code does not send full search results to a remote server. Instead, it analyzes the data and tries to find specific strings 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 targeted at Russian and Ukrainian banks, the list includes a wide range of banks from Switzerland, Singapore, Latvia, Lithuania, Estonia, Denmark, Croatia, the United Kingdom, Austria and Cyprus (including some banks that are no longer work).
Conclusion
The Win32 / Corkow malware is an example of how attackers can use Carberp’s leaked source code for their own purposes. When analyzing Corkow, it is quite easy to detect various programming styles, in particular, those parts of the code that were written by the authors of the malicious program themselves or those that were copied from other malicious programs. Although Corkow may be technically less complex than some other malicious programs that we have analyzed before, it contains all the necessary features to steal confidential user data.
The criminals who operate the Corkow botnet seem to have a well-thought-out plan of action, paying particular attention to users of online banking systems. We can confirm that several thousand users in Russia and Ukraine in 2013 have already become victims of this malicious code.
Infection prevention
Often, users are interested in how to protect themselves from infection with similar malware, so here we will give a few recommendations.
Malefactors used a typical method of distribution of a malicious code through the drive-by download. We pointed it out in our 2013 report and mentioned that it is the most common way to deliver malicious code, which is used by cybercriminals to date. The case of Win32 / 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 targets, and also describe its other features that were not mentioned in the first post.
')
General information
As in the case of other banking Trojan programs, for example, Win32 / Spy.Hesperbot , Win32 / Corkow consists of a main module and several plug-ins that implement the corresponding features. Each such plug-in or module is designed as a DLL. In fact, most other plugins are embedded in the main DLL, while others are loaded from the C & C server manager. In any case, this main DLL will inject other modules into the processes running on the system. The table below shows the different 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 for execution and loading configuration data from C & C, each of these modules contains its own list of C & C servers to load data there directly.
As can be seen in the table above, the Win32 / Corkow malicious code contains features that are typical for banking Trojans, including a keylogger, a screen capture module, and a web form data grabber to steal online banking authentication data. Nevertheless, the last three modules implement functions that can be infrequently encountered in banking Trojan programs. Win32 / Corkow uses two separate modules to compromise the iBank2 RB and Sberbank application, which is used to access its account by corporate users. The latest 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.
Installation
Win32 / Corkow has an interesting and relatively complex installation procedure. The trojan is usually delivered to the victim in the form of an executable dropper file that contains the main Core DLL in the resources section.
Fig. Installing the dropper in the system.
When the dropper is launched for execution, it installs itself into 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 selected path depends on the account under which the dropper, a regular user or an administrator was launched. Possible installation paths are shown in the table below.
- When the code of the main DLL is executed, it searches for the system file to infect. To do this, Corkow searches for a legitimate DLL library from the% SystemRoot% \ System32 directory by a certain criterion. The search criterion includes the insecurity ( SfcIsFileProtected ) of the library being searched for and some specific filenames, 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 decrypting 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 in 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 survival 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 a DLL library in the OS and Win32 / Corkow can use one of the three methods described above. Each of these methods loads a DLL through an export call with different names. All these names belong to the function that decrypts the main body of the malicious code from the resources section.
As we indicated above, the main Corkow DLL is written to the resources section of the original system DLL in an encrypted form, besides this, aPLib compression is applied to it. For encryption, XOR is used with a key that is generated from the C Volume: Volume Serial Number data using the multiply-with-carry algorithm. After installation, the infected Corkow library is tied to the infected computer and cannot be run on another computer. Thus, the 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 integrating them into the relevant processes, as well as working with the C & C server. The malicious code contains a list of URLs with which it is trying to contact. The initial HTTP request that is sent to the server contains basic system information, the versions of certain modules and the bot ID 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 with one or more commands. Listed below are such commands.
- Reboot the system.
- Download and execute executable file or DLL.
- Update bot.
- Download configuration file for individual modules.
- Destroy arbitrary file on disk (overwriting it with arbitrary data).
- Remove yourself from the system (with the possibility of disabling the system, ie, disrupting its work).
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 delete itself from the system, it can pass a special parameter that will tell the bot to remove the critical system file in the system and overwrite the MBR or NTFS MFT with arbitrary data. After such operations, the system becomes unloaded.
The Core DLL also contains features for capturing desktop screenshots, blocking the launch of certain applications and listing the installed smart cards. The application launch blocking policy is determined by the bot configuration. The malicious code in an infinite loop enumerates the 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 success 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 his account.
Unlike other , more complex Trojan programs, Corkow does not know how to interact with smart cards, but only lists them. Interestingly, the malicious code does not use the Windows API to retrieve information about smart cards, but instead lists the physical devices of the cards (using the SetupDi API for this), then searching for the specified device names.
Compromise of certain banking applications
We have already written that Corkow is aimed at compromising the iBank2 RB System. iBank2 is a Java application, in turn, the malicious code tries to gain access to 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 operates. To accomplish this task, Corkow injects module IB2 (see above) into each created Java process (java.exe or javaw.exe).
Fig. Malicious code Corkow, which implements itself in the created processes of the Java virtual machine (JVM).
The embedded code further uses the Java Native Interface (JNI) functions to perform the necessary operations: getting a pointer to a working JVM, embedding in it, and downloading 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 used to authenticate the user in the online banking system.
Fig. 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 method of implementing Java code does not rely on any vulnerability in the iBank2 application. We also observed other banking Trojans that are aimed at compromising this DB, for example, Win32 / Spy.Ranbyus and Win32 / Carberp , both use different methods to achieve their goal. The SBRF module is used to compromise Sberbank’s banking application (Win32 platform). Like the IBank2 oriented module, the SBRF code can create screenshots and steal key files that are used for client authentication.
DC module
This module recognizes user activity by searching for the following information.
- Running processes
- Browser history - to access the browsing history of Internet Explorer, Mozilla Firefox, Google Chrome and Safari browsers, Corkow launches the third-party BrowsingHistoryView application. In the case of the Opera browser, the history file opens directly.
- Installed applications - by listing the files in the respective directories of the installed applications.
- Recently used applications - through the listing of the relevant registry keys.
An interesting fact is that the malicious code does not send full search results to a remote server. Instead, it analyzes the data and tries to find specific strings 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 targeted at Russian and Ukrainian banks, the list includes a wide range of banks from Switzerland, Singapore, Latvia, Lithuania, Estonia, Denmark, Croatia, the United Kingdom, Austria and Cyprus (including some banks that are no longer work).
Conclusion
The Win32 / Corkow malware is an example of how attackers can use Carberp’s leaked source code for their own purposes. When analyzing Corkow, it is quite easy to detect various programming styles, in particular, those parts of the code that were written by the authors of the malicious program themselves or those that were copied from other malicious programs. Although Corkow may be technically less complex than some other malicious programs that we have analyzed before, it contains all the necessary features to steal confidential user data.
The criminals who operate the Corkow botnet seem to have a well-thought-out plan of action, paying particular attention to users of online banking systems. We can confirm that several thousand users in Russia and Ukraine in 2013 have already become victims of this malicious code.
Infection prevention
Often, users are interested in how to protect themselves from infection with similar malware, so here we will give a few recommendations.
- Use in the work of Windows 7+ x64 . 64-bit up-to-date versions of Windows starting with Windows 7 are much less sensitive to the main vector of the drive-by download infection (remote code execution), because they contain special technologies for protection against exploitation.
- Update your OS regularly (enabled by default) and software. Microsoft regularly updates the system libraries of its programs, including support for ASLR for them. Some drive-by download exploits take advantage of unmovable ASLR modules (for example, some versions of the .NET Framework, Office) to create stable chains of ROPs that can be used to bypass DEP within one or more versions of Windows / Office. Regular updates will protect against many exploits, including such ones.
- Use the advantages of Admin Approval Mode and 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 the user account that belongs to the Administrators group. This additional token is used to represent the user in the system and contains the disabled Administrator group (Deny SID), which allows you to approve or prohibit actions contributed by programs that require administrator rights. Malicious programs contain LPE exploits to bypass UAC or install kernel-mode code bypassing the operating system (user-mode restrictions), but such methods work only on out-of-date (obsolete) operating systems, which are not updated in a timely manner. The practice of using 0day LPE / RCE exploits for malicious code that is intended for ordinary users is not so high, so timely updating of the OS and using UAC will significantly reduce the risk of infection.
- Use security / AV product to protect your OS. This will allow you to control file-level operations, data transferred from the Internet, as well as other transactions conducted in the OS. Today, many of these products contain built-in exploit protection. For example, the latest version of ESET Smart Security 7 contains a special HIPS setting, which is called “Exploit Blocker” and allows you to timely detect exploit activities in applications.
- Use browsers with support for sandbox and other technologies that limit tab processes in the actions they perform. Even if the exploit contains code for the browser using the RCE vulnerability, being in an isolated process, it will not be able to perform basic functions, for example, download the payload from a remote server or reset its file to the file system.
- To date, the most secure solution is to use Windows 8+ x64 with an integrated SmartScreen at the OS level and active EMET in a system that is configured to protect the browser, especially the 32-bit one. Note that by default most browsers work in compatible 32-bit mode (Google Chrome & Mozilla Firefox does not have 64-bit options, the newest Internet Explorer 11 runs its processes by default as 32-bit). The practice of using an AV product in such a configuration is also necessary, since it will allow tracking down attempts to “land” malicious code in the OS based on antivirus signatures and heuristics. SmartScreen allows you to perform similar actions due to the updated blacklist-base Microsoft.
- Note that no standalone-app or in-browser DBO system will not be able to withstand a malicious code attack or ensure the integrity of its code in memory in the event that the OS itself is compromised. When OS is compromised, you automatically compromise all applications running on your system, including online banking applications or the browser used. Virtually any malicious code contains on-the-fly mechanisms for modifying process code (runtime-patching / injection) that an application cannot cope with to ensure its integrity. Systems such as HIPS can help track this behavior of malicious code.
Source: https://habr.com/ru/post/214197/
All Articles