Update on the Torrentlocker ransomware

This posting is an update to the Torrentlocker blog posting of October 15. For guidance on containment and recovery, see the previous blog post.

Financial aspects

Payments for the ransom have to be done in Bitcoins. We have identified 7 Bitcoin addresses that received ransom payments. The total income as of the 21th of October is 862,79539531 BTC which comes down to 257.393,45 EURO made in payments to the criminals. Based on the current BTC price for the ransom, currently 1.32 BTC about 400 EURO, we can say that at least 653 victims have paid the ransom. We have confirmed 4180 infected clients up until October 21st. If they would all pay the ransom that would amount to 1.6 million euros.

Harvesting new e-mail addresses

Torrentlocker is currently being spread via phishing emails luring victims to fake postal service websites. One of the ways the criminals are getting new emails to send the emails towards is by harvesting email addresses from infected machines. It is able to grab email addresses from:

  • Thunderbird
  • Outlook
  • Windows Live Mail

We’ve found that they were able to harvest 2.614.109 email addresses in total. In addition to email addresses to use as a recipient, Torrentlocker also looks for IMAP/POP3/SMTP credentials to send the emails from. Started from the 20th we have seen them harvest a total of 1746 SMTP account credentials.


Location and number of the affected clients

This Torrentlocker campaign started on the 16th of September 2014 and has been targeting various countries. The criminals have made payment templates for the following countries:

  • Australia
  • Canada
  • Spain
  • Great Britain
  • Ireland
  • Italy
  • Namibia
  • Netherlands
  • New Zealand

They have been sending the phishing mails to recipients in the following countries:

  • Albania
  • Australia
  • Austria
  • Belgium
  • Canada
  • Chile
  • Colombia
  • Egypt
  • France
  • Germany
  • Great Britain
  • Greece
  • Hongkong
  • Hungary
  • India
  • Indonesia
  • Iran
  • Ireland
  • Isle of Man
  • Italy
  • Japan
  • Korea
  • Malta
  • Namibia
  • Netherlands
  • New Caledonia
  • New Zealand
  • Norway
  • Papue new Guinea
  • Philippines
  • Poland
  • Portugal
  • Puerto Rico
  • Qatar
  • Romania
  • Russia
  • Serbia
  • Singapore
  • South Africa
  • Spain
  • Sweden
  • Switserland
  • Turkey
  • United Arab Emirates
  • United States

In total we were able to confirm 4180 infections in 44 countries. This campaign first started on the 16th of September. They have done runs sometimes a week apart and sometimes only a day apart. The last run we saw started on the 21st of October. In every country they impersonate emails from the local postal service.

New IoCs

The following new domain names were used for hosting the fake website for the Dutch phishing campaign

  • Postnl-track.org
  • Postnl-track.net
  • Postnl-tracktrace.net

The following IP-addresses were additionally used for global C&C traffic


On the infected client system, the ransomware copies itself to a location based on whether it has admin privileges:

  • With admin privileges it will copy itself to C:\WINDOWS\[a-z]{8}.exe
  • Without admin privileges it will copy itself to C:\ProgramData\[a-z]{8}.exe

Additionally a startup key is added to the registry to start the ransomware upon a reboot.

New Torrentlocker variant active in the Netherlands


The Netherlands was hit with a new spam run designed to spread a cryptolocker variant known as torrentlocker from Monday October 13th 2014 onwards. Please note that torrentlocker appears to present itself to victims as cryptolocker in all cases. Fox-IT now receives multiple reports of new victims in the Netherlands and we are currently analyzing the new spam run and malware that was subsequently used.

This blogpost is aimed at providing victims with advice on how to deal with the infections. It contains technical details that will help system administrators trace back the original infection, and contain the spread of the infection as much as possible. We will update this blog post as more information is available.

What to do if you are a victim of torrentlocker?

You have fallen victim to torrentlocker if you find that a number of your (data) files have been encrypted and are unreadable. In this instance of torrentlocker, each directory that contains encrypted files will also contain an HTML-file with instruction on how to contact and pay the criminals behind this latest wave of torrentlocker attacks.

There are a number of things that you can do yourself to find the original infection and contain the spread of torrentlocker, and possibly restore files to their original state.

  1. Block access to certain resources on the internet in order to minimize the risk of further infections. For information on which resources to block, see section “Indicators of compromise in network traffic”.
  2. Activate system policies that prevent further activity by torrentlocker:
    1. Restrict “delete” permissions. Activate a policy that prevents users from deleting files from shares. We have indications that such a policy may prevent torrentlocker from working effectively. We are currently investigating this claim.
    2. Restrict “write” permissions. To be extra careful, you may change user’s rights on all files to “read-only”. This will prevent any changes to files.
  3. Identify the systems that are infected with torrentlocker. The following steps will help with identification:
    1. Identify who received emails as part of the spam run. In your email messaging logs, search for email messages with characteristics as described in the section “Indicators of compromise in email”. Any hits should provide you with information about who within your organization received emails as part of the spam run and will allow you to remove these emails.
    2. Identify who visited suspicious torrentlocker websites. In your gateway logs (proxy logs, firewall logs, IDS logs etc), search for visits to websites known to be associated with this spam run. Any hits should provide you with evidence which systems within your infrastructure visited those websites and are potentially infected with torrentlocker. More information about what to look for can be found in section “Indicators of compromise in network traffic”.
    3. Identify which systems are infected. After the previous two steps, you may have narrowed down the number of systems that are potentially infected and have caused the files to be encrypted. On suspected systems, you may use the information in the section “Indicators of compromise on hosts”.
  4. Isolate the infected systems from your infrastructure. Once identified, these systems should be carefully isolated from the infrastructure, to prevent further encryption of additional files but at the same time preserve digital traces.
    1. Immediately cease all user activity on infected systems as they may contain important clues for decryption of the encrypted files or additional information about the infection.
    2. Physically disconnect the infected systems from the network.
    3. Do not power off, wipe or reimage infected systems.
  5. Restore backups of the infected files. In case backups are not available or only partly available, and you have preserved sufficient digital evidence, you may seek professional assistance in an effort to recover infected files.

