TorrentLocker - a new modification of the FileCoder cryptographer, part 2
In the last part of our study on the TorrentLocker cipher, we described the general mechanisms of its operation, and also considered possible scenarios for its distribution. The second part is devoted to the analysis of this malware, its work with a remote C & C server, as well as statistics on infections in various countries.
Before the payload is executed directly, TorrentLocker injects its code (injection) into other processes. This process is carried out in two stages. At the first stage, the dropper starts a special process - the loader. The loader decrypts the auxiliary code, which is then embedded in the explorer.exe process. TorrentLocker remotely creates a stream in explorer.exe, with the exported __remote_entry function being the starting function.
')
We observed several different versions of the dropper, but this analysis is devoted to one of these versions, which has a compilation date of October 15, 2014 (SHA-1 hash of this sample begins with 40B1D84B).
Dropper contains several well-known tricks to complicate the analysis of the executable file. One such trick is to use dynamic exports. It also uses an anti-debugging technique, which is to reuse the OutputDebugString API function. When calling OutputDebugString from the context of a process to which the debugger is not connected, it does not perform any useful functions. However, if a debugger is connected to the process, it sends it a string for output. The dropper code calls this function 320,500 times, which causes the debugger to hang. This method also allows a malicious program to bypass the sandbox mechanism (sandbox), which runs the program in debug mode.
Fig. The dropper code calls the OutputDebugString function 320,500 times.
The dropper packer uses two executable PE file resources to extract the payload. The first resource contains a 16-bit key at the beginning of its data. This key is used to decrypt the rest of the data for this resource. This part contains the key that will be used to decrypt the second resource. The second resource is the packer configuration. The configuration can set the behavior of the packer itself, for example, set for it the use of detection techniques of virtual machines through the use of in and vpcext instructions . Both instructions are used to detect VMWare and VirtualPC.
The above resources are encrypted using a modified version of the RC4 algorithm. The decryption process contains an error, since one of the variables, which must be initialized to zero, remains intact. A similar error in the code of the decryptor is contained in one of the versions of the malicious software MiniDuke, which was described by F-Secure experts.
The data of the second section after proper decryption is a PE file. At the same time, the dropper creates a new process in a suspended state (suspended), allocates a region of memory in this new process, and writes the contents of this PE file to this region. Then the process resumes its work from the entry point in the copied PE file. We call this process the launcher.
The TorrentLocker component, called the bootloader, is quite simple. It performs two functions: it copies the dropper file to another directory and launches another component of the malicious program called “core”. The core component is located in the body of the malware in compressed and encrypted form. The loader unpacks it using the aPlib library and injects its code into the system processes explorer.exe and svchost.exe. If the loader does not have enough privileges to perform this operation (administrator), he will request these privileges and restart his executable file.
TorrentLocker stores some configuration information in the system. To do this, use the registry key. Newer versions of the malware can also store configuration data within a directory with an arbitrary name within the System Data Application system directories or the Programs directory in All Users . Files located there are encrypted using the AES-256-CBC algorithm. The decryption key is hard-wired in the body of the executable file of the malicious program and differs depending on the campaign used by attackers. Dropper also contains a code to generate an AES key. It is formed based on the date of the OS installation on the computer. However, this code is not used by the malware itself, it may be reserved for future use.
TorrentLocker specializes in collecting information used by the user mail client. It can steal authentication data for the victim's SMTP server and address book. Various email clients are supported, including Thunderbird, Outlook, Outlook Express, Windows Mail.
Fig. TorrentLocker uses the Protected Storage API to get mail client configuration.
Fig. The part of the TorrentLocker code that is responsible for parsing the address book of the Thunderbird email client.
Given the fact that attackers use e-mail as the main vector for delivering malware, stealing information such as a list of contacts can make it much easier to distribute TorrentLocker. They can also use stolen SMTP information to use a legitimate server to send phishing messages.
The TorrentLocker malware interacts with the C & C server manager using a URL that is hard-coded into the dropper body. It can use various modifications of its network protocol to work with C & C and the modification described below was used in samples that were distributed by attackers from October to December 2014. If the C & C server is unavailable at the URL specified in the body of the malicious program Generation Algorithm (DGA) for obtaining an auxiliary list of 30 new domains. The DGA engine for getting new C & C addresses was added to the TorrentLocker samples that were discovered in October 2014.
In fact, TorrentLocker uses a fairly simple protocol to interact with the C & C server. However, as mentioned in the previous paragraph, it can vary depending on the version of the malware. To work with C & C, the SSL protocol is used, which uses encryption for the transmitted traffic. Some modifications instead of using SSL to encrypt so-called. chain XOR algorithm. Each HTTPS POST request to a C & C server by a malicious program has the following format.
Fig. An example of a message that a malicious program sends to a C & C server.
Fig. Correspondence to the fields of the request with the data from the message, which is given above.
When a TorrentLocker on an infected computer contacts its C & C server, a special “user ID” or “user code” is generated. This ID is then used to identify the victim and, based on this, the C & C server sends the TorrentLocker a URL link to the ransom payment page and the file decryption tool. This URL has the following form.
For easier access to the .onion domain, the ransom request web page contains links to websites with access through Tor2Web . Using this mechanism allows the victim to access the ransom payment web page even from a browser that does not support Tor.
The user ID mentioned above is a string of six randomly selected characters. However, if two malware infections occur at the same time, the IDs of the infected systems may be similar. Further analysis of this algorithm showed that the code for generating identifiers is predictable. As an example, consider three identifiers selected by the C & C server.
For the identifier, a thirty-six-hex base is used (base 36). After converting to the decimal system (base 10), the identifier appears as a usual combination of numbers from zero to ten. If you separate the last five digits, you get two series. At the same time it is clear that increment operations are applied to the older series, when decrementing is applied to the younger series. It can be seen that if you add two numbers according to this scheme, then the total will always be 99999. This allows you to verify the correctness of the identifier by the malicious program operator. Knowing the identifier generation algorithm, we were able to get all possible web pages from the remote server with a ransom requirement. What has this been done for various C & C servers.
In September 2014, Nixu security reseller published a post describing various tricks that allowed to decrypt files encrypted by TorrentLocker. A special GUI tool was also released that allowed the decryption operation to be performed automatically. Such a situation with “unauthorized” decryption has become possible due to the AES-256 algorithm used by the malware in the Counter Mode encryption mode (CTR). In this case, the same key was used for all files, as well as the initialization vector (IV), which made the algorithm vulnerable. Newer versions of TorrentLocker use AES in CBC encryption mode (Cipher Block Chaining), which excludes the possible decryption of files. To work with this cryptographic algorithm, the malware code uses the LibTomCrypt library.
The only AES-256 key for file encryption is generated when the dropper is executed. It is used to encrypt all files in the system. In this case, the key generation procedure itself uses the pseudo-random number generator Yarrow and the following Windows API functions (the values ​​returned by them).
Before directly encrypting files, the AES key is encrypted with the RSA public key, which is located in the malware file. It is then sent to the remote C & C server with the request type set to one.
To avoid performance overhead, TorrentLocker encrypts only the first 2MB files. Obviously, even in the case of large files, such a length is enough to make the file completely inoperative or unusable. The malware adds three special fields to the end of each encrypted file, the format of which is indicated below.
The Adler-32 checksum, which is listed in the table, may be used to verify the AES key and the fact that the file itself is TorrentLocker encrypted. This way of storing an AES key in an encrypted file allows TorrentLocker operators or another RSA private key holder to easily decrypt the contents of the file without accessing other sources. It can also be used to restore the AES key in case the C & C server is unavailable.
Similarities TorrentLocker and Hesperbot
The Hesperbot banking trojan was discovered by ESET analysts in 2013 and is a sophisticated malicious tool used by cybercriminals to steal money from online banking accounts of users in different countries around the world. He used the embedding of his malicious HTML and JavaScript code in the web pages of the launched browser. We found similarities between TorrentLocker and Hesperbot. It seems that the authorship of the code of both malicious programs belongs to one criminal group, which also deals with campaigns for their distribution. Spam campaigns to spread both Trojans are aimed at the same countries, for example, Turkey, the Czech Republic, and Australia.
The web pages that were used to distribute Hesperbot in early 2014 were very similar to those that were used for distribution in the case of TorrentLocker. In March of this year, one of the security writers, Zoltan Balazs, published information on the Hesperbot distribution web pages, which contained the CAPTCHA mechanism. This is very similar to the TorrentLocker distribution method. The URL pattern, in some cases, ended in .php? Id = [digits] .
Fig. Compare URLs that were used to distribute malware.
It is worth noting that the IP addresses of the C & C servers of both malicious programs also coincide. Hesperbot used as a remote C & C server a domain updatesecurehost1.ru with IP address 46.149.111.178. The same IP address was used by the TorrentLocker sample in September 2014. The domain was nigerianpride.net.
In both families of malware, their earlier versions contained the string path to the PDB file. In order to see this path, the sample must be unpacked. For Hesperbot (procblock module), the path to pdb looked like.
In August 2014, the TorrentLocker sample, which contained a very similar path (rack-core module), came into our hands.
Another sample contained the path to the rack-dropper module.
The identity of the directory hierarchy in the paths may indicate that the executable files were compiled by one group of persons or on one computer.
Statistics
Above, we described the mechanism for generating user IDs, which was used by the authors of a malicious program to identify computers infected with TorrentLocker. Using these identifiers, we were able to extract information about the victims from a remote C & C server. This experiment was conducted on November 24, 2014. Below is a list of remote C & C servers that were used to extract the referenced information.
We received 47.365 redemption web pages from five different C & C servers. Of this number, 39,670 web pages represented the real users, whose IDs were generated by the infected system. Other identifiers were removed from the database by operators, because they were already outdated or were not at all the result of successful infection of the user with a malware (they could have been created by malware researchers). Of the mentioned number of real victims, 570 users paid the ransom to the attackers and received a link to the file decryption software. Also, 20 web pages indicate that the amount of the ransom was not fully received.
Fig. Statistics buyout payment TorrentLocker.
The ransom payment web pages are translated to the appropriate language for the region. A total of 13 different countries are supported. Below is a statistic that clearly demonstrates the number of TorrentLocker infections in different countries.
Fig. Statistics of infections by country.
Conclusion
Cybercriminals have been distributing TorrentLocker since at least February 2014. They managed to collect a large number of bitcoins from their victims. Users were ready to lay out their money to restore access to their files. The use of cryptocurrency Bitcoins makes intruders virtually invulnerable to law enforcement agencies who can not set the destination address during the payment.
The authors of TorrentLocker switched to using the CBC mode of the AES symmetric encryption algorithm, instead of the previously used CTR. Thus, they nullified the possibility of "unauthorized" decryption of files. Decryption is possible only in the case of obtaining the RSA private key from intruders, with which you can decrypt the AES key. This encrypted public RSA key AES key is stored at the end of the encrypted file and is used to directly decrypt the file (or its first 2 MB). As we described above, the public RSA key is located in the body of the malware.
As a basic protective measure against the effects of TorrentLocker infection and file encryption, you should use backup files on your hard drive. It should be remembered that TorrentLocker specializes in encrypting files located on network drives that are connected to an infected computer. In this case, files with backup data are best stored on a remote device that is not connected to the computer, otherwise, they may also be compromised by TorrentLocker.
Fig. The types of files that TorrentLocker encrypts.
Before the payload is executed directly, TorrentLocker injects its code (injection) into other processes. This process is carried out in two stages. At the first stage, the dropper starts a special process - the loader. The loader decrypts the auxiliary code, which is then embedded in the explorer.exe process. TorrentLocker remotely creates a stream in explorer.exe, with the exported __remote_entry function being the starting function.
')
We observed several different versions of the dropper, but this analysis is devoted to one of these versions, which has a compilation date of October 15, 2014 (SHA-1 hash of this sample begins with 40B1D84B).
Dropper contains several well-known tricks to complicate the analysis of the executable file. One such trick is to use dynamic exports. It also uses an anti-debugging technique, which is to reuse the OutputDebugString API function. When calling OutputDebugString from the context of a process to which the debugger is not connected, it does not perform any useful functions. However, if a debugger is connected to the process, it sends it a string for output. The dropper code calls this function 320,500 times, which causes the debugger to hang. This method also allows a malicious program to bypass the sandbox mechanism (sandbox), which runs the program in debug mode.
Fig. The dropper code calls the OutputDebugString function 320,500 times.
The dropper packer uses two executable PE file resources to extract the payload. The first resource contains a 16-bit key at the beginning of its data. This key is used to decrypt the rest of the data for this resource. This part contains the key that will be used to decrypt the second resource. The second resource is the packer configuration. The configuration can set the behavior of the packer itself, for example, set for it the use of detection techniques of virtual machines through the use of in and vpcext instructions . Both instructions are used to detect VMWare and VirtualPC.
The above resources are encrypted using a modified version of the RC4 algorithm. The decryption process contains an error, since one of the variables, which must be initialized to zero, remains intact. A similar error in the code of the decryptor is contained in one of the versions of the malicious software MiniDuke, which was described by F-Secure experts.
The data of the second section after proper decryption is a PE file. At the same time, the dropper creates a new process in a suspended state (suspended), allocates a region of memory in this new process, and writes the contents of this PE file to this region. Then the process resumes its work from the entry point in the copied PE file. We call this process the launcher.
The TorrentLocker component, called the bootloader, is quite simple. It performs two functions: it copies the dropper file to another directory and launches another component of the malicious program called “core”. The core component is located in the body of the malware in compressed and encrypted form. The loader unpacks it using the aPlib library and injects its code into the system processes explorer.exe and svchost.exe. If the loader does not have enough privileges to perform this operation (administrator), he will request these privileges and restart his executable file.
TorrentLocker stores some configuration information in the system. To do this, use the registry key. Newer versions of the malware can also store configuration data within a directory with an arbitrary name within the System Data Application system directories or the Programs directory in All Users . Files located there are encrypted using the AES-256-CBC algorithm. The decryption key is hard-wired in the body of the executable file of the malicious program and differs depending on the campaign used by attackers. Dropper also contains a code to generate an AES key. It is formed based on the date of the OS installation on the computer. However, this code is not used by the malware itself, it may be reserved for future use.
TorrentLocker specializes in collecting information used by the user mail client. It can steal authentication data for the victim's SMTP server and address book. Various email clients are supported, including Thunderbird, Outlook, Outlook Express, Windows Mail.
Fig. TorrentLocker uses the Protected Storage API to get mail client configuration.
Fig. The part of the TorrentLocker code that is responsible for parsing the address book of the Thunderbird email client.
Given the fact that attackers use e-mail as the main vector for delivering malware, stealing information such as a list of contacts can make it much easier to distribute TorrentLocker. They can also use stolen SMTP information to use a legitimate server to send phishing messages.
The TorrentLocker malware interacts with the C & C server manager using a URL that is hard-coded into the dropper body. It can use various modifications of its network protocol to work with C & C and the modification described below was used in samples that were distributed by attackers from October to December 2014. If the C & C server is unavailable at the URL specified in the body of the malicious program Generation Algorithm (DGA) for obtaining an auxiliary list of 30 new domains. The DGA engine for getting new C & C addresses was added to the TorrentLocker samples that were discovered in October 2014.
In fact, TorrentLocker uses a fairly simple protocol to interact with the C & C server. However, as mentioned in the previous paragraph, it can vary depending on the version of the malware. To work with C & C, the SSL protocol is used, which uses encryption for the transmitted traffic. Some modifications instead of using SSL to encrypt so-called. chain XOR algorithm. Each HTTPS POST request to a C & C server by a malicious program has the following format.
Fig. An example of a message that a malicious program sends to a C & C server.
Fig. Correspondence to the fields of the request with the data from the message, which is given above.
When a TorrentLocker on an infected computer contacts its C & C server, a special “user ID” or “user code” is generated. This ID is then used to identify the victim and, based on this, the C & C server sends the TorrentLocker a URL link to the ransom payment page and the file decryption tool. This URL has the following form.
For easier access to the .onion domain, the ransom request web page contains links to websites with access through Tor2Web . Using this mechanism allows the victim to access the ransom payment web page even from a browser that does not support Tor.
The user ID mentioned above is a string of six randomly selected characters. However, if two malware infections occur at the same time, the IDs of the infected systems may be similar. Further analysis of this algorithm showed that the code for generating identifiers is predictable. As an example, consider three identifiers selected by the C & C server.
For the identifier, a thirty-six-hex base is used (base 36). After converting to the decimal system (base 10), the identifier appears as a usual combination of numbers from zero to ten. If you separate the last five digits, you get two series. At the same time it is clear that increment operations are applied to the older series, when decrementing is applied to the younger series. It can be seen that if you add two numbers according to this scheme, then the total will always be 99999. This allows you to verify the correctness of the identifier by the malicious program operator. Knowing the identifier generation algorithm, we were able to get all possible web pages from the remote server with a ransom requirement. What has this been done for various C & C servers.
In September 2014, Nixu security reseller published a post describing various tricks that allowed to decrypt files encrypted by TorrentLocker. A special GUI tool was also released that allowed the decryption operation to be performed automatically. Such a situation with “unauthorized” decryption has become possible due to the AES-256 algorithm used by the malware in the Counter Mode encryption mode (CTR). In this case, the same key was used for all files, as well as the initialization vector (IV), which made the algorithm vulnerable. Newer versions of TorrentLocker use AES in CBC encryption mode (Cipher Block Chaining), which excludes the possible decryption of files. To work with this cryptographic algorithm, the malware code uses the LibTomCrypt library.
The only AES-256 key for file encryption is generated when the dropper is executed. It is used to encrypt all files in the system. In this case, the key generation procedure itself uses the pseudo-random number generator Yarrow and the following Windows API functions (the values ​​returned by them).
- Gettickcount
- GetCurrentProcessId
- GetCurrentThreadId
- GetDesktopWindow
- Get foregroundwindow
- GetShellWindow
- Getcapture
- GetClipboardOwner
- GetOpenClipboardOwner
- Getfocus
- GetActiveWindow
- GetKBCodePage
- Getprocessheap
- GetThreadTimes (GetCurrentThread ())
- GetProcessTimes (GetCurrentProcess ())
Before directly encrypting files, the AES key is encrypted with the RSA public key, which is located in the malware file. It is then sent to the remote C & C server with the request type set to one.
To avoid performance overhead, TorrentLocker encrypts only the first 2MB files. Obviously, even in the case of large files, such a length is enough to make the file completely inoperative or unusable. The malware adds three special fields to the end of each encrypted file, the format of which is indicated below.
The Adler-32 checksum, which is listed in the table, may be used to verify the AES key and the fact that the file itself is TorrentLocker encrypted. This way of storing an AES key in an encrypted file allows TorrentLocker operators or another RSA private key holder to easily decrypt the contents of the file without accessing other sources. It can also be used to restore the AES key in case the C & C server is unavailable.
Similarities TorrentLocker and Hesperbot
The Hesperbot banking trojan was discovered by ESET analysts in 2013 and is a sophisticated malicious tool used by cybercriminals to steal money from online banking accounts of users in different countries around the world. He used the embedding of his malicious HTML and JavaScript code in the web pages of the launched browser. We found similarities between TorrentLocker and Hesperbot. It seems that the authorship of the code of both malicious programs belongs to one criminal group, which also deals with campaigns for their distribution. Spam campaigns to spread both Trojans are aimed at the same countries, for example, Turkey, the Czech Republic, and Australia.
The web pages that were used to distribute Hesperbot in early 2014 were very similar to those that were used for distribution in the case of TorrentLocker. In March of this year, one of the security writers, Zoltan Balazs, published information on the Hesperbot distribution web pages, which contained the CAPTCHA mechanism. This is very similar to the TorrentLocker distribution method. The URL pattern, in some cases, ended in .php? Id = [digits] .
Fig. Compare URLs that were used to distribute malware.
It is worth noting that the IP addresses of the C & C servers of both malicious programs also coincide. Hesperbot used as a remote C & C server a domain updatesecurehost1.ru with IP address 46.149.111.178. The same IP address was used by the TorrentLocker sample in September 2014. The domain was nigerianpride.net.
In both families of malware, their earlier versions contained the string path to the PDB file. In order to see this path, the sample must be unpacked. For Hesperbot (procblock module), the path to pdb looked like.
In August 2014, the TorrentLocker sample, which contained a very similar path (rack-core module), came into our hands.
Another sample contained the path to the rack-dropper module.
The identity of the directory hierarchy in the paths may indicate that the executable files were compiled by one group of persons or on one computer.
Statistics
Above, we described the mechanism for generating user IDs, which was used by the authors of a malicious program to identify computers infected with TorrentLocker. Using these identifiers, we were able to extract information about the victims from a remote C & C server. This experiment was conducted on November 24, 2014. Below is a list of remote C & C servers that were used to extract the referenced information.
We received 47.365 redemption web pages from five different C & C servers. Of this number, 39,670 web pages represented the real users, whose IDs were generated by the infected system. Other identifiers were removed from the database by operators, because they were already outdated or were not at all the result of successful infection of the user with a malware (they could have been created by malware researchers). Of the mentioned number of real victims, 570 users paid the ransom to the attackers and received a link to the file decryption software. Also, 20 web pages indicate that the amount of the ransom was not fully received.
Fig. Statistics buyout payment TorrentLocker.
The ransom payment web pages are translated to the appropriate language for the region. A total of 13 different countries are supported. Below is a statistic that clearly demonstrates the number of TorrentLocker infections in different countries.
Fig. Statistics of infections by country.
Conclusion
Cybercriminals have been distributing TorrentLocker since at least February 2014. They managed to collect a large number of bitcoins from their victims. Users were ready to lay out their money to restore access to their files. The use of cryptocurrency Bitcoins makes intruders virtually invulnerable to law enforcement agencies who can not set the destination address during the payment.
The authors of TorrentLocker switched to using the CBC mode of the AES symmetric encryption algorithm, instead of the previously used CTR. Thus, they nullified the possibility of "unauthorized" decryption of files. Decryption is possible only in the case of obtaining the RSA private key from intruders, with which you can decrypt the AES key. This encrypted public RSA key AES key is stored at the end of the encrypted file and is used to directly decrypt the file (or its first 2 MB). As we described above, the public RSA key is located in the body of the malware.
As a basic protective measure against the effects of TorrentLocker infection and file encryption, you should use backup files on your hard drive. It should be remembered that TorrentLocker specializes in encrypting files located on network drives that are connected to an infected computer. In this case, files with backup data are best stored on a remote device that is not connected to the computer, otherwise, they may also be compromised by TorrentLocker.
Fig. The types of files that TorrentLocker encrypts.
Source: https://habr.com/ru/post/247031/
All Articles