TorrentLocker - a new modification of the FileCoder ransomware trojan, part 2

    In the last part of our study on the TorrentLocker ransomware, we described the general mechanisms of its operation, and also examined possible scenarios of its distribution. The second part is devoted to the analysis of this malicious program, its operation with a remote C & C server, as well as the statistics of infections in various countries.

    Before executing the payload directly, TorrentLocker injects its code into other processes. This process is carried out in two stages. At the first stage, the dropper starts a special process - the bootloader. The bootloader decrypts the helper code, which is then injected into the explorer.exe process. TorrentLocker remotely creates a stream in explorer.exe, and the export function acts as a start function__remote_entry .

    We observed several different versions of the dropper, but this analysis focuses on one of these versions, which has a compilation date of October 15, 2014 (the SHA-1 hash of this sample begins with 40B1D84B).

    The 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 consists in reusing the OutputDebugString API function . When calling OutputDebugStringfrom the context of the 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 the malware to bypass the sandbox mechanism, which runs the program in debug mode.

    Fig. The dropper code calls the OutputDebugString function 320,500 times.

    The dropper packer uses two resources of the executable PE file 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 of this resource. This part contains the key that will be used to decrypt the second resource. The second resource is the configuration of the packer. The configuration can specify the behavior of the packer itself, for example, specify for it the use of discovery methods of virtual machines through the use of instructions in and vpcext . Both instructions are used to discover 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 untouched. A similar error in the decryptor code is contained in one of the versions of the MiniDuke malware, which was described by F-Secure specialists.

    The data of the second section after the correct decryption is a PE-file. At the same time, the dropper creates a new process in a suspended state, allocates a memory region in this new process and writes the contents of this PE file to this region. The process then resumes its work from the entry point in the copied PE file. This process we call the launcher.

    The TorrentLocker component, called the bootloader, is pretty simple. It performs two functions: it copies the dropper file to another directory and launches another component of the malicious program called “core” for execution. The core component is located in the body of the malware in a compressed and encrypted form. The bootloader 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), it will request these privileges and restart its executable file.

    TorrentLocker stores some configuration information on the system. To do this, use the registry key. Newer variants of the malicious program can also store configuration data inside a directory with an arbitrary name inside the Application Data system directories or the Programs directory in All Users. Files located there are encrypted using the AES-256-CBC algorithm. The decryption key is hardwired in the body of the executable file of the malicious program and differs depending on the campaign used by the attackers. The dropper also contains the code for generating the AES key. It is formed based on the date the OS was installed on the computer. However, this code is not used by the most malicious program; it may be reserved for future use.

    TorrentLocker specializes in collecting information used by the email client. It can steal authentication data for the victim's SMTP server and address book. Various mail clients are supported, including Thunderbird, Outlook, Outlook Express, Windows Mail.

    Fig. TorrentLocker uses the Protected Storage API to retrieve the email 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 cybercriminals use e-mail messages as the main vector for delivering malware, stealing information such as a contact list can greatly facilitate the subsequent distribution of TorrentLocker. They can also use stolen SMTP information to use a legitimate server to send phishing messages.

    The malware TorrentLocker interacts with the C&C server manager using a URL that is hard-wired 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 cybercriminals from October to December 2014. If the C & C server is not available at the URL specified in the body of the malicious program, it uses a special Domain Generation Algorithm (DGA) to get an auxiliary list of 30 new domains. A DGA mechanism for obtaining new C&C addresses was added in the TorrentLocker samples that were discovered in October 2014.

    In fact, TorrentLocker uses a fairly simple protocol to interact with a C&C server. However, as mentioned in the previous paragraph, it may vary depending on the version of the malware. To work with C&C, an SSL protocol is used, which uses encryption for transmitted traffic. Instead of SSL, some modifications are used for encryption. chain XOR algorithm. Each HTTPS POST request to the C&C server from the malicious program has the following format.

    Fig. An example of a message that a malicious program sends to a C&C server.

    Fig. Correspondence of the request fields with the data from the message above.

    When TorrentLocker contacts its C&C server on an infected computer, a special “user ID” or “user code” is generated. This ID is used later to identify the victim and, based on it, the C&C server transmits a TorrentLocker URL link to the ransom payment page and obtains a file decryption tool. This URL has the following form.

    For easier access to the .onion domain, the ransom page contains links to websites accessed via 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 matched 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 a C&C server.

    The identifier uses a thirty-hex base (base 36). After converting to a decimal system (base 10), the identifier appears as a normal combination of numbers from zero to ten. If you separate the last five digits, you get two series. It can be seen that incrementation operations are applied to the older series, while decrementation is applied to the younger series. It can be seen that if you add two numbers according to this scheme, then the total number will always be 99999. This allows you to verify the correctness of the identifier by the malware operator. Knowing the algorithm for generating the identifier, we were able to get all possible web pages with a ransom demand from a remote server. What has this been done for various C & C-servers.

    September 2014 Nixu Security Resourceposted a post describing various tricks that allowed decrypting files encrypted by TorrentLocker. A special tool with a graphical interface was also released , which allowed to perform the decryption operation automatically. This situation with “unauthorized” decryption became possible due to the AES-256 algorithm used by the malware in Counter Mode (CTR) encryption mode. At the same time, 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 (Cipher Block Chaining) encryption mode, which excludes possible file decryption. To work with this cryptographic algorithm, the malicious 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. At the same time, the Yarrow pseudo-random number generator and the following Windows API functions (the values ​​returned by them) are used for the key generation procedure itself.

    1. Gettickcount
    2. GetCurrentProcessId
    3. GetCurrentThreadId
    4. GetDesktopWindow
    5. GetForegroundWindow
    6. GetShellWindow
    7. Getcapture
    8. GetClipboardOwner
    9. GetOpenClipboardOwner
    10. Getfocus
    11. GetActiveWindow
    12. GetKBCodePage
    13. Getprocessheap
    14. GetThreadTimes (GetCurrentThread ())
    15. GetProcessTimes (GetCurrentProcess ())

    Before encrypting files directly, the AES key is encrypted with the RSA public key, which is located in the malware file. Then it is sent to the remote C&C server with the set request type value to one.

    To avoid performance overhead, TorrentLocker only encrypts the first 2MB files. Obviously, even in the case of large files, this length is enough to make the file completely unusable or unusable. At the end of each encrypted file, the malware adds three special fields, the format of which is indicated below.

    The Adler-32 checksum, which is indicated in the table, is probably used to check the AES key and the fact that the file itself is encrypted with TorrentLocker. This method of storing the AES key in an encrypted file allows TorrentLocker operators or another RSA private key holder to easily decrypt the contents of the file without resorting to other sources. It can also be used to restore the AES key in case the C&C server is unavailable.

    Similarities between TorrentLocker and Hesperbot Hesperbot

    banking trojan was discoveredESET analysts in 2013 and it is a complex malicious tool that was used by cybercriminals to steal money from online banking accounts of users in different countries around the world. He used the injection of his malicious HTML and JavaScript code into the web pages of a running browser. We found similarities between TorrentLocker and Hesperbot. It seems that the authorship of the code for both malicious programs belongs to one criminal group, which also runs campaigns to distribute them. Spam campaigns to distribute both Trojans are aimed at the same countries, for example, Turkey, the Czech Republic, and Australia.

    The web pages used to distribute Hesperbot in early 2014 were very similar to those used for distribution in the case of TorrentLocker. In March this year, one of Zoltan Balazs security resellers published information on the Hesperbot distribution web pages that contained the CAPTCHA mechanism. This is very similar to the TorrentLocker distribution method. The URL pattern, in some cases, ends with .php? Id = [digits] .

    Fig. Comparison of URLs used to distribute malware.

    It is worth noting that the IP addresses of the C & C servers of both malicious programs also match. Hesperbot used the remote updates domain with the IP address as a remote C&C server. The same IP address was used by the TorrentLocker sample in September 2014. The domain was

    In both malware families, their earlier versions contained a path string 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 this.

    In August 2014, a TorrentLocker sample fell into our hands, which contained a very similar path (rack-core module).

    The other 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 people or on one computer.


    Above, we described the mechanism for generating user IDs that the malware authors used to identify TorrentLocker infected computers. Using these identifiers, we were able to extract information about victims from a remote C & C server. This experiment was conducted on November 24, 2014. The following is a list of remote C & C servers that were used to retrieve the referenced information.

    We received 47.365 web pages with ransom from five different C&C servers. Of this number, 39,670 web pages represented real users whose identifiers were generated by an infected system. Other identifiers were deleted from the database by operators because they were already outdated or did not result from successful malware infection of the user (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 software for decrypting files. Also, 20 web pages indicate that the amount of the ransom was not received in full.

    Fig. TorrentLocker foreclosure payment statistics.

    The ransom payment web pages are translated into the appropriate language for the region. A total of 13 different countries are supported. Below are statistics that clearly illustrate the number of TorrentLocker infections in different countries.

    Fig. Country infection statistics.


    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 of bitcoins makes attackers practically invulnerable to law enforcement agencies, which will not be able to establish the destination address when making the payment.

    TorrentLocker authors have switched to using the CBC mode of the symmetric AES encryption algorithm, instead of the previously used CTR. Thus, they reduced to zero the possibility of "unauthorized" decryption of files. Decryption is possible only if an RSA private key is obtained from cybercriminals with the help of which it is possible to decrypt the AES key. This AES key encrypted with the public RSA 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 malicious program.

    As the main protective measure against the consequences of TorrentLocker infection and file encryption, back up files on your hard drive. Remember that TorrentLocker specializes in encrypting files located on network drives that are connected to an infected computer. In this case, files with a backup copy of the data should be stored on a remote device that is not connected to the computer, otherwise they can also be compromised by TorrentLocker.

    Fig. Types of files TorrentLocker encrypts.

    Also popular now: