An analysis of Cryptowall 2.0 reveals that the ransomware relies on complex encryption routines and sandbox detection capabilities to survive. It also uses Tor for command and control, and can execute on 32- and 64-bit systems.

If you need more evidence that ransomware is here to stay, and could turn into cybercriminals’ weapon of choice, look no further than Cryptowall.

Researchers at Cisco’s Talos group today published an analysis of a Cryptowall 2.0 sample, peeling back many layers of known commodities around this threat, such as its use of the Tor anonymity network to disguise command-and-control communication. But perhaps more telling about the commitment around ransomware is the investment attackers made in its capabilities to detect execution in virtual environments, building in many stages of decryption present before the ransomware activates, and its ability to detect 32- and 64-bit architectures and executing different versions for each.

“They went through a lot of work to hide the executable in encryption, to check if it’s running in a virtual machine, and the ability to exploit multiple environments,” said Talos security research engineer Earl Carter. “So much was put into Cryptowall 2.0. Someone went to a lot of work on the front end to avoid detection.”

Cryptowall emerged close to a year ago and attackers have used it to generate noteworthy profits. Unlike first-generation ransomware that would lock a computer and generate a phony message informing the victim their machine had been seized because of illicit online activities, Cryptowall and its cousin Cryptolocker upped the ante and encrypted files on compromised machines. The malware demands a ransom for the decryption key to restore the user’s data, a key that many times is not delivered even if the ransom is forked over.

Such ransomware is delivered most often via phishing campaigns or links to websites hosting exploit kits. For the particular sample analyzed by Cisco, the means of infection was last summer’s Windows TrueType font-parsing vulnerability which enables an elevation of privileges on a machine. A dropper was built for 32-bit machines, but could also came with a 64-bit DLL that could execute on AMD Windows machines, Carter said.

“This one took from the best of both worlds; it would start with a 32-bit exploit that could also take advantage of 64-bit AMD processors. Just the fact that it was so seamless, that it could back and forth between the two however it needed to was noteworthy,” Carter said. “Normally it’s doing one or the other.”

The Cisco report goes into great detail about the stages of the various decryption routines used by Cryptowall 2.0, all in the name of avoiding detection by antimalware and intrusion detection software.

“It’s a pretty simple check looking for a common executable for VMware or (Oracle’s ) VirtualBox,” Carter said. “If it detects either, it assumes it’s in a virtual sandbox and will not execute. At that point, you don’t even have the [Cryptowall] code, just the dropper and not the actual Cryptowall binary that will run.

“Everyone has a sandbox in a virtual environment, and they’re trying to avoid that initial detection so it won’t pop up and execute in the sandbox,” Carter said. “It’s hard to identify the sample as malware, and there’s a chance it will slip through and attack more systems.”

News that Cryptowall was using Tor for command and control emerged in the fall, though it was not the first to do so. Malware and other scams have become increasingly present on Tor, which hides a packet’s originating IP address.

“Using Tor just makes it harder to identify the command and control on the back end,” Carter said. “It’s not obvious it’s command-and-control traffic going across your network. You’ll see Tor traffic, but you can’t get to the underlying information to see the distinction.”