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.

harvested-torrentlocker-addresses

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

  • 46.161.30.16
  • 46.161.30.17
  • 46.161.30.18
  • 46.161.30.19
  • 46.161.30.20
  • 46.161.30.21

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

Introduction

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

TorrentLocker

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:

annswebfolio.com/wp-content/themes/twentfourteen/showthread.php
nodramadating.com/wp-content/uploads/showthread.php
strengthyourrunning.com/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/img/showthread.php
kjob.jp/re/wp-content/themes/twentyten/showthread.php
garypilafas.com/wp-content/themes/whitehousepro3_dev/showthread.php

The above websites redirected to:

www.postnl-tracktrace.com
postnl-track.com

Domains for command and control traffic over SSL:

server4love.ru
octoberpics.ru

Command and control IP’s involved with this threat:

46.161.30.20
46.161.30.16

Fake PostNL IP’s involved with this threat:

109.68.190.174
193.124.95.83

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:

tracktrace

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:

tracktrace2

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:

warning

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:

payment

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,http://blog.fox-it.com/2014/10/15/poodle/; sid:1; rev:2;)

Further reading

Update on DecryptCryptoLocker

A month ago Fox-IT and FireEye announced the DecryptCryptoLocker service, which provides free private keys to victims of the CryptoLocker Malware. We decided not only to share the information with victims for free, but also provide a website that provides the right key to victims, saving them a lot of time and effort. For each request the website needs to do comparisons to over half a million private keys to obtain the right one. This blog and the accompanying one from FireEye serves as an update on CryptoLocker and the DecryptCryptoLocker service.

Reactions

We’ve got a lot of reactions, hundreds of inquiries and thank you notes, and tens of thousands of social media interactions. Steve Belleguelle, system administrator for multiple customers, wrote “Just a short message to say thank you so much for the work in obtaining the CryptoLocker keys database and then providing the DecryptCryptoLocker website. One of my customers ‘lost’ many thousands of files due to this malware and we have now been able to recover most of them.” For us that reaction alone makes it worth the effort, but Steve is not alone: up until last week we were able to provide 2900 keys to victims, and dozens of keys are still being provided on a daily basis. For that reason we decided to keep the DecryptCryptoLocker website running for several months. If you know a victim, point them to it.

Update on CryptoLocker

Most of the operators behind P2P ZeuS and CryptoLocker have not been seen since the operation against this group and their infrastructure, however this does not mean that the threat has gone away. The past months have seen a lot of fluidity, caused by new players trying to enter this space and existing customers of the P2P ZeuS group looking for new solutions for their crimeware needs.

Parts of the inject code have reappeared in other botnets, we are tracking new malware variants being developed which appear to re-use or build upon parts of P2P Zeus and there is an upsurge activity from Gozi, Bugat and other existing malware variants. This means some of the high profile customers of P2P Zeus are looking for a new custom piece of malware while others customers simply joined other existing operations like Gozi.

The fact that the CryptoLocker malware netted the P2P Zeus group significant income has also lead to renewed interest in ransomware as a way to make money and copycat malware using the same approach have now appeared, an example being Cryptowall – which has even copied part of the name.

Some numbers

When we started the project, we could only guess how many people we would be able to help. Now, after a month we can do a first assessment.

Please note that these statistics are not in any way correlated to personal identifiable information; and that PII was used for nothing else than delivering the private keys.

The infection rate as mentioned in the original blog post is shown below:

Cryptolocker_stats-infection

If we compare that to the decryption requests, we can see the data correlates. Indeed the top countries requests are made from, are countries where English is a major language.

Cryptolocker_stats-top20_request

Cryptolocker_stats-requests

The total number of valid decryption requests is 2900. An interesting fact is that in the UK, relatively more victims have requested their keys than in the US – more than in all other large countries to be precise. Only some very small countries with a handful of infections showed greater ratios, which can be attributed to too low statistical sample sizes.

The type of files that were offered for private key matching show some interesting things too.

Cryptolocker_stats-top10_filetypes_rounded

