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.
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:
- A1 Telekom (Austria)
- AGL (Australia)
- Australia Post (Australia)
- Australian Federal Police (Australia)
- British Gas (United Kingdom)
- Correos (Spain)
- Endesa (Spain)
- Enel (Italy)
- Österreichische Post (Austria)
- New Zealand Post (New Zealand)
- PGE Polska (Poland)
- PostNord (Sweden)
- PostNL (Netherlands)
- Telia (Sweden)
- Turkcell (Turkey)
- Verbund (Austria)
- Vodafone Italia (Italy)
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.
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.
- Spam message contains a link to print tracking code: hxxp://diniyat.com/jKu8xT.email@example.com
- User is redirected to hxxp://azrs.postnl-tracking24.org/yr7mb.php?id=dmljdGltQGRvbWFpbi5ubA==
- User clicks to download hxxp://azrs.postnl-tracking24.org/file/PostNL-pakket.zip
- User opens the file and double-clicks the PostNL-pakket.js file
- This JScript downloads and executes TorrentLocker fromhxxp://sudoimpex.ru/administrator/file.exe
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.
For this analysis, we have chosen three samples of TorrentLocker that were packed using variouscrypters. 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
// calls InternetOpenW(NULL, INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL,
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.
Here’s a list of the domains used in the three different samples we analyzed:
The following three onion-routed domains are found in that order in all the samples we analyzed:
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.
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:
- Czech Republic
- Republic of Korea
- 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:
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.
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 toGetTickCount.
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, http://www.bleepingcomputer.com/forums/t/574686/torrentlocker-changes-its-name-to-crypt0l0cker-and-bypasses-us-computers/
Lilia Elena Gonzalez Medina, Insights on TorrentLocker, 2016‑07‑25, https://blog.fortinet.com/2016/07/25/insights-on-torrentlocker
Marc Rivero López, TorrentLocker Campaign Exploits Spanish Utility Brand, 2016‑06‑01, https://blogs.mcafee.com/mcafee-labs/torrentlocker-campaign-exploits-spanish-utility-brand/
Nicholas Griffin, TorrentLocker is Back and Targets Sweden & Italy, 2016‑03‑15, https://blogs.forcepoint.com/security-labs/torrentlocker-back-and-targets-sweden-italy
Paul Pajares and Christopher Ke, TorrentLocker Ransomware Hits ANZ Region, 2015‑01‑11,https://blog.trendmicro.com/trendlabs-security-intelligence/torrentlocker-ransomware-hits-anz-region/
The current state of ransomware: TorrentLocker, 2015‑12‑23,https://blogs.sophos.com/2015/12/23/the-current-state-of-ransomware-torrentlocker/
Thomas White, Crypt0L0cker – TorrentLocker Rebranded, 2015‑05‑13,https://tribalchicken.com.au/security/crypt0l0cker-torrentlocker-rebranded/
TorrentLocker Campaign affecting Spain and Italy, 2014‑12‑26, http://securityblog.s21sec.com/2014/12/torrentlocker-campaign-affecting-spain.html
TorrentLocker Ransomware targeting Swiss Internet Users, 2016‑01‑21, https://www.govcert.admin.ch/blog/17/torrentlocker-ransomware-targeting-swiss-internet-users
Trojaner-Warnung: Gefälschte “A1” Online-Rechnung, 2016‑08‑16, https://www.mimikama.at/allgemein/trojaner-warnung-gefaelschte-a1-online-rechnung/
Uncovering a ransomware distribution operation – Part 1, 2016‑04‑11, https://reaqta.com/2016/04/uncovering-a-ransomware-distribution-operation/
Uncovering a ransomware distribution operation – Part 2, 2016‑04‑26,https://reaqta.com/2016/04/uncovering-ransomware-distribution-operation-part-2/
Kelvin Heath, TorrentLocker Ransomware Outbreak, 2016‑05‑19, https://www.vectra-corp.com/torrentlocker-ransomware-outbreak/
|SHA-1||PE Compile time||Campaign||ESET Detection name|
|2BF11BD7C946F36A690BD2DDB6623BF478E8F37B||Tue May 17 07:13:48 2016||main-9||Win32/Filecoder.TorrentLocker.C trojan|
|BFF8090E21C020E989E4C36EBFE50B6C33DDC733||Tue Oct 07 00:40:23 2014||main-12||Win32/Injector.DCIZ trojan|
|EB7BF6B79CCA5FD6B73F32049560AE57C9988A70||Wed Aug 10 08:55:29 2016||main-13||Win32/Filecoder.TorrentLocker.A trojan|
AES-256 Static keys
IV is always null bytes.
|Sample SHA-1||Communication Key||Configuration file key|
Files with these extensions are not encrypted
TorrentLocker RSA-4096 public key used in campains main-9 to main-13
-----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0LrTxrnan3wlqkeCrO8j L/BlcjS3yOh/YZ9vH5uRw4RvHY86JpsKaJLQ1WajkY9bgO6w9an9l9dtJch70joD o+aQfzpQIb1HUwrOmrxICO18zyhvkH+vXBSuDmQBFvuPMu8g1R4cpo9TzR0XCSEn BjDBhNirSBRmfSjhWMhLMcrrAUJ986+ucLdjQtBrDyTIlYZ8/H83T+rbkBE2sLbY D7HSBtosPArg18hC6fgDJ2V4tADmLx/wk3k8JKeQ0OXbBqVbzWbYzODIJ/VibKNg mE278RS9KR3f+0P38/ztf81SH4ZK5kjqN6qLL0AyUfQpm7bOpQHSpwOdhA0i/8M5 lMzZj1wdfp3UDoPpAyH4fc6mpgt1OjN5Rj5PjQj/bEPM/Rz67LCdFY3LbI5rCyxm 9V4UVTOJdAavByDUa8PKEY++XMKjEjTskDD4Io3tD+54rmr4/WPoRPlrQ+Bj4o7I DSvrMGsnEudhcO7qMlQ5JszHDejk5QF8glsiWsCHVxmZqsHFNYxBKGgtvUxvokgv +yxo6twfC/hC1wJHhWofINDABxIYqgVOg4GJEs0gA1v8FByNg6pss2W/oNcYDuiZ 7R/9vHAUHzMBVNaXq9Rz5h61pLFjEpIrfzO8ctAq3+wDdltyTbz40D7G4+zPHV2t PW9R7I4fmgDQMM4SimN8NcUCAwEAAQ== -----END PUBLIC KEY-----
by Marc-Etienne M.Léveillé, ESET We Live Security