TorrentLocker: Crypto‑ransomware still active, using same tactics

ESET has carried out analysis of new samples of the crypto-ransomware family TorrentLocker, to compare the 2016 campaigns against its research in late 2014.

ESET has carried out analysis of new samples of the crypto-ransomware family TorrentLocker, to compare the 2016 campaigns against its research in late 2014.

In December 2014, ESET released a white paper about TorrentLocker, a crypto-ransomware family spreading, via spam, email messages that impersonated local postal service, energy or telecom companies. The paper described its distribution scheme, its core functionalities, its network protocol and exposed some similarities with the Hesperbot banking trojan.

During the last few months, we decided to take a look at new samples to check the current state of this malware family. This article summarizes the results of our analysis and compares the 2016 campaigns against our research from late 2014.

In 2014, the name used in TorrentLocker’s ransom note alert was the well-known “CryptoLocker”. For unknown reasons, a year later the “o”s were changed to zeros, resulting in “Crypt0l0cker”. There are no significant changes in the distribution, C&C infrastructure or malware samples that would indicate it is a different ransomware. We believe the same gang operates it. To avoid confusion, we decided to keep the name TorrentLocker instead of Crypt0l0cker when referring to this malware family.

Distribution scheme

Current distribution is very similar to the techniques used in 2014. Email messages include a link to a page claiming a “document” (supposedly a bill or a tracking code) should be downloaded. If the malicious document is downloaded and opened by the user, TorrentLocker is executed. It then starts communicating with its C&C server and begins encrypting the victim’s files. Some examples of TorrentLocker impersonations between April and August 2016 are:

As we documented in 2014, the distributed URLs are still accessible only from IP addresses apparently in the country targeted by the campaign, making the pages difficult to track for researchers or crawlers outside that country.

Figure 1: Spam for Austria looks like it comes from Österreichische Post

Figure 1: Spam for Austria looks like it comes from Österreichische Post

Figure 2: Download page for Austria campaign mimics A1 Telekom

Figure 2: Download page for Austria campaign mimics A1 Telekom

Figure 3: Download page for Australia campaign mimics AFP

Figure 3: Download page for Australia campaign mimics AFP

Figure 4: Download page for Austria campaign mimics Verbund

Figure 4: Download page for Austria campaign mimics Verbund

Although the scheme looks the same, there are a few changes under the hood. There are added layers of redirections in the chain to the final malicious executable file. The link in the spam email message now leads to a PHP script hosted on a compromised server. This script checks if the visitor is browsing from the targeted country and, if so, redirects to the page where the next stage of this malware is downloaded. Otherwise, the visitor is redirected to Google. Also, the downloaded ZIP file now contains an obfuscated JScript file, which will download and execute the TorrentLocker PE file.

ReaQta published a two part blog post describing the scheme in more detail. To summarize, here is an example chain of events leading to a victim having their files encrypted:

  1. Spam message contains a link to print tracking code: hxxp://
  2. User is redirected to hxxp://
  3. User clicks to download hxxp://
  4. User opens the file and double-clicks the PostNL-pakket.js file
  5. This JScript downloads and executes TorrentLocker from hxxp://

TorrentLocker still has the ability to exfiltrate address books and SMTP settings to aid its spreading.

Additional four digit password added to prevent payment page enumeration

During the late 2014 analysis, ESET researchers discovered that “user codes” generated by the C&C server to identify the victims are sequential and predictable. This allowed us to access every payment page and to gather statistics on how many victims paid the ransom, the number of cases by country, etc. By the time that our white paper was released, TorrentLocker’s operators had added a four digit password field called “user pass” to access the payment pages.

According to a blog post by TrendMicro, the user_pass parameter was first seen on December 9th, 2014, one week before the release of the ESET white paper. Thus, the operators probably did not find out about the flaw by reading the paper but by inspecting their logs. After the operators noticed that researchers were able to access all the payment pages, they added the password field to prevent future enumeration.

The “user code” generation still uses the same predictable algorithm in the current campaigns. We did not find anything that could help predict the “user pass” value. It looks like a random integer that is added in the database of the C&C server.

Figure 5: URL in 2014

Figure 5: URL in 2014


Figure 6: URL with password

Figure 6: URL with password


For this analysis, we have chosen three samples of TorrentLocker that were packed using various crypters. We didn’t spend too much time reverse engineering them. As we saw in 2014, there are multiple levels of code decryption and the final payload is injected into the explorer.exe process. TorrentLocker’s core exports the same functions as in 2014, namely “_local_entry” and “_remote_entry“. However, this scheme changed in the “main-13” campaign sample where TorrentLocker doesn’t inject into explorer.exe anymore.

