Attacks/Breaches
8/28/2014
05:45 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

CryptoWall More Pervasive, Less Profitable Than CryptoLocker

The former CryptoLocker wannabe has netted 625,000 infected systems and more than $1 million in ransoms.

CryptoWall might have been just a CryptoLocker wannabe a few months ago, but since CryptoLocker went down with the GameOver ZeuS ship in June, CryptoWall has taken its place as the top ransomware on the market, according to a new report.

Like similar ransomware, CryptoWall infects an endpoint, encrypts users' files, and demands payment from those who want access to those files. CryptoWall can get its hands on hard disks, removable drives, network drives, and even cloud storage services that are mapped to a targeted file system.

CryptoWall is neither as technologically sophisticated nor as profitable as CryptoLocker, but it has infected more systems, and it's earned a cool million for its operators so far. Dell SecureWorks' Counter Threat Unit says in a new threat intelligence report that its researchers "consider CryptoWall to be the largest and most destructive ransomware threat on the Internet as of this publication, and they expect this threat to continue growing."

CryptoWall has infected approximately 625,000 systems worldwide -- 80,000 more than CryptoLocker. According to Dell SecureWorks, every nation in the world has at least one victim, but more than 250,000 are in the United States.

CryptoWall has encrypted 5.25 billion files. To retrieve their files, victims generally pay ransoms ranging from $200 to $2,000 apiece, but one unfortunate person paid $10,000. Over the course of six months, the CryptoWall operators convinced 1,683 victims to pay up and made $1,101,900 in ransoms.

This is rather a small haul when compared to CryptoLocker, which made $27 million in its first two months. Researchers have a few theories as to why CryptoWall is less profitable.

For one thing, it does not provide enough payment options. CryptoLocker accepted bitcoins and MoneyPak, but CryptoWall takes only bitcoins, so it's more difficult for victims to hand over the dough.

CryptoWall may have the price point wrong. It asks for a higher average price from each individual than CryptoLocker did. Also, CryptoWall isn't as well connected as CryptoLocker, which had access to the GameOver ZeuS gang's cashout and laundering services.

It is also not as technologically sophisticated. Before it can encrypt any files on or mapped to the machine it's infected, CryptoWall must call back to its command-and-control server to retrieve a RSA public key. Therefore, blocking that initial communication with the C2 server will prevent the ransomware from ever holding anything for ransom -- and this C2 system is "unremarkable," according to SecureWorks.

"Unlike other prevalent malware families, CryptoWall does not use advanced techniques such as domain generation algorithms or fast-flux DNS," the report said. Nevertheless, "while neither the malware nor infrastructure of CryptoWall is as sophisticated as that of CryptoLocker, the threat actors have demonstrated both longevity and proficiency in distribution."

CryptoWall has used the Cutwail botnet to spread through malicious email attachments and malicious download links -- sometimes to the Upatre downloader and other times to legitimiate cloud hosting providers like DropBox and MediaFire. It's also spread through the Angler, RIG, and Infinity exploit kits.

Researchers have seen similarities between CryptoWall and the Tobfy ransomware family. This suggests that the threat actors for both are the same or are related.

"The threat actors behind this malware have several years of successful cybercrime experience and have demonstrated a diversity of distribution methods," the report said. "As a result, CTU researchers expect this threat will continue to grow."

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
theb0x
50%
50%
theb0x,
User Rank: Moderator
8/29/2014 | 4:55:25 PM
Re: What should enterprises do when faced with ransomware?
Given the complexity of the encryption used, a bruteforce attack is not practical by any means for key retrieval. I have seen both cases where paying the ransom has allowed the user/company to retrieve their data successfully. I have also seen the ransom paid and no key was ever provided by the criminal. If you have no valid backup of your files, the only chance you have at all is to pay it. That may not be what you want to hear but is the truth in most incidents.

Some of this ransomware is quite sophisticated as it does indeed encrypt all locally attached storage, network shares, sdeletes all volume shadow copies etc of previous version files.


Besides having offsite redundant backups, I recommend that all backups performed are locally encrypted prior to being sent offsite. This ensures your files cannot be affected. The ransomware will not be able to access your files with it's cipher.