Although this is not necessarily a representation of the actual files being encrypted with malware, one can imagine that a .dwg file (a CAD file) might represent a lot of value to the victim, in terms of specialist hours spent on working on the file.

Feedback and other ransomware victim solutions

We try to answer every question we’re asked via e-mail or social media. Due to the overwhelming amount of feedback a reaction might have taken some time. The most asked question was from victims of other ransomware: will we be able to provide a solution for CryptoWall, Synolocker, CryptoLocker V2 or others? Unfortunately we don’t offer decryption keys for these ransomwares. It is unlikely we will provide something for that anytime soon.

Conclusion

The DecryptCryptoLocker service has been able to help thousands, and will be continued for several months, hopefully helping more victims reclaiming their files. While the original CryptoLocker malware is not used anymore, criminals though seem encouraged by its success and many more families of ransomware are now seen in the wild.

Malvertising: Not all Java from java.com is legitimate

Isn’t it ironic getting a Java exploit via java.com, the primary source for one of the most common used browser plugins? Current malvertising campaigns are able to do this. This blog post details a relatively new trend: real-time advertisement bidding platforms being infiltrated by cyber criminals spreading malware.

Malvertising

 

Conclusion

Malvertising has changed over the years starting with exploitation of weak advertisement management panels and has now evolved into pretending to be a legit third party advertiser with social engineering. The current malvertising techniques are quite deceptive and most of the times only noticeable at the client side.

Combating this malvertising technique is hard due to the large layered setup of the bidding platforms currently in place. It can be a malicious advertiser 3 layers down in the chain but it can also be on the 1st level. Trust is the current system many advertisers use but it seems to be insufficient for today’s malvertising campaigns and techniques, a new system needs to be implemented in order to combat them.

Findings in network monitoring

Over the last week, from Tuesday august 19th until Friday august 22nd, the Security Operations Center of Fox-IT’s ProtACT service observed multiple high-profile websites redirecting their visitors to malware. These websites have not been compromised themselves, but are the victim of malvertising. This means an advertisement provider, providing its services to a small part of a website, serves malicious advertisement aimed at infecting visitors with malware.

While monitoring network traffic to and from workstations we observed a higher than usual amount of infections. When investigating these incidents in depth we noticed that they were infected with advertisements served via high-profile websites. During this period at least the following websites were observed redirecting and/or serving malicious advertisements to their visitors:

  • Java.com
  • Deviantart.com
  • TMZ.com
  • Photobucket.com
  • IBTimes.com
  • eBay.ie
  • Kapaza.be
  • TVgids.nl

The advertisement in this case included the Angler exploit kit. Upon landing on this exploit kit a few checks were done to confirm whether the user is running a vulnerable version of either Java, Flash or Silverlight. If the user was deemed vulnerable the exploit kit would embed an exploit initiating a download of a malicious payload, in this campaign it was the Asprox malware. This whole process of malvertising towards an exploit kit is also visualized in the image at the top of this post.
Please note, a visitor does not need to click on the malicious advertisements in order to get infected. This all happens silently in the background as the ad is loaded by the user’s browser.

One aspect of advertisement networks that makes tracking these threats really complicated is ‘retargetting’. Retargetting is the process of one or multiple ad and content providers leaving tracking data, cookies or other files, so the next time an advertiser can deliver different advertisement as was shown the previous time. A website that rents advertisement space can sometimes show retargetted advertisement without knowing. The way it works is that a user with an interesting set of tracking cookies and other metadata for a certain adprovider is retargetted from the original advertisement content on the website to the modified or personalized data. We have seen examples where the website that helped with the ad redirect to infect a user had no idea it was helping the delivery of certain content for a certain adprovider.

While half the world is already familiar with exploitation of browser plugins, keep in mind drive-by and water-hole attacks are not solely focusing on the common browsers. A couple of months ago we also noticed advertisement loaded by the ‘Skype’-application was also serving malicious content.

In both cases Fox-IT contacted the affected advertiser, AppNexus in these cases, to quickly stop the malvertising.

The problem

The biggest problem with these malicious advertisements is that separating good from bad is a difficult process in the world of online advertising. With specific schemes such as real-time bidding, bad advertisements can remain hidden for extended periods of time. The Dutch website tweakers.net has recently published a detailed article about the problem here.