Infection process


Indicators of compromise in email

Within your messaging logs, you may search for emails with the subject:

Heb je niet geleverde packet

Starting on Sunday emails were sent around impersonating a Dutch postal company called PostNL. The emails were styled so as to look exactly like the company’s normal email communication:

postnl phishing

The recipient of the email is enticed to click on the ‘Zie de informatie’ link. This took the recipient to a compromised wordpress website used as redirection page towards the actual malicous page.

Indicators of compromise in network traffic

Within your gateway logs (proxy, firewall and IDS logs, etc) you may search for traffic to the following site in order to identify systems within your infrastructure that visited malicious websites associated with this attack. Please note that this list contains currently known resources on the internet but is not necessarily complete.

Initial websites linked to in the email:


The above websites redirected to:


Domains for command and control traffic over SSL:


Command and control IP’s involved with this threat:

Fake PostNL IP’s involved with this threat:

The domain ‘postnl-track.com’ had its CSS and images loaded from ‘postnl-track.com’. The page was a convincing page talking about a track and trace document being available:


The user is forced to enter the captcha in order to proceed. After the captcha the user is presented with a download of their track and trace information:


The user is presented with a zip which has the payload inside. After opening their ‘document’ the malware will start connecting with its command and control server, generate encryption keys and start encrypting files. After its completed the user is presented with the following notice:


When visiting one of the links of their payment website the user is told to pay 400 EURO’s within a certain time otherwise the price will be doubled:


Indicators of compromise on hosts

On suspected systems, you may look for the following clues of infection by torrentlocker. Please note that once you determine that a system is infected, you should remove it from your infrastructure. Do not wipe or reinstall the system as it may contain additional clues about the infection.

  • The initial infection is dropped as the following file C:\WINDOWS\[a-z]{8}.exe
  • There will be a reference in the registry to the previous file, to make sure that torrentlocker starts up automatically upon boot. You may use the Windows tool msconfig to inspect startup entries.
  • A second process “explorer.exe” will be active.

Live blog on SSLv3 protocol vulnerability ‘POODLE’

Google has announced the discovery of a protocol vulnerability in SSLv3. This vulnerability allows an attacker to read contents of connections secured by SSLv3.

SSLv3 is a Secure Sockets Layer (SSL) protocol that has been ratified in 1996. SSL is used to encrypt communications between clients and servers. It is usually integrated with webservers, mailservers or other software that use secure communications.

SSLv3 has been succeeded by TLS v1.0 in 1999 and later by TLS v1.1 and v1.2 in 2006 and 2008 respectively. SSLv3 is still supported on most servers for backward compatibility with old clients that have no TLS support such as Internet Explorer 6.

What is the vulnerability?

An attacker can perform a man-in-the-middle attack on SSLv3. This attack consists of two steps

  1. Make sure the client and server agree on using SSLv3
  2. Exploit protocol vulnerabilities in SSLv3 to obtain plaintext traffic

The original paper describing the attack can be found here: https://www.openssl.org/~bodo/ssl-poodle.pdf

The vulnerability is assigned CVE reference 2014-3566

Are you affected?

All software supporting SSLv3 is affected by this vulnerability. To see if your servers support the SSLv3 protocol we recommend to following tools to scan your websites:

You can test your server by using the following OpenSSL command:

openssl s_client -ssl3 -connect [host]:[port]

For services using STARTTLS such as SMTP, POP3 and IMAP you need to add the -starttls option:

openssl s_client -starttls [smtp|pop3|imap|ftp|xmpp] -ssl3 -connect [host]:[port]

If the server does not support SSLv3 you should see a SSL alert similar to this:

SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/xx/src/ssl/s3_pkt.c:1125:SSL alert number 40
SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/xx/src/ssl/s3_pkt.c:546:

Or you can use the following Nmap command (does not support STARTTLS):

nmap --script ssl-enum-ciphers -p [port] [host or subnet]

If the server does not support SSLv3 you should see output similar to this:

| ssl-enum-ciphers: 
| SSLv3: No supported ciphers found

As a system admin – what can I do?

As a consumer – what can I do?

See the following blogpost by Zmap.io for information how to disable clientside SSLv3 for the most popular browsers: https://zmap.io/sslv3/

Detecting SSLv3 usage in your network

You can identify servers that still use SSLv3 in your network only when an SSLv3 connection is successfully negotiated using the following IDS signature:

Note: The following rule only detects the usage of SSLv3 on servers, not clients. It makes use of the Snort SSL preprocessor (http://manual.snort.org/node147.html), please make sure the ports you want to monitor are listed in both the preprocessor config and the signature. Servers can still be vulnerable if SSLv3 is enabled but no clients make use of SSLv3 towards the server, the rule only triggers if SSLv3 is successfully negotiated.

alert tcp $HOME_NET [443,465,993,995,25] -> any any (msg:"FOX-SRT - SSLv3 Server Hello Detected (Poodle)"; flow:established,to_client; ssl_version:sslv3; ssl_state:server_hello; content:"|16 03 00|"; depth:3; threshold: type limit, track by_src, seconds 300, count 1; reference:cve,2014-3566; classtype:policy-violation; reference:url,https://blog.fox-it.com/2014/10/15/poodle/; sid:1; rev:2;)

Further reading