Blue Coat Labs

Labs Blog

Cryptowall Demands Cryptocurrency, Abuses Tor

Cryptowall Demands Cryptocurrency, Abuses Tor

Andrew Brandt

Last week, while on the road having meetings with some of our European partners and customers, I stumbled upon a very interesting infection: Cryptowall. The Trojan is a form of ransomware, similar to CryptoLocker in that it encrypts various document filetypes and then demands a financial payment for their safe return. But it differs from CryptoLocker in some important ways, which I'd like to describe here.

The URL that had been hosting the Cryptowall malware sample I obtained was only viable for a few hours last week; I managed to grab a copy of the file before it disappeared, and ran it on a testbed connected to a hotel's Internet service in the Netherlands. The malware ran for a considerable amount of time before it displayed a warning message informing me that it had encrypted the files on my testbed.

Unlike its predecessor, CryptoLocker, which threatened to delete the decryption key after 72 hours, Cryptowall's countdown timer is merely a trigger to a doubling of the ransom.

Immediately after execution, the malware hooked the system processes shown above, then began to try to connect to a number of different IP addresses using the Tor protocol. Tor is a network service that, effectively, allows two computers to communicate with one another over the Internet without revealing each computer's IP address to the other. While it can be useful for people such as, for example, human rights activists who operate in countries where repressive regimes may react violently to dissent, it's also useful for criminals or others with less noble intentions. The initialization of Tor communications typically involves TCP traffic in the port 9001-and-above range, which is what I saw it start to do.

The Tor traffic spun up for a short time and then the infected machine made a more traditional, SSL-encrypted connection to a server that claimed to act as a "Tor-to-web gateway" -- in essence, an entry point into the Tor network that doesn't require one side of the conversation to have the Tor software installed on their computer.

CryptoLocker was defeatable, in part, because the malware would not encrypt data files until and unless the malware could exchange data (including the encryption keys) with its command-and-control server. By blocking access to the IP address ranges and domain names used by the malware, infected machines would not incur additional damage. The use of Tor, however, encapsulates the communication in onion-like layers of obfuscation that prevents readily blocking the communication based on the address of the endpoint. That said, blocking all Tor traffic, as well as the Tor-Web gateway services, may be prudent as a precaution. These URLs shown above were shut down within days of the infection taking hold.

Immediately after making this connection, the malware dropped a couple of files on the testbed, and then displayed a detailed warning message explaining what the malware has done and what the victim needs to do next if he/she wants to get the now-encrypted files back: Pay the criminals the equivalent of either 500 euros or 500 dollars in Bitcoins (only).

The criminals, in this case, employed a "countdown clock" similar to that used by CryptoLocker, but with a twist: CryptoLocker basically gave the victim 72 hours to comply with the ransom demand or, as threatened, the criminals would delete the decryption key and the affected files on the infected system would be lost forever. Cryptowall gives you a period of time to pay, and when that time elapses, the ransom demand doubles in cost, from 500 to 1000 euros/dollars, again payable only in Bitcoins.

All of the interaction between the victim and Cryptowall's operators takes place through the browser on the infected machine. The instructions describe victims multiple different ways to reach the criminals, including by installing a Tor client on the infected machine, in case the Tor-to-Web gateway site goes down (which it did on Monday). Before the service went offline, we did some experiments using the SSL Visibility Appliance, and as shown above, we were able to man-in-the-middle their certificate and extract the session artifacts from these interactions.

We also determined that, just by changing one variable in the URL provided, we were able to see the countdown timer, operating system, and IP address and IP geolocation details of other victims, such as the one shown above. The process was made somewhat more tedious because the criminals implemented the use of a "captcha" image before you could view the "threat message" targeted at a different victim.

Checking into our logs, we've seen a spike in the volume of traffic to sites that appear to be hosting Cryptowall or its close relative, another ransomware known as Cryptodefense. Webpulse researchers have deployed automation that seeks out new URLs being used for the command-and-control traffic and it has ramped up significantly in the past few days.

Cryptowall's Web-based "service" also provides an opportunity for the criminals to demonstrate their ability to carry out the decryption process: They allow you to upload a single file that has been encrypted, and they'll return the decrypted file to you with a download link. It does work, which I suppose proves that the criminals are able to deliver on their promises, as loathsome as they (and the threat) may be.

Looking closer at the malware itself, we discovered a rootkit-masked process that hooked explorer.exe and svchost.exe. I suspended the thread performing the encryption task (it had been running at full CPU load for nearly 30 seconds) and dumped the process memory of svchost, and found that this was, in fact, the process performing the encryption.

Revealing strings of text were scattered throughout the process memory.

Tracing the line backwards, we found the malware in a folder flagged with the "hidden" flag in the root of the C: drive on the infected machine.

Inside this folder was a single file, the Cryptowall binary.

Tracing the infection back even further, we found the root cause of the infection was a fake message purportedly originating from Wells Fargo bank about some sort of "secure message" or "fax delivery" -- an old scam, to be sure, but clearly still useful to the criminals. The file in this case was a copy of the Upatre downloader malware, which retrieved and executed Cryptowall as its primary payload. Chris Larsen has already blogged about Crypto-ransomware being delivered via malvertisement driveby infections, as well.

In this case, it appears to be the continuation of a pattern of abuse of various cloud storage services: In the past several weeks, we've seen URLs pointing to malware samples stored on Amazon's cloud, Microsoft's storage service, Google docs, Dropbox,, and now To their credit, all of these services have been shutting down the files as quickly as they appear, but a few may escape notice, and for every minute that one of these malware samples persists in the wild, untold numbers of victims may end up in these dire straits.

As with CryptoLocker and other data encrypting ransomware, our most salient advice remains that you should encourage everyone you know to perform daily backups of all data, check those backups to make sure they work, and ensure you're backing up everything you might wish to recover, including things like browser bookmarks, mail files, or other files holding important data that aren't on the desktop or the My Documents folder.

A good backup, in essence, drastically reduces the severity of any threat these malware goons might direct at a victim. With backups of all files, you could shrug a "so what" at the threat, reimage your hard drive with a clean copy of your OS, and restore the data with minimal disruption. The sad fact is that most people don't regularly back up their data, and those who do may not do so on a daily basis, or as thoroughly as necessary to quickly recover from a total loss that malware such as Cryptowall can produce.