CryptoWall Ransomware Threat Analysis

• Author: Dell SecureWorks Counter Threat Unit™ Threat Intelligence
• Date: 27 August 2014

Overview

In late February 2014, the Dell SecureWorks Counter Threat Unit™ (CTU™) research team analyzed a family of file-encrypting ransomware being actively distributed on the Internet. Although this ransomware, now known as CryptoWall, became well-known in the first quarter of 2014, it has been distributed since at least early November 2013. CTU 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.

Background

After the emergence of the infamous CryptoLocker ransomware in September 2013, CTU researchers observed an increasing number of ransomware families that destroyed data in addition to demanding payment from victims. While similar threats have existed for years, this tactic did not become widespread until CryptoLocker's considerable success. Traditionally, ransomware disabled victims' access to their computers through non-destructive means until the victims paid for the computers' release.

Early CryptoWall variants closely mimicked both the behavior and appearance of the genuine CryptoLocker (see Figure 1). The exact infection vector of these early infections is not known as of this publication, but anecdotal reports from victims suggest the malware arrived as an email attachment or drive-by download. Evidence collected by CTU researchers in the first several days of the February 2014 campaign showed at least several thousand global infections.

Figure 1. Early CryptoWall variants (left) mimicked CryptoLocker (right). (Source: Dell SecureWorks)

As illustrated by a sample uploaded to the VirusTotal analysis service, CryptoWall has had multiple names. CTU researchers called early variants "CryptoClone" due to a lack of a unique name offered by the threat actors. In mid-March 2014, the authors revealed that the true name of this malware was CryptoDefense. In early May 2014, the malware's name was again changed to CryptoWall.

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. Similarities between CryptoWall samples and the Tobfy family of traditional ransomware suggest that the same threat actors may be responsible for both families, or that the threat actors behind both families are related.

Infection

CryptoWall has spread through various infection vectors since its inception, including browser exploit kits, drive-by downloads, and malicious email attachments. Since late March 2014, it has been primarily distributed through malicious attachments and download links sent through the Cutwail spam botnet. These Cutwail spam email attachments typically distribute the Upatre downloader, which retrieves CryptoWall samples hosted on compromised websites. Upatre was the primary method of distributing the Gameover Zeus banking trojan until Operation Tovar disrupted that ecosystem in May 2014. Upatre has also been used to distribute the Dyre banking trojan. In June 2014, the malicious emails began including links to legitimate cloud hosting providers such as Dropbox, Cubby, and MediaFire. The links point to ZIP archives that contain a CryptoWall executable.

On June 5, 2014, an aggressive spam campaign launched by Cutwail led to the largest single-day infection rates observed by CTU researchers as of this publication. These emails used a common "missed fax" lure that included links to Dropbox. This spam campaign paused over the weekend but resumed in earnest on June 9-10 with emails purporting to be from financial institutions or government agencies, as shown in Figure 2.

Figure 2. Fake tax payment rejection notice sent by Cutwail on June 10, 2014. (Source: Dell SecureWorks)

On both May 25 and May 28, just prior to this spam campaign, security researchers observed the Angler exploit kit distributing CryptoWall. The RIG exploit kit was also observed distributing this malware between May 19 and May 30. In early May, the Infinity exploit kit (also known as Goon and Redkit V2) was infecting systems with CryptoWall.

Since CryptoWall's emergence in late February 2014, CTU researchers have observed steady but low-level infection rates on Dell SecureWorks client networks. The threat actors behind CryptoWall increased the volume of its distribution in mid-May, resulting in a marked growth in infections (see Figure 3).

Figure 3. CryptoWall infections observed on Dell SecureWorks client networks. (Source: Dell SecureWorks)

On February 26, 2014, CTU researchers registered a domain used by the CryptoWall malware as a backup command and control (C2) server. Through June 13, this sinkhole received connections from 968 unique hosts that appeared to be infected with early CryptoWall variants (see Figure 4).

Figure 4. Unique IP addresses contacting a sinkhole from February 26 to June 13, 2014. (Source: Dell SecureWorks)

The geographic distribution of infected systems indicated a bias towards systems in Asian and Middle Eastern countries, as shown in Table 1.

Table 1. Geographic breakdown of infection counts.

Every new infection is assigned a unique alphanumeric code (Base 36), which is allocated sequentially by the CryptoWall backend (e.g., aaaa, aaab, aaac). Between mid-March and August 24, 2014, nearly 625,000 systems were infected with CryptoWall. In that same timeframe, CryptoWall encrypted more than 5.25 billion files. CTU researchers queried the ransom payment server using the codes assigned to each of these systems and collected the IP address, approximate time of infection, and payment status for each infection.

