Back in December, Heimdal Security
spotted the Angler exploit kit leveraging drive-by campaigns to infect unsuspecting web users with Cryptowall 4.0 ransomware. The notorious malware has since been spotted in
additional attack campaigns, leading Heimdal to
wonder whether a newer version is on the horizon.
Cryptowall's next installment will no doubt arrive at some point in time. In preparation for this near-inevitability, it is important that we understand the ransomware's current version. We, therefore, turn to
Lastline – an advanced malware protection firm whose researchers recently dissected Cryptowall 4.0 in depth.
In a blog post published on the company's blog, malware research engineer Arunpreet Singh joins Christopher Kruegel, co-founder and chief scientist at Lastline, in examining what makes the ransomware tick.
When Cryptowall is first unpacked, the duo explains, the code peels back several layers in order to reveal the malware payload, which overwrites the PE image memory.
But there is a snafu. Due to an error in locating the correct offset of a section header, it may break automated dumping/unpacking tools as unpacked files will not have a correct PE header, thereby concealing the malware's payload.
Fortunately, Lastline's analysis environment uses memory snapshots, which allows us to detect the overwriting of the PE image and to explore the unpacked malware payload in greater detail.
One of the first things Lastline's research duo noticed about Cryptowall 4.0's unpacked malware payload is a list of hashes it uses to resolve the addresses of all the APIs it needs to call. (One hash corresponds to exactly one API.) This choice of design, as opposed to storing the API names as strings or referring to an import table, enhances the ransomware's ability to conceal itself from antivirus software.
The next step in the infection process involves the code producing a machine identifier
system_info_hash, which computes a MD5 hash of information, such as "ComputerName," "Username," "Number of CPUs," and "Keyboard Layout."
The malware then uses that identifier, along with data regarding the command and control (C&C) network configuration and a hardcoded string, to produce a second MD5 hash
system_info_network_hash. These two MD5 hashes are stored for reference along with information regarding the OS version, the WOW64 status, and whether the current user has administrative privileges.
Once it has completed the setup process, Cryptowall 4.0 injects itself into two processes – explorer.exe and svchost.exe.
The ransomware's activities in explorer.exe are meant to achieve persistence and hide its tracks. Cryptowall 4.0 sets about to achieve these objectives by copying itself to the %AppData% directory, creating a registry entry that enables it to start up at each boot, terminating the primary malware process, and deleting the original file. The malware also disables system restore, shadow volume copies, and removes the previous 1,000 restore points.
As for svchost.exe, Cryptowall 4.0 uses a DecryptNetworkConfig function to decrypt and then decompress a list of C&C servers:
In the meantime, the malware uses a random number to generate a RC4 key, whose characters are sorted for a second RC4 key. This key is used to encrypt the hash identifying the client, the OS make, information regarding whether the processor is running in 32-bit or 64-bit mode, and if the malware is running with administrative privileges. Cryptowall 4.0 then sends this encrypted information to a C&C server.
If the server is up, it will respond with a message that sends the ransomware a public key used to protect another key that scrambles the user's data. The message also includes payment address that the malware can later incorporate into its ransom note.
All that remains at this point is the encryption of the user's files. To complete this process, Cryptowall 4.0 creates a random AES key using local Win32 APIs, which it uses to encrypt both files and filenames.
As information security analyst
Bob Covello notes in a
blog post, the filename encryption feature is a new functionality of Cryptowall that could potentially serve as a canary warning insofar as victims could instantly see their filenames changing in their folders or on their desktops. Victims could exploit this visibility to cut short the encryption process by shutting down their computer, at which time they can enlist the help of an expert to help them restore their affected data. This course of action is not guaranteed, however, and it largely depends on the user's timing.
But back to the encryption process. Once all files and filenames have been encrypted, Cryptowall 4.0 adds metadata to its files, including the hash of the public key and an AES key encrypted with the public key. It then purges the AES key, making local restoration impossible.
Once the victim has paid, they are given access to a private key that was used to encrypt the public key. They can use that private key to decrypt the AES key and, in turn, decrypt their files.
Clearly, Cryptowall 4.0 uses a number of anti-evasion methods to give users as much of a headache as possible. With that in mind, it's important that an emphasis be placed on ransomware prevention.
For tips on how you can prevent a ransomware infection, please click
here.
