Background
CryptoWall is a new and highly destructive variant of ransomware. Ransomware is malicious software (malware) that infects your computer and holds hostage something of value to you in exchange for money. Older ransomware used to block access to computers. Newer ransomware, such as CryptoWall, takes your data hostage. With CryptoWall, thieves use asymmetric encryption, where the decryption key is different from the encryption key and is not stored next to the encrypted data. This forces victims to pay the thief a ransom for the decryption key to unlock the data.
The Problem
Ransomware presents a unique threat. It must be detected and stopped before data is maliciously encrypted, or the data may be lost and become forever unrecoverable. A less optimal approach would be to develop methods of detecting the malware and ways to mitigate or reverse the damage. This blog provides an in-depth analysis of CryptoWall 3.0 (CW3), how it behaves and what it does so that we may better detect and defend against it.
Detection
CW3 is a new malware that is being launched on a global scale. The sample we analyzed was compiled on the 13th of January 2015, and first seen in the wild on the 14th of January, marking the beginning of CW3. SentinelOne technology caught CW3 immediately after its release, but it eluded other anti-virus and anti-malware solutions from companies such as McAfee, Microsoft, F-Secure, Avast, and AVG. The sample in this analysis is a part of the CryptoWall “crypt1” campaign.
Method of Analysis
Our analysis included execution, monitoring and debugging of the sample in a virtualized environment with Internet connectivity, as well as complete static reverse engineering in IDA.
Infection Vector
The latest infection vectors are unclear, though there is evidence that at least some of the samples were transferred via phishing mails with an attached Upatre file, which is a downloader for other malicious files.
Anti-probing
The sample discussed in this analysis (MD5 47363b94cee907e2b8926c1be61150c7) exhibited minor anti-reversing and anti-debugging techniques in the form of junk code, hidden internal PE, and a segment-register modification. Eventually, the dropped payload file (MD5919034c8efb9678f96b47a20fa6199f2) was clean of anti-probing techniques.
Persistence
First, the CW3 malware generates a unique computer identifier by calculating an MD5 hash on the following string:
Next, the malware generates the hexadecimal string representation of the MD5 hash of the above string. This hexadecimal string will be referred to as the CUUID.
The malware then tries to open a new event called /BaseNamedObjects/{CUUID} to make sure it is the only instance running on a system, otherwise it terminates. If it doesn’t terminate, the malware proceeds to calculate the CRC32 of the CUUID, generates the hexadecimal representation of this new result, and finally appends an .exe suffix. This results in a somewhat random filename which the malware stores locally on the victim’s computer.
In short: ToHexString(CRC32(ToHexString(MD5(ComputerDetails)))).exe
CW3 then proceeds to copy that file into the default Startup directory and register it into the Run and RunOnce registry keys (under HKLM or HKCU, depending on whether it’s running as administrator or not).
In contrast with CW2, where the file name was merely the CUUID, CW3 adds the CRC32. However, as with CW2, the persistence methods are erased once the malware finishes its job and it uninstalls itself.
Preparation
Before starting its intended task, and even before persisting on the system, the malware spawns a new suspended explorer.exe process, allocates some memory inside it, and writes a designated code section into the process. It creates a remote thread and calls NtResumeThread on it. Once it is running as explorer, it performs the actions described in the above persistence routine, and starts downgrading the host system’s security. It begins by patching RtlQueryElevationFlags to prevent the UAC elevation dialog for certain actions (technique described in detail here.)
The malware calls WinExec(“vssadmin.exe Delete Shadows /All /Quiet”), which deletes “shadow copies” (automatic filesystem snapshots that Windows routinely takes for you with the Volume Snapshot Service).
It calls WinExec(“bcdedit /set {default} recoveryenabled No/code>”), which disables Startup Repair from automatically booting when there is a problem.
It calls WinExec(“bcdedit /set {default} bootstatuspolicy ignoreallfailures”), which disables windows error recovery on startup.
The malware stops the following services, and changes them so they do not begin on startup:
Wscsvc | WinDefend | Wuauserv | BITS | ERSvc | WerSvc
Deletes the registry key
HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run.Windows Defender – to prevent Windows Defender from starting automatically on system boot.
;Deletes the registry key HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/ShellServiceObjects/{FD6905CE-952F-41F1-9A6F-135D9C6622CC} – used to disable the security center notifications And finally, writes HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/SystemRestore.DisableSR = “1” – to disable System Restore.
Main Payload
A “svchost.exe –k netsvcs” is spawned, suspended, and injected with a thread executing the main payload, which performs the rest of the malware’s work.
The sample needs a key to encrypt the files, and it contacts the home server to request one. The communication and encryption CW3 uses are similar to, but different from CW2.
First, CW3 generates a 10-15 character long random alphanumeric string, and uses the sortedversion of it as an RC4 key for the message it is about to send, an introduction message for the server:
{7|CAMPAIGN_IDENTIFIER|CUUID|1}
(in CW2 the “1” at the end is a “4”)
The key will also be used to decrypt the server’s reply. Next, the malware needs to find a home server to contact. It keeps a very short, hard-coded list of i2pproxies – “proxy1-1-1.i2p” and “proxy2-2-2-.i2p” (newer samples have more proxies – up to “proxy5-5-5.i2p”). This utilization of i2p is new in CW3. While i2p is similar to Tor, it has numerous architectural and design differences; the most relevant difference is Tor’s central-oriented directory listing versus i2p’s peer to peer, dynamic listing.
CW2 used a few “Tor to web” services to bridge the gap between Tor-only sites (such as those used to pay ransom) and victims’ non-Tor computers that couldn’t access these sites unless they installed the Tor client. However, censors blocked CW2 from using those bridging services once its usage of them became known. i2p is harder to detect and block, as it’s not kept in a centralized location. In addition to using i2p proxies, CW3 also keeps a short, hard-coded and RC4-encrypted list of IP and port pairs, which it decrypts using the hard-coded key “6hehbz4fp” into the following list:
The malware then connects to the chosen endpoint and makes an HTTP request for the proxy name, with the object name being the unsorted RC4 key. The content of the HTTP request is “(last letter of sorted RC4 key)=(RC4 encrypted message)”. It looks like this:
The server’s RC4-encrypted reply includes the infected computer’s two letter country code, the victim’s unique payment page, and the public key that the server generated for this victim.
The country code undergoes CRC32 and is matched against a table of “forbidden” country code hashes. If matched, the virus immediately uninstalls itself and terminates. In CW2, this contained four forbidden countries: RU, BY, KZ, and UA (for Russia, Belarus, Kazakhstan and Ukraine, respectively). CW3 adds a fifth forbidden entry “AM” for Armenia.
CW3 then unpacks a lot of internally stored HTML files, all of them identical except that each one is in a different language, and tries its best to match the country code of the victim with the right language.
These HTML files are the “your files have been encrypted” message.
The malware calculates the MD5 hash of the server’s public key and sends it back to the server using a new RC4 key, in the following format:
{7|CAMPAIGN_IDENTIFIER|CUUID|2|Hex Representation of Hash}
The response from the server contains a user-unique PNG file, effectively a splash-screen for the ransomware.
It appears that some leftover debug code was inserted into this first variant, as the malware attempts to save the PNG into C:/out.png:
This second message (and reply) did not appear in CW2. Finally, CW3 begins the encryption process, iterating over all letter drives in the system (except for CD drives) and recursively encrypting all files with specific suffixes. The malware excludes certain directories and specific files, but the encrypted files list has expanded greatly from CW2 to the following in CW3:
Note that these suffixes represent only 311 out of 312 suffixes. The last one is probably a unique long suffix (like the above db-journal).
The encryption process has changed from CW2 to CW3. CW3 starts the same as CW2 by creating a file with the same name as the target file, adding a random alphanumeric suffix, reading the content of the target file and encrypting it into the temporary file, then renaming the temporary file to overwrite the target file.
However, unlike CW2, instead of using the server’s public key for encryption, in CW3 a local AES-256 key is generated using Windows API and used for all encryption purposes. The header of each encrypted file has also changed, and is now composed of the 16-byte MD5 hash over the server’s public key, followed by the AES-256 key encrypted by the server’s public key. In this way, CW3 took a big performance leap by using symmetric encryption and only encrypting the symmetric key with the public key.
Every file encrypted is saved in the registry under HKCU/Software/(CUUID)/(sorted 2nd half of CUUID)/(FullFilePath) = (Volume Serial Number)
The final message reports the number of encrypted files to the server:
{7|CAMPAIGN_IDENTIFIER|CUUID|3|all=###}
After the server sends it “1” as a response, it uninstalls itself, cleans various temporary registry values it saved except for the list of encrypted files, and terminates itself.
Lessons Learned
In order for any ransomware to be successful, the victim’s data must be manipulated. Backups must be deleted. Regardless of the method used, the end result is that the data will be altered, and backups corrupted or deleted. The damage is detectable by calculating the entropy of a file before and after the malware manipulates it, by checking the header of a file, detecting repetitive access to files that weren’t owned by the reading process, and also by checking system backups for integrity. The common malware ploy of spawning an additional process (in this case explorer or svchost) and subverting it by injection can be detected, and can be used to militate against a large percentage of malware infections.
The detection mechanisms present in SentinelOne on endpoints enabled us to immediately identify CW3 on day one. Even though the new malware was re-packed several times, and even though the code and behavior were different from previously seen samples, the new CW3 ransomware did not elude SentinelOne’s dynamic behavior analysis and machine learning detection engine.
As of today (Feb. 3, 2015) companies mentioned above are now able to detect CW3, as they have updated their signature databases. SentinelOne, however, needed no update in order to protect our customers from this new strain of CryptoWall, and it is capable of detecting as yet unknown strains of ransomware.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.