Figure 5 shows the geographic distribution of these compromised systems. Every nation in the world had at least one victim. Most of the infections are in the United States due to CryptoWall's frequent distribution through Cutwail spam targeting English-speaking users.

Figure 5. Global distribution of CryptoWall infections between March 12 (approximate) and August 24, 2014. (Source: Dell SecureWorks)

Table 2 lists the top ten affected countries.

Table 2. Geographic breakdown of infection counts.

Each CryptoWall sample is marked with a "campaign ID" that is transmitted to the C2 server during communication. The threat actors use this ID to track samples by infection vector. For example, the "cw400" campaign was used for samples distributed by Cutwail (either through Upatre, direct attachment, or externally linked). Table 3 lists the campaigns identified by CTU researchers. The date ranges are based on the best available evidence. These campaign identifiers could also be used to implement an affiliate program. However, as of this publication, CryptoWall is thought to be controlled and used by a single threat group.

Table 3. CryptoWall campaign identifiers, time ranges, and infection vectors.

Execution and persistence

When CryptoWall is first executed, it unpacks itself in memory and injects malicious code into new processes that it creates. It creates an "explorer.exe" process using the legitimate system binary in a suspended state and maps and executes malicious code into the process's address space. This malicious instance of explorer.exe then executes the following process:

• vssadmin.exe Delete Shadows /All /Quiet

This process causes the Windows Volume Shadow Copy Service (VSS) to delete all shadow copies of the file system. CryptoWall also disables Windows' System Restore feature by modifying the registry key:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore => DisableSR

Both techniques prevent infected systems from recovering encrypted files.

Finally, the malicious code creates a "svchost.exe -k netsvcs" process, again using the legitimate system binary. The malicious svchost.exe process is anomalous, as it runs with the privileges of the victim system's user and not as a system process (see Figure 6). Additionally, the process runs independently and does not appear as a child process of services.exe.

Figure 6. CryptoWall masquerading as a legitimate system process. (Source: Dell SecureWorks)

To establish persistence across system reboots, a copy of the malware is placed in %AppData%, %UserProfile%\Start Menu\Programs\Startup, and a directory at the root of the system drive. Then the malware adds multiple "autostart" registry keys (see Figure 7). Some CryptoWall variants also install a "RunOnce" key prefixed with an asterisk, which causes the executable to run even in Safe Mode. Each sample is configured to use a certain six hexadecimal character filename (e.g., 3e0d6a) that the malware uses in other variations (e.g., 3e0d6a9).

Figure 7. Registry keys added to establish persistence. (Source: Dell SecureWorks)

More recent CryptoWall variants terminate after successfully encrypting files and notifying the C2 server. At the time of analysis, the malware may not be executing in memory on systems affected by these variants, but the persistence mechanisms remain and ensure that the malware runs upon system reboot.

Network communication

CryptoWall uses an unremarkable C2 system that relies on several static domains hard-coded into each binary. Unlike other prevalent malware families, CryptoWall does not use advanced techniques such as domain generation algorithms (DGA) or fast-flux DNS systems. Although CryptoWall uses the WinINet application programming interface (API) to perform network functions, the malware ignores the system's configured proxy server and instead communicates directly with its C2 servers.

Once CryptoWall is active on a compromised system, it sends an initial phone-home message to the C2 server over HTTP on TCP port 80 (see Figure 8).

Figure 8. CryptoWall phone-home network traffic. (Source: Dell SecureWorks)

These servers use the Privoxy non-caching web proxy and likely act as first-tier servers that proxy traffic from victims to backend servers that manage encryption keys. In late July 2014, several distributed samples used C2 servers hosted on the Tor network, which may indicate the operators intend to eventually stop using traditional, directly accessible servers.

The requested object is the RC4 key used to encrypt the information contained in the POST parameter. The unencrypted request has the following format:

• {7|cw1900|3E0D6A957E4BF936C016D17B11951E54|4}

The "cw1900" string represents the CryptoWall binary's campaign. The string of 32 hexadecimal characters is a unique infection identifier derived from the compromised system's computer name, disk volume serial number, processor information, and OS version (see Figure 9). This string is also used as a mutex that prevents multiple copies from infecting the same system.

Figure 9. Unique infection identification string generation. (Source: Dell SecureWorks)