Once unpacked, the TorrentLocker core uses additional obfuscation techniques to make the analysis harder. We’ll describe two techniques that weren’t present in the 2014 samples. First, the strings are encoded using a hardcoded key. The key is the same from one campaign to another, but it is truncated and the size changes. Encoded strings are decoded on demand by simply XORing them with the truncated key. We provide an IDA script on ESET’s Github to help decode the strings from an unpacked sample.

Important Windows API functions are resolved dynamically from a 32-bit hash. The resolving function iterates over the exports of the requested library and computes the hashes of the exported names until it finds a match. This function takes a variable number of parameters: the first parameter is an index into an array of library filenames, the second is the function name hash, the third is the number of parameters passed to the API function and the rest are the values of those parameters. For instance, here’s what a call to InternetOpenW looks like:

23,       // wininet.dll
0xF190D96, // hash(“InternetOpenW”)
5,         // nargs
0, 0, 0, 0, 0x8404C700 // args

C&C Communications

One of the most interesting changes in TorrentLocker is the ways it can contact its C&C. As it used to do back in 2014, TorrentLocker tries to reach a hardcoded domain over HTTPS. However, it now prepends a random subdomain. The hardcoded domains are usually short-lived and taken down quickly.

What’s interesting is that in case of failure, it now falls back on Tor hidden services. A small Tor implementation is statically linked into the binary ensuring it doesn’t rely on external dependencies to connect to the Tor network successfully. Contacting C&C via Tor hidden services is a technique that is becoming increasingly popular among attackers who create ransomware. This makes it significantly harder for malware researchers to find where the C&Cs are located physically.

Figure 7: Paths showing the included Tor library is using LibreSSL

Figure 7: Paths showing the included Tor library is using LibreSSL

Here’s a list of the domains used in the three different samples we analyzed:

Domain IP Campaign main-9 main-12 main-13

The following three onion-routed domains are found in that order in all the samples we analyzed:

Hidden services

We haven’t noticed any significant changes in the communication protocol except that when Tor is used, there’s a new field for the victim’s public IP address. Because of how Tor works, the C&C server doesn’t know the source IP address of the request it receives; embedding the victims’ public IP addresses in the report is important as it allows the C&C to geolocate them. TorrentLocker uses the IP address to generate ransom pages in the victim’s most likely language and uses the local currency when displaying the price, as we’ll see later in this post.

While TorrentLocker used to rely only on HTTPS to encrypt communications with the C&C server, the current variants add a layer of encryption. AES-256-CBC is used to encrypt the report before wrapping it in an HTTP POST request, which is then encrypted, either with SSL in the case of HTTPS, or by Tor. The key is hardcoded in the binary and must not change very often because if the key is changed in TorrentLocker’s C&C server, the previous samples won’t be able to talk to it anymore. The AES keys are listed in the appendixes.

Geolocalized behavior

A well-known feature of TorrentLocker is how localized the download, ransom and payment pages are. Victims are provided with information in their own languages and in their local currency. For this analysis, we tried to gather information about which countries are receiving these localized details about the ransom and payment.

To achieve that, we used the fact that successful victim file encryption can be reported over the Tor network. In this scenario, the external IP address (used to locate the victim) is provided as a (user-controlled) parameter to the C&C server. We took one IP address in each country, reported a successful file encryption event to the C&C server claiming to be from that IP address and requested the ransom and payment page.

The default page is in English and the currency is USD. We found that 22 countries received a localized version of the ransom or payment page. Here’s the list of countries:

  • Australia
  • Austria
  • Belgium
  • Czech Republic
  • Denmark
  • France
  • Germany
  • Italy
  • Japan
  • Martinique
  • Netherlands
  • Norway
  • Poland
  • Portugal
  • Republic of Korea
  • Spain
  • Sweden
  • Switzerland
  • Taiwan
  • Thailand
  • Turkey
  • United Kingdom

We have seen TorrentLocker spam campaigns for all the countries in bold. It’s unclear if the others are past or future targets or have a different spreading mechanism.

We also noticed that TorrentLocker refuses to encrypt victims from a few specific countries. This behavior was already documented, but we haven’t come by a list of these countries. At the time of our experiment, TorrentLocker refused to encrypt victims coming from these four countries:

  • China
  • Russia
  • Ukraine
  • US