Network share permissions should be reviewed for all user accounts and a GPO should be put in place to deny executible processes from running in %AppData% and %LocalAppData .

 
Robert McDougal
50%
50%
Robert McDougal,
User Rank: Ninja
8/29/2014 | 3:05:14 PM
Re: What should enterprises do when faced with ransomware?
As much as I would like to say there isn't a situation in which you should pay the ransom, since doing so encourages the attackers, but that isn't always the case.  Until recently, most of the computers that I dealt with which were infected with Cryptowall have all had backups.  A few months ago a user's PC was infected and she didn't have a backup and to make matters worse her PC contained the all the financial documents for the organization.  Losing that data would have been devastating to her small business so I advised her to pay the ransom of $400 to get the data back.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
8/29/2014 | 2:55:59 PM
Re: What should enterprises do when faced with ransomware?
Very good questions. I have just recently dealt with ransomware and have experience in dealing with both sets of questions. However unfortunately Marilyn I would not want to alienate any organizations regarding your question so I will be ambiguous in your answer and say yes. Luckily my current organization has never dealt in such matters but I know of ones that have.

@DarkReadingTim, I would say no to , "are there situations where instituations consider paying the ransom" and here is why. Ransomware and restricting local areas shouldn't be a factor. It should be dictated in your enterprises policy and for best business practice that all data be stored on mapped drives. Stored in a data center and backed up to other servers. In this way for ransomware and physical theft, you are not in trouble of losing your data and don't find yourself in that situation.

You have the right to call law enforcement regarding these situations however I am not certain as to the success percentage of discovering the perpetrator. Before you do anything document everything done to the machine. Logging is critical before law enforcement should get involved. (Senior professionals should be the ones investigating)

Lastly, as stated above, I believe this should be set by policy. Policies are the foundation to information security. Before pursuing any endeavor, policy is the first item that should be set.

Thats just one InfoSec Professionals opinion, does anyone have a different outlook that could provide an outside perspective?
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
8/29/2014 | 10:41:54 AM
Re: What should enterprises do when faced with ransomware?
Those are great questions, @DarkReadingTim. I've got one to add (and I doubt that anyone will answer), but here goes: Isn't it likely that companies that do pay a ransom would not publicize the fact -- so as not to encourgage more ransomware threats?
DarkReadingTim
50%
50%
DarkReadingTim,
User Rank: Strategist
8/29/2014 | 9:59:00 AM
What should enterprises do when faced with ransomware?
I'm interested to hear what security professionals advise when faced with ransomware infections such as those outlined in the story. Are there situations when they should consider paying the ransom? What are the implications for their data if they call in law enforcement? Is this something an enterprise can set a policy on, or is it really decided on a case-by-case basis?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5700
Published: 2014-09-22
Multiple cross-site scripting (XSS) vulnerabilities in Baby Gekko before 1.2.2f allow remote attackers to inject arbitrary web script or HTML via the (1) id parameter to admin/index.php or the (2) username or (3) password parameter in blocks/loginbox/loginbox.template.php to index.php. NOTE: some o...

CVE-2014-0484
Published: 2014-09-22
The Debian acpi-support package before 0.140-5+deb7u3 allows local users to gain privileges via vectors related to the "user's environment."

CVE-2014-2942
Published: 2014-09-22
Cobham Aviator 700D and 700E satellite terminals use an improper algorithm for PIN codes, which makes it easier for attackers to obtain a privileged terminal session by calculating the superuser code, and then leveraging physical access or terminal access to enter this code.

CVE-2014-3595
Published: 2014-09-22
Cross-site scripting (XSS) vulnerability in spacewalk-java 1.2.39, 1.7.54, and 2.0.2 in Spacewalk and Red Hat Network (RHN) Satellite 5.4 through 5.6 allows remote attackers to inject arbitrary web script or HTML via a crafted request that is not properly handled when logging.

CVE-2014-3635
Published: 2014-09-22
Off-by-one error in D-Bus 1.3.0 through 1.6.x before 1.6.24 and 1.8.x before 1.8.8, when running on a 64-bit system and the max_message_unix_fds limit is set to an odd number, allows remote attackers to cause a denial of service (dbus-daemon crash) or possibly execute arbitrary code by sending one m...

Best of the Web
Dark Reading Radio