An active C2 server responds with data encrypted with the same RC4 key. Each request initiated by the compromised system uses a new RC4 key. After a compromised system successfully contacts an active C2 server, the system sends a second request that prompts the C2 server to send the following reply (shown unencrypted):

{216|kpai7ycr7jxqkilp.onion|b0hd|US|-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5uLyGhW15QJZIFp8QK4
/UNMpkwChp04WmzfwsnSu6CjzKZy0okrjt9iSP6PBPfwYM5CzhepUNNA2RqMPw9X
V3Vu/yQx3wS1zaSHqqluQkO/iZFxN+5HYKhUYVbOKwl1K2cGD9ynDAcqhQzZCHeT
0r4+Sy6K8SUiJRnoYG+ipxm7yHTexH+JcQKYWRsbVc/SMkiRI92NhkPM2R/pKRzJ
n/j2l4p33y19EeCQUkfDRnRQTVbdonqjvus4UYrDlUTKw8G0nLDuKnAAqDaM9wnD
G0mStK0FqGLXF8Bn6F39UVw9AFb9GpyAMjWAeZ0GGQTsI10amPjqMt2ocGHWQ8j6
XQIDAQAB
-----END PUBLIC KEY-----}

This reply includes the Tor payment site, unique payment identifier, country code of the compromised system, and the public key component of the RSA-2048 key pair to encrypt system files. The unique payment identifier allows the victim to navigate to the decryption page specific to their infection. This identifier differs from the unique infection identifier shown in Figure 9, which the threat actors use to identify victims and associate them with the stored RSA private key.

The malware regularly beacons to the C2 server during the encryption process. Once encryption is complete, the malware notifies the C2 server how many files were encrypted:

• {7|cw1900|3E0D6A957E4BF936C016D17B11951E54|3|all=2284}

The malware does not exfiltrate user credentials, files, or metadata about files. Early CryptoWall variants did transmit a screenshot of the infected system back to the C2 server, but this functionality has not been present in variants distributed since mid-March 2014.

File encryption

File encryption begins after CryptoWall successfully retrieves the RSA public key from an active C2 server. Therefore, using network-based controls to block this communication can prevent compromised systems from becoming encrypted. Unlike CryptoLocker's use of a symmetric cipher, such as AES, to encrypt bulk data, CryptoWall uses the RSA public key to directly encrypt files. Because the RSA algorithm is far more computationally intensive than symmetric ciphers, compromised systems experience significant CPU load after CryptoWall compromises as files are encrypted.

The first explicit indication of an active infection presented to a victim is the web page that CryptoWall opens after encrypting the files (see Figure 10).

Figure 10. CryptoWall "splash" screen presented to victims. (Source: Dell SecureWorks)

CryptoWall variants deployed before April 1, 2014 contained a weakness in the cryptographic implementation that allowed recovery of the key used to encrypt files. This flaw appears to have been corrected in later versions of the malware. CTU researchers have not performed a rigorous assessment of CryptoWall's cryptographic implementation, but they have not discovered any obvious flaws that allow decryption without payment.

CryptoWall recursively navigates the file system, selectively encrypting certain file types (e.g., text files, documents, source code). Executables and DLLs are left unmodified to prevent the compromised system from becoming corrupted and unusable. Table 4 lists the targeted file extensions.

Table 4. File extensions targeted for encryption.

Files on fixed (e.g., hard disks), removable (e.g., USB memory), and network drives (when mapped to a drive letter) are targeted for encryption. Furthermore, cloud storage services, such as Dropbox or Google Drive, that are mapped to a targeted file system will also be encrypted. Typically, encrypted files are five to ten percent larger than their original versions. CryptoWall marks encrypted files by prepending a custom header (see Figure 11).

Figure 11. Encrypted files from early (bottom) and later (top) CryptoWall variants. (Source: Dell SecureWorks)

CryptoWall leaves three "DECRYPT_INSTRUCTIONS" files with .url, .txt, and .html extensions in each directory it traverses. These files contain information about the infection and instructions on how to pay the ransom.

The CTU research team discourages victims from paying ransoms because it facilitates the growth of cybercrime enterprises. Victims who choose to pay the ransom submit payment and wait an arbitrary amount of time for the threat actors to confirm the payment. Once the payment has been confirmed, the victim's page on the payment server reflects the changes shown in Figure 12.

Figure 12. Redacted victim landing page after payment confirmation. (Source: Dell SecureWorks)

A "decrypt.zip" archive contains a small (30 KB) decryption program ("decrypt.exe") and the victim's secret RSA key ("secret.key") in Microsoft Cryptographic Provider key BLOB format. The decryption program is a UPX-packed executable that is uniquely generated for each victim after payment.

