CryptoLocker Ransomware

In mid-September 2013, the Dell SecureWorks CTU(TM) research team observed a new ransomware malware family called CryptoLocker. Ransomware malware such as Reveton, Urausy, Tobfy, and Kovter has cost consumers considerable time and money over the past several years. Ransomware prevents victims from using their computer normally (e.g., by locking the screen) and uses social engineering to convince victims that failing to follow the malware authors’ instructions will lead to real-world consequences. These consequences, such as owing a fine or facing arrest and prosecution, are presented as being the result of a fabricated indiscretion like pirating music or downloading illegal pornography. Victims of these traditional forms of ransomware could ignore the demands and use security software to unlock the system and remove the offending malware. CryptoLocker changes this dynamic by aggressively encrypting files on the victim’s system and returning control of the files to the victim only after the ransom is paid.

The earliest CryptoLocker samples appear to have been released on the Internet on September 5, 2013. Details about this initial distribution phase are unclear, but it appears the samples were downloaded from a compromised website located in the United States, either by a version of CryptoLocker that has not been analyzed as of this publication, or by a custom downloader created by the same authors.

Early versions of CryptoLocker were distributed through spam emails targeting business professionals (as opposed to home Internet users). The lure was often a “consumer complaint” against the email recipient or their organization. Attached to these emails was a ZIP archive with a random alphabetical filename containing 13 to 17 characters. Only the first character of the filename is capitalized. The archive contained a single executable with the same filename as the ZIP archive but with an EXE extension. Table 1 lists several examples observed by CTU researchers.

On October 7, 2013, CTU researchers observed CryptoLocker being distributed by the peer-to-peer (P2P) Gameover Zeus malware in a typical pay-per-installation arrangement. In this case, Gameover Zeus was distributed by the Cutwail spam botnet using lures consistent with previous malware distribution campaigns. Figure 1 shows a phishing email delivered by Cutwail on October 7, 2013. Attached to the message is a ZIP archive containing a small (approximately 20KB) executable using a document extension in the filename and displaying an Adobe Reader icon. This Upatre malware downloads and executes Gameover Zeus, which in turn downloads and installs other malware families including CryptoLocker.

As of this publication, Gameover Zeus remains the primary method of distributing CryptoLocker. In addition to being distributed by Cutwail, Gameover Zeus has also been distributed by the Blackhole and Magnitude exploit kits.

CryptoLocker hides its presence from victims until it has successfully contacted a command and control (C2) server and encrypted the files located on connected drives. Prior to these actions, the malware ensures that it remains running on infected systems and that it persists across reboots. When first executed, the malware creates a copy of itself in either %AppData% or %LocalAppData%. CryptoLocker then deletes the original executable file.

CryptoLocker then creates an “autorun” registry key:

Some versions of CryptoLocker create an additional registry entry:

The asterisk at the beginning of the key name ensures that the malware executes even if the system is restarted in “safe mode.”

Additional configuration data is stored in the following registry key:

The VersionInfo value stored within this key contains configuration data encoded with the XOR key 0x819C33AE. The PublicKey value contains the RSA public key received from the C2 server during the initial network connection.

The executable files in early CryptoLocker samples used a random filename formatted like a GUID:

However, the executable files in recent samples use the naming pattern shown in the second column of Table 1.

Several early versions of CryptoLocker, thought to be part of a beta testing phase, included code to connect to 184.164.136.134. This IP address is located in a PhoenixNAP datacenter in Arizona, but it was likely under the administrative control of Jolly Works Hosting. As of this publication, this IP address is no longer active, and CryptoLocker samples released since mid-September no longer reference it.

The malware’s network communications use an internal domain generation algorithm (DGA) that produces 1,000 potential C2 domain addresses per day. The domain names contain 12 to 15 alphabetical characters and are within one of seven possible top-level domains (TLDs): com, net, org, info, biz, ru, and co.uk. An error in the algorithm prevents it from using ‘z’ in a generated domain name. The threat actors never registered a domain under the ‘co.uk’ TLD, and Nominet, the official registrar for the ‘uk’ ccTLD, began to sinkhole all potential addresses under this domain on October 18, 2013. As a result, the threat actors cannot use ‘co.uk’ domain names.

The threat actors have also used static C2 servers embedded inside the malware. On October 17, a sample was distributed that first connected to inworkforallthen . com before cycling through the domains created by the DGA. Several days later, another sample was hard-coded to connect to ovenbdjnihhdlb . net prior to attempting other generated domains. Since that time, new samples frequently contain static addresses taken from the pool of domain names created by the DGA.

CryptoLocker cycles indefinitely until it connects to a C2 server via HTTP. After connecting to an attacker-controlled C2 server, CryptoLocker sends a phone-home message encrypted with an RSA public key embedded within the malware (see Figure 2). Only servers with the corresponding RSA private key can decrypt this message and successfully communicate with an infected system.