AppNexus as an example for this case, is one of the companies providing real-time bidding on advertisements and is used by many of the top ranking websites.

What is real-time bidding?

Real-time bidding is a process many advertisers have to serve ads. When a user visits a website, for example deviantart.com, this triggers a bidding request among the affiliates of the advertiser who will get to see meta-data about the visiting user. This metadata can include: geographical location, browser type, and web browsing history. The affiliates in their turn then automatically bid on this impression. The highest bidding advertisers gets to display their ad. In the case of this malvertising campaign the malicious advertisers were the highest bidders. For more details please see http://en.wikipedia.org/wiki/Real-time_bidding.

The Payload

The aim of the exploit kit is to execute a malicious file on the visitor’s computer to infect them. The Angler exploitkit has been observed to deliver different payloads in the last few days. Although the dropped malware can vary, Fox-IT has only seen the Asprox malware being spread with this campaign.

Update (August 27th): It was pointed out by Kimberly on twitter that it was in fact Rerdom that was distributed which we mistook for Asprox (https://twitter.com/StopMalvertisin/status/504652910429360129). Although, Asprox and Rerdrom do have a close relationship and affiliate with each other. More about the Asprox ecosystem can be read here on the StopMalvertising website: [ Urgent eviction notification - A deeper dive into the Asprox Ecosystem ].

Asprox is a notorious spam botnet which has upped its game over these past few months by using the infected machines to perform advertisement clicking fraud. Since this move the actors behind this botnet have started spreading Asprox on a much larger scale, at first via e-mail attachments and now by employing various exploit kits. Statistics provided by FireEye provided back in May 2014 shows big fluctuations in the botnet size and botnet activity:

FireEye Asprox tracking
(Source: http://www.fireeye.com/blog/technical/malware-research/2014/06/a-not-so-civic-duty-asprox-botnet-campaign-spreads-court-dates-and-malware.html)

In 2013 Trendmicro also published a paper about Asprox which explained the variety of functionality of the botnet. While Asprox is known as a spam botnet to most the spam is only 1 component of a modular botnet called Asprox. Asprox has gone through many changes and modifications which includes spam modules, website scanning modules and even credential stealing modules. This history and current events show Asprox is still actively being developed and used.

Indicators of compromise

These IOC’s relate to the malvertising campaign on the high-ranked websites specifically. The advertisement content first redirects to: ads.femmotion.com (204.45.251.105) which will give redirects towards the exploit kit.

The exploit kit:

Domains that were observed:

  • thegloriousdead.com (on port 37702)
  • taggingapp.com (on port 37702)

PassiveDNS logging shows 3 IP’s having been associated with these domains:

  • 198.27.88.157
  • 94.23.252.38
  • 178.32.21.248

All the exploit kit hosts were observed using port 37702. Running exploit kits on high ports at best prevents certain network tools from logging the HTTP connections, as these are typically configured to monitor only HTTP ports. It does mean this exploit kit is blocked on a lot of corporate networks as they do not allow for browsing outside the normal HTTP ports, port 80 (or proxy ports) and 443 for SSL.

The ‘Asprox’ malware:

Since this botnet makes use of a fast flux technique the domain names make for better indicators of compromise than IP’s:

  • from-gunergs.ru
  • oak-tureght.ru
  • nationwidedownload.com

The following MD5 hash was seen for the dropped payload:

  • Crypted payload: 554c5dbb12e3fd382ce16e5bb34a17c2
  • Decrypted payload: 5304bc5b9454e6bc5a0ba2bff0eba605

Advice

There is no silver bullet to protect yourself from malvertising. At a minimum:

  • Enable click-to-play in your browser. This prevents 3rd party plugins from executing automatically.
  • Keep all plugins running in the browser up-to-date using tools like Secunia PSI.
  • Consider turning off unneeded plugins if you don’t use them. For example, Java can be installed without the web-plugin component lowering the risk of exploitation and infection.

Usage of Adblockers

In cases of malvertising on websites ad blockers are usually effective in blocking redirects.
However, on the case of Skype on May 15th it would have been insufficient. Most adblockers are part of the Browsers as an add-on, incapable of filtering for other applications. Skype makes use of Adobe Flash to display certain advertisements, this happens to be a plugin which the Angler can exploit.

Fox-IT Security Research Team

CryptoLocker ransomware intelligence report

In the beginning of September 2013, the CryptoLocker malware variant appeared in the wild, spread exclusively by the infamous P2P ZeuS (aka Gameover ZeuS) malware. CryptoLocker had a simple purpose: to act as ransomware, encrypting important files such as images and documents, and then asking the victim for money to unlock the files.

CryptoLocker warning
Image source: Ars Technica

In collaboration with FireEye, InTELL analysts at Fox-IT worked on the investigation. By the end of 2013, certain groups that were focused on online banking fraud, were moving to less risky attacks, such as ransomware, click fraud, and crypto coin mining. All of these attack types pose lower risk to the criminals compared to online banking attacks. P2P ZeuS was one of these groups.

US Law Enforcement led a joint operation from the 30th of May 2014, leading to a long term disruption of both P2P Zeus and CryptoLocker. A detailed description of the operation is available here.

CryptoLocker used AES symmetric cryptography to encrypt the files and encrypted the AES key with an RSA-2048 bit public key generated on the server side of CryptoLocker. For each infection a new RSA asymmetric key pair was generated on the CryptoLocker server. This rendered files impossible to recover for CryptoLocker victims on their own. To recover files, the malware offered victims the option to purchase the required RSA-2048 private key. The CryptoLocker authors began charging victims 100 USD in September 2013 to recover their files, and by May 2014, were charging victims 500 USD for recovery.

Not every computer infected with P2P ZeuS malware became infected with CryptoLocker. The reason for this is that CryptoLocker ran on victim machines alongside P2P ZeuS malware, which was used to commit financial fraud. In order for P2P ZeuS to be successful, a victim had to remain unaware that his/her system was compromised. Therefore, only a handful of P2P ZeuS botnets within the full P2P ZeuS network installed CryptoLocker. From September 2013 through May 2014, over half a million (545,146) infections occurred. This is much less than the amount of infections of P2P ZeuS over the same period.

Of the botnets distributing CryptoLocker, infections were mostly limited to victims located in the US, Canada, UK and Australia. These regions were most likely selected for their use of English as the primary language. This is shown in the heat map below – with over 60% of the CryptoLocker infections located in the US.

Global-Infection-Rate-Cryptolocker

While CryptoLocker infections started in the beginning of September 2013, the largest number of infections in one month occurred during October 2013, with over 155000 systems affected worldwide. This accounts for nearly 29% of all infections between September and May 2014. After October 2013 the rates dropped, but still steadily pacing at around 50,000 infections per month.

infections-per-month
The CryptoLocker infrastructure was separate from the P2P ZeuS infrastructure. It used a fast-flux network offered by a bulletproof hoster and a service hidden in the TOR network. These two channels were terminated on a proxy system that lead directly to the backend system, allowing victims to pay the ransom even though the fast flux network experienced various disruptions by security researchers.

The majority of victim payments to CryptoLocker were processed through Moneypak, but also a considerable amount of money was paid through the use of Bitcoins. A new Bitcoin address was created for each infection, making it harder for researchers to track and easier for CryptoLocker operators to distinguish transactions. In total, over 1400 Bitcoins (1407.24575477 BTC, around 700,000 USD in current exchange rates) were received. That is more than the 1388 BTC the malware requested, apparently some victims tried to transfer partial amounts. Unfortunately for them these lower amounts were lost for them and they added a small bonus for the criminals. A small number of early payments were received via Paysafecard and Ukash. In total, the amount of money made during the 9 month CryptoLocker operation was around 3 million USD. This accounts for the fluctuating Bitcoin exchange rate over time.

Payments-Cryptolocker
In the end, 1.3% of victims paid a CryptoLocker ransom, therefore, a large amount of victims likely permanently lost files due to this attack. Fox-IT InTELL and FireEye provide a free service to victims, to recover the private keys associated to CryptoLocker infections. This was announced on August 6 2014, in this press release. This gives CryptoLocker victims the ability to recover their files and restore the contents.

A big thank you to Kyrus tech for their tool Cryptounlocker. And finally we wish to thank Surfright for their assistance by providing encrypted files they generated using CryptoLocker.

Michael Sandee

Links:

http://www.fireeye.com/
http://www.fox-it.com/
http://www.foxintell.com
https://www.decryptcryptolocker.com/
http://www.fbi.gov/news/pressrel/press-releases/u.s.-leads-multi-national-action-against-gameover-zeus-botnet-and-cryptolocker-ransomware-charges-botnet-administrator
http://www.kyrus-tech.com/cryptolocker-decryption-engine/
http://www.surfright.nl/en
http://arstechnica.com/security/2013/10/youre-infected-if-you-want-to-see-your-data-again-pay-us-300-in-bitcoins/
http://www.fireeye.com/news-events/press-releases/read/fireeye-and-fox-it-announce-new-service-to-help-cryptolocker-victims

OpenSSL ‘heartbleed’ bug live blog

heartbleedA bug has been identified in OpenSSL, all details can be found at heartbleed.com. The bug has been assigned CVE-2014-0160. OpenSSL versions 1.0.1 – 1.0.1f are vulnerable. We advise to upgrade OpenSSL to version 1.0.1g or higher

Test if you are vulnerable

You can test if you are vulnerable by requesting a heartbeat response with a large response. If the server replies your SSL service is probably vulnerable. You can use any of the tests below:

This vulnerability only applies to OpenSSL versions 1.0.1-1.0.1f. Other SSL libraries, such as PolarSSL, are not vulnerable. OpenVPN-NL, which is depending on PolarSSL, is not affected.

Advice

We advise to perform the following steps for every vulnerable SSL service

  • Upgrade the OpenSSL version to 1.0.1g
  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

Indicator of Compromise

It is possible to detect successful exploitation of this vulnerability by inspecting the network traffic. We have developed 2 sets of Snort signatures to detect succesful exploitation of the ‘heartbleed bug’. The first set has a higher detection rate but also quite a few false positives:

alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible SSLv3 Large Heartbeat Response"; flow:established; ssl_version:sslv3; content:"|18 03 00|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001126; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1 Large Heartbeat Response"; flow:established; ssl_version:tls1.0; content:"|18 03 01|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001127; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.1 Large Heartbeat Response"; flow:established; ssl_version:tls1.1; content:"|18 03 02|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001128; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.2 Large Heartbeat Response"; flow:established; ssl_version:tls1.2; content:"|18 03 03|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001129; rev:8;)

The second set has a lower false positive ratio but might also have a slightly lower detection rate:

alert tcp any any -> any any (msg:"FOX-SRT - Flowbit - TLS-SSL Client Hello"; flow:established; dsize:< 500; content:"|16 03|"; depth:2; byte_test:1,​ <=,​ 2,​ 3; byte_test:1,​ !=,​ 2,​ 1; content:"|01|"; offset:5; depth:1; content:"|03|"; offset:9; byte_test:1,​ <=,​ 3,​ 10; byte_test:1,​ !=,​ 2,​ 9; content:"|00 0f 00|"; flowbits:set,​foxsslsession; flowbits:noalert; threshold:type limit,​ track by_src,​ count 1,​ seconds 60; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001130; rev:10;)
alert_testing tcp any any -> any any (msg:"FOX-SRT - Suspicious - TLS-SSL Large Heartbeat Response"; flow:established; flowbits:isset,​foxsslsession; content:"|18 03|"; depth: 2; byte_test:1,​ <=,​ 3,​ 2; byte_test:1,​ !=,​ 2,​ 1; byte_test:2,​ >,​ 200,​ 3; byte_test:2,​<,​16409,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001131; rev:6;)

Note: if you want to detect vulnerable SMTP servers that are being exploited via STARTTLS, make sure that you do not have “ignore_tls_data” enabled on your SMTP preprocessor.

Impact

An attacker can retrieve a block of memory of the server up to 64kb. There is no limit on the number of attacks that can be performed. The attacker has no control over the memory region where the block is read from. Sensitive information that can be obtained is:

  • SSL private keys
  • Basic authorization strings (username / password combinations)
  • Source code

This bug affects both sides of the connection. Not only will client certificates not save you from having to update your server certificate, they can be read from the client (along with your username, password etc.) by any server you connect to. DNS poisoning, MitM etc. can be used to direct clients to a malicious server – it seems that this vulnerability can be exploited before the server has to authenticate itself.

According to http://www.openssl.org/news/openssl-1.0.1-notes.html the heartbeat extension was introduced in March 2012 with the release of version 1.0.1 of OpenSSL. This implies the vulnerability has been around for 2 years.

Updates

OpenSSL has provided an updated version (1.0.1g) of OpenSSL at https://www.openssl.org/source/.

Linux distributions are providing updates right now, so check your system for updates. Some Linux distributions have backported the fix to previous versions, ie Debian’s OpenSSL 1.0.1e-2+deb7u5 package has incorporated the fix.

Examples

When running the ssltest.py script against yahoo.com we were presented with this (censored) output. It shows clearly that the ‘heartbleed bug’ has serious consequences.

heartbleed example

 

 

 

Building Bowser – A password cracking story

At Fox-IT we perform a lot of penetration tests. Invariably we encounter hashed versions of passwords that need to be tested for strength. We suspected that with a relatively small investment most passwords could be cracked, regardless of their complexity. It turns out this is true for any password of 8 characters or less. 

This is a story about passwords. It’s intended for hardware lovers and IT security managers alike. The purpose is to change the views on what requirements a password has to fulfill to be considered “safe”. Basically, this story should convince you that conforming to the default Microsoft Password Complexity Requirements (http://technet.microsoft.com/en-us/library/cc264456.aspx) barely bothers hackers trying to crack your password, and explains why everyone should be switching to passphrases. Don’t bother with taking the first letter of all words in a sentence, just use the whole sentence. The longer the better. Cracking passwords in a short timeframe is something we were able to do on a fairly limited budget, but will scale up very nicely with a larger one. Imagine what someone with virtually unlimited funds (intelligence agencies, countries) is able to do to your precious password hashes.

Over the years we’ve done our fair share of penetration tests, both on external services and internal networks. This includes web applications, Windows- and Unix networks, mobile applications, etc. During these tests it’s not uncommon to come across hashed passwords in one form or another. While some protocols (like NTLM) are vulnerable to a technique called “passing-the-hash” (essentially using the hash itself as a password), sometimes you just want its plaintext counterpart. For the sake of consistency, this story will focus on NTLM (Windows) passwords.

One of the ways of obtaining the plaintext password is by “cracking” the hash. You can go about this using different techniques. The most basic of which being a “brute-force” attack, simply trying all combinations of letters, numbers, special characters, etc. and see if the resulting hash matches the hash you are trying to crack.

Another technique is using wordlists. These are huge lists containing hundreds, thousands and even millions of words depending on the size of the list. By simply hashing each word on the list one by one, and seeing if the resulting hash matches your target hash you can try and “crack” it this way.

Modern tools allow you to use these methods in smarter ways, by combining wordlists with brute-force techniques, or applying rules to words on the list (adding capitals, appending numbers or special characters, etc.). Still, this can be a time consuming project when using regular desktop hardware.

Enter the video card or GPU (Graphics Processing Unit). While designed for running games, these cards have power in all the right places for use in password cracking. I could go on explaining about the how, why and other technical mumbo-jumbo, but sometimes pictures indeed are better than words. This screenshot was taken from the password cracking tool hashcat (http://www.hashcat.net) and shows the speed of cracking an NTLM hash while running on two cores of an Intel i7 3840QM CPU:

image001

Almost 34 million words per second (34MH/s). Sounds like a lot right? Well, it’s not, really. At this rate, trying all 8 character passwords (uppercase letters, lowercase letters, decimals and special characters) takes approximately four to five months.

Let’s try cracking that same password using oclHashcat, hashcat’s big brother, designed for use with GPU’s. This screenshot was taken while running oclHashcat on our old cracking machine with a single AMD Radeon 7970 GPU:

image003

Wow, a single GPU can do almost 18000 MH/s. Compared to the 34MH/s the CPU can do, that’s around 53000% more per second. At this rate, trying all 8 character passwords will take somewhere around five days. We are impatient people though, so we wanted more speed.
This is when we decided to build a new dedicated server, designed for one thing, and one thing only: cracking password hashes. This new server, codename “Bowser”, would be a 4U server chassis from Tyan (FT72B7015), have two Intel Xeon CPU’s, two 1TB SSD’s, 4x8GB of RAM and most important, eight AMD Radeon R9 290X GPU’s. Time to place some orders!
The first things to arrive were the GPU’s. Just look at these beauties:

The next day, the CPU’s came in:

image012

The rest however, took a while. The Tyan chassis wasn’t in stock and had to be back-ordered from Taiwan. Almost two weeks went by, until:

Finally! Time to start building. Instead of boring you with a wall of text, I’ll just let the pictures do the talking:

Quite something right? Now time for the hard part. Making the system secure enough for customer data. The OS we’ve chosen to install was Debian 7 at first, but it looked like the 3.2 kernel shipped with Debian 7 did not very much like our hardware. Random kernel panics and freezes everywhere. So, on to Ubuntu Server 12.04.3.

The first 1024MB of the first SSD was partitioned as unencrypted /boot partition. The first 1024MB of the second SSD was partitioned as unused space. This was done because the rest of both SSD’s were configured to run as a RAID0 volume. Why? It’s not business critical data, and large wordlists on slow disks really impact the cracking performance.

On the newly created RAID0 volume, a LUKS encrypted partition was made. Using LVM, a volume group was created on that partition. This volume group contained two logical volumes. The root file system (/) and some swap space.

After OS installation was done, it was time for some benchmarks! Firstly, we made sure that the BIOS switch on all the cards was set to “Über mode” (http://www.hardocp.com/article/2013/10/23/amd_radeon_r9_290x_video_card_review/2#.Uukqp3VdXZg). Then we installed a tool called od6config (http://epixoip.github.io/od6config/) to fix the fan speed of the cards at 100%, the GPU clock at 1000MHz and the Memory clock at 1250Mhz. Because a running X session is necessary to use the GPU’s, we also installed Ubuntu Desktop and the AMD 13.12 driver package.

The firewall was configured to only allow communication needed for remote management. All other incoming and outbound traffic was disallowed.
Finally, benchmark time! Feast your eyes on this:

image059

145GH/s per second! That is a performance increase of around 800% compared to the single card. This means that we are able to retrieve all 8 character NTLM hashed passwords (uppercase, lowercase, decimal and special characters) within 24 hours! All the while, due to the insane cooling capabilities of the Tyan chassis, temperatures keep well within acceptable ranges:

image061

Note: adapter 1 has a higher temperature than the rest, because this adapter is responsible for showing the desktop.
After some tuning, we managed to get a 100 MHz core overclock on all the cards. This resulted in a 20Gh/s increase in performance with a total of almost 190GH/s (while cracking a single NTLM hash):

image062

That’s the equivalent of 9 of these cards running at stock speeds. The temperatures after about 19 hours seem almost unaffected. The card responsible for showing the desktop peaked at 76C, while the other cards average at about 65C.

It does take a considerable amount of power to run this machine though:

image064 image066

2500 Watts, 12 Amps. Nice.

I can hear you thinking “Why not just use rainbow tables and get it over with”. While it’s true that rainbow tables can be an effective way of cracking passwords, they are not a magical solution. First off, the tables themselves require a lot of storage space (for example: around 1TB for alpha-numeric passwords, length one to eight). Secondly they take a very long time to generate and every type of hash needs a new table. Lastly, with a large list of hashes to crack (say, a dump of all active directory passwords) the pre-calculation when using rainbow tables can take much longer than just using wordlists or brute-force attacks. In most cases, it is faster to just brute-force a hash then to use rainbow tables on it. Besides, the combination of wordlists, rules and brute-force can usually crack more than 80% of the hashes already. If you really need a specific hash cracked, you can always resort to rainbow tables after brute forcing the bulk of the hashes.

Well, that’s it. Feel free to leave any questions you might have in the comments, and happy cracking!

Donny Maasland, Pentester at Fox-IT

Tilon/SpyEye2 intelligence report

SpyEye2 infrastructure

Tilon, son of Silon, or…
SpyEye2 evolution of SpyEye?

The malware family commonly known as Tilon has been around for several years now. While several public analysis reports have described the malware; no one has thus far linked it with the well-known SpyEye malware family. In light of the recent news of the guilty plea of SpyEye distributor Gribodemon we revisit the Tilon malware family. We give a detailed analysis of similarities to SpyEye and also place Tilon and SpyEye into a wider context of the digital underground.

The original name Tilon was chosen due to the similarities with Silon. This was merely true for the outer layer of the malware, the so called loader. A better name probably was SpyEye2, as the functional part of the malware is sourced from SpyEye. The team behind its creation was similar, however reinforced with at least one better skilled programmer.

The decline in Tilon/SpyEye2 activity after the arrest of Gribodemon was evident, the development however continued and the fraudulent activities did not stop. Finally after nearly a year of declining usage, it seems we might have come to the real end of the SpyEye era, or will the team behind SpyEye2 continue and start working on getting new customers?

Read all the details in this intelligence report.

Fox-IT InTELL

Malicious advertisements served via Yahoo

Detection of the infection

Fox-IT operates the shared Security Operations Center service ProtACT. This service monitors the networks of our clients for malicious activity. On January 3 we detected and investigated the infection of clients after they visited yahoo.com.

Infection

Clients visiting yahoo.com received advertisements served by ads.yahoo.com. Some of the advertisements are malicious. Those malicious advertisements are iframes hosted on the following domains:

  • blistartoncom.org (192.133.137.59), registered on 1 Jan 2014
  • slaptonitkons.net (192.133.137.100), registered on 1 Jan 2014
  • original-filmsonline.com (192.133.137.63)
  • funnyboobsonline.org (192.133.137.247)
  • yagerass.org (192.133.137.56)

Upon visiting the malicious advertisements users get redirected to a “Magnitude” exploit kit via a HTTP redirect to seemingly random subdomains of:

  • boxsdiscussing.net
  • crisisreverse.net
  • limitingbeyond.net
  • and others

All those domains are served from a single IP address: 193.169.245.78. This IP-address appears to be hosted in the Netherlands.

This exploit kit exploits vulnerabilities in Java and installs a host of different malware including:

  • ZeuS
  • Andromeda
  • Dorkbot/Ngrbot
  • Advertisement clicking malware
  • Tinba/Zusy
  • Necurs

The investigation showed that the earliest signs of infection were at December 30, 2013. Other reports suggest it might have started even earlier.

Schematically the exploit looks like this:

yahoo ads malware

Size

Based on a sample of traffic we estimate the number of visits to the malicious site to be around 300k/hr. Given a typical infection rate of 9% this would result in around 27.000 infections every hour. Based on the same sample, the countries most affected by the exploit kit are Romania, Great Britain and France. At this time it’s unclear why those countries are most affected, it is likely due to the configuration of the malicious advertisements on Yahoo.

yahoo ad distribution

Motivation

It is unclear which specific group is behind this attack, but the attackers are clearly financially motivated and seem to offer services to other actors. The exploit kit bears similarities to the one used in the brief infection of php.net in October 2013.

Advice

Block access to the following IP-addresses of the malicious advertisement and the exploit kit:

  • Block the 192.133.137/24 subnet
  • Block the 193.169.245/24 subnet

Also closely inspect network traffic for signs of successful exploits for any of the dropped malware.

Yahoo is aware of the issue and looking into it.

Please watch this page for updates.

Update January 3, 1815 (GMT+1): It appears the traffic to the exploit kit has significantly decreased. It looks like Yahoo is taking steps to fix the problem.