Payment

Like CryptoLocker, earlier CryptoWall variants included numerous payment options, including pre-paid cards such as MoneyPak, Paysafecard, cashU, and Ukash in addition to the Bitcoin cryptocurrency. Unlike CryptoLocker, the CryptoWall threat actors originally accepted Litecoin (see Figure 13); however, the only observed Litecoin address (LTv4m4y7NKHCXdw31dSEpTJmP6kXTinWDy) never received any payments.

Figure 13. Litecoin payment option in early CryptoWall variants. (Source: Dell SecureWorks)

The ransom has frequently fluctuated at the whim of the botnet operators, and no exact pattern has been established that determines which victims receive a particular ransom value. Ransoms ranging from $200 to $2,000 have been demanded at various times by CryptoWall's operators. The larger ransoms are typically reserved for victims who do not pay within the allotted time (usually 4 to 7 days). In one case, a victim paid $10,000 for the release of their files.

The web page that instructs victims how to pay the ransom displays a static Bitcoin address that is rotated at least once per day. Table 5 lists known Bitcoin addresses, the number of ransoms collected, the value in bitcoins of those received ransoms, and the value in U.S. dollars as of August 24, 2014. CTU researchers directly observed all the addresses in Table 5 in use on the CryptoWall payment servers, except the ones indicated in bold. The addresses in bold were discovered retrospectively by analyzing the transaction history of the Bitcoin network for addresses likely receiving ransom payments.

Table 5. Known CryptoWall Bitcoin addresses and received transfer totals.

The total inflow to the addresses in Table 5 is approximately 939 BTC. At the BTC exchange rate as of August 24, 2014 (1 BTC = $520), threat actors have received more than $488,000 in ransoms. These payments represent a subset of the total CryptoWall payments thought to be received. Some payments made to these addresses did not fit the pattern of CryptoWall ransom payments and may be income from other, unrelated criminal activity.

Data collected directly from the ransom payment server reveals the exact number of paying victims as well as the amount they paid. Of nearly 625,000 infections, 1,683 victims (0.27%) paid the ransom, for a total take of $1,101,900 over the course of six months. The distribution of ransom payments is shown in Table 6.

Table 6. Distribution of ransom payments made by victims.

Based on post-mortem data collected by researchers, CryptoWall has been less effective at producing income than CryptoLocker. Both malware families accepted payments via Bitcoin, with 0.27% of CryptoWall victims and 0.21% of CryptoLocker victims paying ransoms in bitcoins. CryptoLocker also accepted MoneyPak, and an additional 1.1% of victims paid ransoms using pre-paid MoneyPak cards. As of this publication, CryptoWall has only collected 37% of the total ransoms collected by CryptoLocker despite infecting nearly 100,000 more victims. CryptoWall's higher average ransom amounts and the technical barriers typical consumers encounter when attempting to obtain bitcoins has likely contributed to this malware family's more modest success. Additionally, it is likely the CryptoWall operators do not have a sophisticated "cash out" and laundering operation like the Gameover Zeus crew and cannot process pre-paid cards in such high volumes.

Conclusion

In mid-March 2014, CryptoWall emerged as the leading file-encrypting ransomware threat. The threat actors behind this malware have several years of successful cybercrime experience and have demonstrated a diversity of distribution methods. As a result, CTU researchers expect this threat will continue to grow.

The following actions may mitigate exposure to or damage from CryptoWall:

• Block executable files and compressed archives containing executable files before they reach a user's inbox.
• Keep operating systems, browsers, and browser plugins, such as Java and Silverlight, fully updated to prevent compromises resulting from exposure to exploit kits.
• Aggressively block known indicators from communicating with your network to temporarily neuter the malware until it can be discovered and removed.
• Reevaluate permissions on shared network drives to prevent unprivileged users from modifying files.
• Regularly back up data with so-called "cold" offline backup media. Backups to locally connected, network-attached, or cloud-based storage are not sufficient because CryptoWall encrypts these files along with those found on the system drive.

Software Restriction Policies (SRPs) do not effectively mitigate CryptoWall due to the way the malware infects systems.

Threat indicators

To mitigate exposure to the CryptoWall malware, CTU researchers recommend that clients use available controls to restrict access using the indicators in Table 7. The domains and IP addresses listed in the indicator table may contain malicious content, so consider the risks before opening them in a browser.

Table 7. Indicators for CryptoWall ransomware.