While the global cryptographic scheme of TorrentLocker didn’t change, some aspects of its implementation did. In 2014, TorrentLocker used a cryptographic library called LibTomCrypt. However, we’ve seen recent variants using the Microsoft CryptoAPI instead (from campaigns called “main-9” to “main-12“). What’s puzzling is that TorrentLocker’s authors decided to use LibTomCrypt again in a sample from August 10, 2016 (in campaign “main-13“). It’s unclear to us why they change from one library to another. Whether it’s LibTomCrypt or the CryptoAPI, the initialization vector (IV) is always 32 null bytes.

As mentioned earlier, the communication with the C&C is encrypted. This is also the case for the configuration and state files left on the disk. They are AES-256 encrypted with a hardcoded key that changes from one campaign to another. The filenames are also random strings now instead of sequential numbers.

Figure 8: TorrentLocker configuration directory

Figure 8: TorrentLocker configuration directory

TorrentLocker encrypts victim’s files with AES-256-CBC, as it does with the configuration files and reports to the C&C server. The key is generated with a call to CryptGenRandom asking it for 32 bytes. Each of these bytes are then added to the least significant byte of the return value of a call to GetTickCount.

Figure 9: CFG of the AES Key generation

Figure 9: CFG of the AES Key generation

The key is the same for all the encrypted files. It is later encrypted with an embedded RSA public key and sent to the C&C server. The same public key was found in all samples. It is provided in the appendixes.

TorrentLocker ensures the system remains usable by not encrypting system files. Previously, it contained a list of filename extensions to encrypt, such as “.doc“, “.docx“, “.xls“, etc. Now it’s the opposite: it has a list of extensions never to encrypt, such as “.exe“, “.dll“, “.sys” and so on. The full list is provided as an appendix.

Another small change – in 2014, TorrentLocker encrypted the first 2 MB of the files. As reported by Sophos, it was reduced to the first 1 MB.


TorrentLocker is still pretty active and keeps under the radar of many because of how it chooses its potential victims with targeted spam. Look at Lysa Myer’s 11 things you can do to protect against ransomware on WeLiveSecurity for information on prevention.

Thanks to Frédéric Vachon for his help on the analysis and redaction of this article.


Lawrence Abrams, TorrentLocker changes its name to Crypt0L0cker and bypasses U.S. computers, 2015‑04‑28,

Lilia Elena Gonzalez Medina, Insights on TorrentLocker, 2016‑07‑25,

Marc Rivero López, TorrentLocker Campaign Exploits Spanish Utility Brand, 2016‑06‑01,

Nicholas Griffin, TorrentLocker is Back and Targets Sweden & Italy, 2016‑03‑15,

Paul Pajares and Christopher Ke, TorrentLocker Ransomware Hits ANZ Region, 2015‑01‑11,

The current state of ransomware: TorrentLocker, 2015‑12‑23,

Thomas White, Crypt0L0cker – TorrentLocker Rebranded, 2015‑05‑13,

TorrentLocker Campaign affecting Spain and Italy, 2014‑12‑26,

TorrentLocker Ransomware targeting Swiss Internet Users, 2016‑01‑21,

Trojaner-Warnung: Gefälschte “A1” Online-Rechnung, 2016‑08‑16,

Uncovering a ransomware distribution operation – Part 1, 2016‑04‑11,

Uncovering a ransomware distribution operation – Part 2, 2016‑04‑26,

Kelvin Heath, TorrentLocker Ransomware Outbreak, 2016‑05‑19,


Analyzed files

SHA-1PE Compile timeCampaignESET Detection name
2BF11BD7C946F36A690BD2DDB6623BF478E8F37BTue May 17 07:13:48 2016main-9Win32/Filecoder.TorrentLocker.C trojan
BFF8090E21C020E989E4C36EBFE50B6C33DDC733Tue Oct 07 00:40:23 2014main-12Win32/Injector.DCIZ trojan
EB7BF6B79CCA5FD6B73F32049560AE57C9988A70Wed Aug 10 08:55:29 2016main-13Win32/Filecoder.TorrentLocker.A trojan

AES-256 Static keys

IV is always null bytes.

Sample SHA-1Communication KeyConfiguration file key

Files with these extensions are not encrypted

  • exe
  • dll
  • sys
  • vdx
  • vxd
  • com
  • msi
  • scr
  • cpl
  • bat
  • cmd
  • lnk
  • url
  • log
  • log2
  • tmp
  • ###
  • ini
  • chm
  • manifest
  • inf
  • html
  • txt
  • bmp
  • ttf
  • png
  • ico
  • gif
  • mp3
  • wav
  • avi
  • theme
  • evtx
  • folder
  • kdmp

TorrentLocker RSA-4096 public key used in campains main-9 to main-13

Sign up to receive an email update whenever a new article is published in our Ukraine Crisis – Digital Security Resource Center