Analysis of the IP addresses used by the threat actors reveals several patterns of behavior. The first is that the threat actors use virtual private servers (VPS) located at different ISPs throughout the Russian Federation and in former Eastern bloc countries. The extended use of some of these hosts, such as 93.189.44.187, 81.177.170.166, and 95.211.8.39, suggests that they are located at providers that are indifferent to criminal activity on their networks or are complicit in its execution (such as so-called “bulletproof” hosting providers). The remaining servers appear to be used for several days before disappearing. The threat actors could be strategically using this pattern to remain a moving target, or some ISPs could be terminating their service.

A complete list of network indicators is included in the Threat indicators section.

Instead of using a custom cryptographic implementation like many other malware families, CryptoLocker uses strong third-party certified cryptography offered by Microsoft’s CryptoAPI. By using a sound implementation and following best practices, the malware authors have created a robust program that is difficult to circumvent. The malware uses the “Microsoft Enhanced RSA and AES Cryptographic Provider” (MS_ENH_RSA_AES_PROV) to create keys and to encrypt data with the RSA (CALG_RSA_KEYX) and AES (CALG_AES_256) algorithms.

The encryption process begins after CryptoLocker has established its presence on the system and successfully located, connected to, and communicated with an attacker-controlled C2 server. This communication provides the malware with the threat actors’ RSA public key, which is used throughout the encryption process.

The malware begins the encryption process by using the GetLogicalDrives() API call to enumerate the disks on the system that have been assigned a drive letter (e.g., C:). In early CryptoLocker samples, the GetDriveType() API call then determines if the drives are local fixed disks or network drives (DRIVE_FIXED and DRIVE_REMOTE, respectively). Only those two types of drives are selected for file encryption in early samples. Samples since late September also select removable drives (DRIVE_REMOVABLE), which can include USB thumb drives and external hard disks.

After selecting a list of disks to attack, the malware lists all files on those disks that match the 72 file patterns shown in Table 2. Over time, the threat actors adjusted which types of files are selected for encryption; for example, PDF files were not encrypted in very early samples but were added in mid-September. As a result, the list in Table 2 is subject to change.

Each file is encrypted with a unique AES key, which in turn is encrypted with the RSA public key received from the C2 server. The encrypted key, a small amount of metadata, and the encrypted file contents are then written back to disk, replacing the original file. Encrypted files can only be recovered by obtaining the RSA private key held exclusively by the threat actors.

As a form of bookkeeping, the malware stores the location of every encrypted file in the Files subkey of the HKCUSOFTWARECryptoLocker (or CryptoLocker_0388) registry key (see Figure 3).

After finishing the file encryption process, CryptoLocker periodically rescans the system for new drives and files to encrypt.

The malware does not reveal its presence to the victim until all targeted files have been encrypted. The victim is presented with a splash screen containing instructions and an ominous countdown timer (see Figure 4).

The ransom amount varied in very early samples (see Table 3), but settled at $300 USD or 2 BTC (Bitcoins) within the few weeks after CryptoLocker’s introduction. Dramatic Bitcoin price inflation in the latter months of 2013 prompted the threat actors to reduce the ransom to 1 BTC, 0.5 BTC, and then again to 0.3 BTC, where it remains as of this publication.

The threat actors have offered various payment methods to victims since the inception of CryptoLocker. The methods are all anonymous or pseudo-anonymous, making it difficult to track the origin and final destination of payments.

The description of cashU shown in Figure 5 is taken directly from the Wikipedia entryabout the method:

The description of Ukash shown in Figure 6 is largely taken from a Facebook post about the product:

A screenshot of the Paysafecard dialog was not immediately available for this publication, but the description states:

The description of Bitcoin shown in Figure 7 is copied almost verbatim from several online resources:

The description of MoneyPak shown in Figure 8 is copied directly from the MoneyPak website:

Although early versions of CryptoLocker included numerous payment options, the threat actors now only accept MoneyPak and Bitcoin. The Bitcoin option was originally marketed as the “most cheap option” [sic] for ransom payment based on the difference between the $300 USD ransom and the market rate of Bitcoins. From August to December 2013, the Bitcoin market experienced major volatility and dramatically increased in price, negating any monetary benefits for victims to choose this payment method.

The variety of payment options and currency choices in early CryptoLocker versions suggests the threat actors originally anticipated a global infection pattern. For reasons unknown to CTU researchers, the threat actors elected to focus exclusively on English-speaking countries and removed the payment options less popular in these countries.

Anecdotal reports from victims who elected to pay the ransom indicate that the CryptoLocker threat actors honor payments by instructing infected computers to decrypt files and uninstall the malware. Victims who submit payments are presented with the payment activation screen shown in Figure 9 until the threat actors validate the payment. During this payment validation phase, the malware connects to the C2 server every fifteen minutes to determine if the payment has been accepted. According to reports from victims, payments may be accepted within minutes or may take several weeks to process.

In early November 2013, the threat actors introduced the “CryptoLocker Decryption Service” (see Figure 10). This service gives victims who failed to pay the ransom before the timer expired a way to retrieve the encrypted files from their infected system.

The service uploads the first kilobyte of an encrypted file, which contains the header prepended by the malware. The threat actors use that data to query their database for the RSA private key that matches the RSA public key used during file encryption. If the private key is located, the threat actors present the victim with the page shown in Figure 11. The victim is given the option of sending payment to a randomly generated Bitcoin wallet. Early versions of this service charged 10 BTC, but the price was quickly reduced to 2 BTC. After receiving the payment, the threat actors redirect victims to a page that includes instructions on how to decrypt files.

In December 2013, Michele Spagnuolo published a thesis discussing a Bitcoin forensics framework called BitIodine. He discusses identifying Bitcoin addresses controlled by the CryptoLocker threat actors and tracing potential ransom payments made to those addresses. Figure 12 graphs the total number of ransoms paid per day (in gray) along with the total value of those payments in U.S. dollars on the day they were received (in blue).

Using the daily weighted BTC price, if the threat actors had sold the 1,216 total BTC collected over the period shown in Figure 12 immediately upon receiving them, they would have earned nearly $380,000. If they elected to hold these ransoms, they would be worth nearly $980,000 as of this publication based on the current weighted price of $804/BTC.

These figures represent a conservative estimate of the number of ransoms collected by the CryptoLocker gang. Based on conversations with U.S.-based victims, the ease of payment with MoneyPak and the numerous technical barriers to obtaining Bitcoins led to most payments being made through the former method. CTU researchers suspect that a significant portion of Bitcoin payments are being made by individuals outside of the U.S., where MoneyPak is not available and Bitcoin is the only option. Based on this information and measurements of infection rates, CTU researchers estimate a minimum of 0.4%, and very likely many times that, of CryptoLocker victims are electing to pay the ransom.

Based on its design, deployment method, and empirical observations of its distribution, CryptoLocker appears to target English-speakers, specifically those located in the United States. Malware authors from Russia and Eastern Europe, where the CryptoLocker authors are thought to originate, commonly target victims in North America and Western Europe. Law enforcement cooperation between these regions is complicated by numerous factors, which often results in threat actors believing that they can operate with impunity.

CTU researchers observed early infections occurring disproportionately at financial institutions, but anecdotal reports suggest that early victims were in verticals as diverse as hospitality and public utilities. As of this publication, there is no evidence the actors are targeting specific industries. The threat actors have also broadened their attacks to include home Internet users in addition to professionals.

CTU researchers began actively monitoring the CryptoLocker botnet on September 18, 2013 and analyzed various data sources, including DNS requests, sinkhole data, and client telemetry, to build the approximate daily infection rates shown in Figure 13. Spikes coinciding with Cutwail spam campaigns that resulted in increased CryptoLocker infections are clearly indicated, including the period of high activity from October through mid-November. Likewise, periodic lulls in activity have occurred frequently, including a span from late November through mid-December.

The CTU research team registered multiple domains from the pool used by CryptoLocker to construct a sinkhole infrastructure and assess the malware’s global impact. Between October 22 and November 1, 2013, 31,866 unique IP addresses contacted CTU sinkhole servers. Figure 14 shows the geographic distribution of these IP addresses.

The United States was disproportionately represented among countries with measurable infection rates. Table 4 lists countries with the top ten infection rates.

The CTU research team implemented a similar sinkhole infrastructure between December 9 and December 16, which was during a period of limited malware activity. Additionally, recent samples use hard-coded C2 domains, which limits the conclusions that can be drawn from information gathered from sinkhole domains. During this observation period, 6,459 unique IP addresses contacted the CTU sinkhole servers. Figure 15 shows the geographic distribution of these IP addresses.

In the samples gathered by the December sinkhole, the United Kingdom and Australia approached the absolute infection numbers of the U.S, despite having much smaller populations. CTU researchers are unsure whether this change is an anomaly or represents a change in the threat actors’ strategy.

Table 5 lists countries with the top ten infection rates.

Based on the presented evidence, CTU researchers estimate that 200,000 to 250,000 systems were infected globally in the first 100 days of the CryptoLocker threat.

By incorporating the following components in a defense-in-depth strategy, organizations may be able to mitigate the CryptoLocker threat:

CryptoLocker is neither the first ransomware nor the first destructive malware to wreak havoc on infected systems. However, the malware authors appear to have made sound design decisions that complicate efforts to mitigate this threat and have demonstrated a capable distribution system based on the Cutwail and Gameover Zeus botnets. Evidence collected by CTU researchers confirms the threat actors have previous experience in malware development and distribution, especially of ransomware. Based on the duration and scale of attacks, they also appear to have the established and substantial “real world” infrastructure necessary to “cash out” ransoms and launder the proceeds.

To mitigate exposure to the CryptoLocker malware, CTU researchers recommend that clients use available controls to restrict access using the indicators in Table 6. The domains listed in the indicators table may contain malicious content, so consider the risks before opening them in a browser. CTU researchers have attempted to remove IP addresses and domain names operated by security vendors and private researchers, but some non-malicious infrastructure may be included. Date gaps in domain name information represent periods when the threat actors elected not to register malicious domains or when CTU researchers had insufficient data to determine those domain names.