Threat Spotlight: CRYPTOWALL 4 – The Evolution Continues

EXECUTIVE SUMMARY

Over the past year, Talos has devoted a significant amount of time to better understanding how ransomware operates, its relation to other malware, and its economic impact. This research has proven valuable for Talos and led the development of better detection methods within the products we support along with the disruption of adversarial operations. CryptoWall is one ransomware variant that has shown gradual evolution over the past year with CryptoWall 2 and Cryptowall 3. Despite global efforts to detect and disrupt the distribution of CryptoWall, adversaries have continued to innovate and evolve their craft, leading to the release of CryptoWall 4. In order to ensure we have the most effective detection possible, Talos reverse engineered CryptoWall 4 to better understand its execution, behavior, deltas from previous versions and share our research and findings with the community.

For readers that may not be familiar, ransomware is malicious software that is designed to hold users’ files (such as photos, documents, and music) for ransom by encrypting their contents and demanding the user pay a fee to decrypt their files. Typically, users are exposed to ransomware via email phishing campaigns and exploit kits. The core functionality of CryptoWall 4 remains the same as it continues to encrypt users’ files and then presents a message demanding the user pay a ransom. However, Talos observed several new developments in CryptoWall 4 from previous versions. For example, several encryption algorithms used for holding users’ file for ransom have changed. Also, CryptoWall 4 includes a new technique to disable and delete all automatic Windows backup mechanisms, making it almost impossible to recover encrypted files without having an external backup. Finally, CryptoWall 4 has been observed using undocumented API calls not previously used to find the local language settings of the compromised host. These are just a few of the new findings Talos observed in the new iteration of CryptoWall that are detailed further in this post.

For our technically savvy users, we encourage you to continue reading. As always, we strongly encourage users and organizations to follow recommended security practices and to employ multiple layers of detection in order to reduce the risk of compromise. Our in-depth analysis of the latest CryptoWall version gives us a better opportunity to protect our users by allowing us to identify better detection methods. Finally, as a note regarding recent statements by the FBI informing users that they should just pay the ransom if they have no alternative, Talos strongly encourages users to not pay the ransom as doing so directly funds this malicious activity.

The adversaries behind CryptoWall 4 are using phishing and drive-by-download campaigns to distribute their malware to their victims. Once CryptoWall 4 has been successfully executed, the dropper downloads an RSA public encryption key from the command and control (C2) server. All files are encrypted with a temporary AES encryption key, which is later encrypted with the downloaded RSA public key and embedded in the encrypted files. Then it shows its message in three different formats. The first is a text file, the second is an image (.png format) and thirdly an HTML document. All are automatically opened on the victim’s desktop as shown in Figure A.1 below. Figure A.2-5 are showing the full text of the HTML document.

One interesting observation with CryptoWall 4 is if it cannot retrieve the public RSA encryption key from the C2 server it will enter a loop constantly attempting to download the public key. As long as the key cannot be obtained, CryptoWall will not “harm” the victim’s computer. Talos also observed that this sample exhibited some additional safety checks, such as terminating the infection process if the local language is not supported. The following is a non-exhaustive list of some of the unsupported languages:

All functions starting from “Delete all shadow copies” in the above diagram are executed from the CryptoWall 4 code injected in the svchost host process. Injection into this process is increasing the privileged level of access to the compromised machine; this allows the deletion of all available shadow copies without the end user being prompted with the UAC (User Account Control) dialog to ‘Approve’ the deletion if the user has administrator level access rights.

// Generate a random value

DWORD GenerateRandValue(int min, int max) {
    if (min == max) return max;
    // Get the random value
    DWORD dwRandValue = RtlRandomEx(&g_qwStartTime.LowPart);
    DWORD dwDelta = max - min + 1;
    dwRandValue = (dwRandValue % dwDelta) + min;
    return dwRandValue;
}
// Generate a Random unicode string
LPWSTR GenerateRandomUString(int minSize, int maxSize) {
    DWORD dwStringSize = 0;             // Generated string size
    DWORD dwNumOfDigits = 0;            // Number of number letters inside the string
    LPWSTR lpRandString = NULL;         // Random unicode string
    // Generate the string size, and alloc buffer
    dwStringSize = GenerateRandValue(minSize, maxSize);
    lpRandString = new TCHAR[dwStringSize+1];
    for (int i = 0; i < (int)dwStringSize; i++) {
          DWORD dwLetter = 0;                       // Generated letter
          dwLetter = GenerateRandValue(0, 1000);
          dwLetter = (dwLetter % 26) + (DWORD)'a';
          lpRandString[i] = (TCHAR)dwLetter;
    }
    // NULL-terminate the string
    lpRandString[dwStringSize] = 0;
    // Now insert the digits inside the string
    DWORD dwUpperHalf = GenerateRandValue(dwStringSize / 2, dwStringSize);
    dwNumOfDigits = GenerateRandValue(1, dwUpperHalf);
    for (int i = 0; i < (int)dwNumOfDigits; i++) {
          DWORD dwValue = 0, dwPos = 0;       // Generated value and position
          dwValue = GenerateRandValue(0, 9) + (DWORD)'0';
          dwPos = GenerateRandValue(0, dwStringSize-1);
          lpRandString[dwPos] = (TCHAR)dwValue;
    }
    return lpRandString;
}
// Generate a random file name starting from a file full path
BOOLEAN GenerateRandomFileName(LPWSTR lpFileFullPath, LPWSTR * lppNewFileFullPath,
 LPWSTR * lppOrgFileName) {
    LPWSTR lpRandFileName = NULL;         // New random file name (without extension)
    LPWSTR lpRandExt = NULL;              // New random file extension
    LPWSTR lpNewFileName = NULL;          // The new file full name
    DWORD dwSize = 0;                     // size of the new filename
    // Check the arguments
    if (!lpFileFullPath || !lppNewFileFullPath || !lppOrgFileName)
          return FALSE;
    // Generate the new file name (without extension)
    lpRandFileName = GenerateRandomUString(5, 10);
    // Generate the random file extension
    lpRandExt = GenerateRandomUString(2,5);
    // Combine the new file name and extension and generate the final new file path
    // ....
    dwSize = wcslen(lpRandFileName) + wcslen(lpRandExt) + 1;
    lpNewFileName = new TCHAR[dwSize+1];
    swprintf_s(lpNewFileName, dwSize+1, L"%s.%s", lpRandFileName, lpRandExt);
    // ....
}

The new file is created, a new AES-CBC 256 key is generated using CryptGenKey and CryptExportKeyWindows Crypto APIs. This 32-byte key will be used to encrypt the entire file.

At this point CryptoWall 4 does a smart thing: it encrypts the generated AES key using the RSA-2048 public key (256 bytes in size) received from the C&C (using CryptEncrypt API). This will produce an encrypted 256-bit stream decryptable only by the bad guys.

The MD5 hash of the public RSA-2048 key is written in the first 16 bytes of the encrypted file; then CryptoWall 4 writes the 256-bit encrypted stream. The original file attributes and size are written to the next eight bytes. The original file name is encrypted using the generated AES key and written with its size inside the new file.

At this point the real file content encryption takes place, the original file is read in blocks that are 512 KByte chunks. Each block is encrypted with the generated key, using an AES-CBC 256 algorithm, and written directly to the new file (together with the block size in the first four bytes).

Once completed all the CryptoWall 4 resources are released and the original file is now deleted in an interesting manner:

// Move the new encrypted file name in the old original position, replacing the old one

bRetVal = MoveFileEx(newEncFileName, lpOrgFileName,
MOVEFILE_WRITE_THROUGH | MOVEFILE_REPLACE_EXISTING);
if (!bRetVal)
// Delete the old file in the standard manner:
    DeleteFile(lpOrgFileName);
else {
    // Rename the original replaced file in the new random file name
    bRetVal = MoveFileEx(lpOrgFileName, newEncFileName, MOVEFILE_REPLACE_EXISTING);
}

As you can see from the pseudo code above, the sectors used for the original clean file are specifically overwritten on the hard disk to ensure that any potential data recovery process is difficult. This is an interesting and novel method used by the malware author to ensure the highest chance of payment; reducing the ability to recover lost files is beneficial to their business model. Figure J below shows how the encrypted file is composed:

CONCLUSION

In this analysis we have put CryptoWall 4 under the microscope. The dropper doesn’t bring anything terribly innovative, but it still has some clever features. The weak point in the infection process is that it deeply relies on the C2 server communication. If a firewall or IPS is able to detect and block its communication packets, the infection will not be able to operate correctly because it doesn’t have any public key needed to properly encrypt the victim files. However, once CryptoWall 4 has encrypted the victim’s files, there is no known way to recover the private key and decrypt them without paying the ransom as the RSA private key is never managed by the victim’s workstation. The private key resides only on the adversaries’ infrastructure.

As our analysis shows, the adversaries behind CryptoWall have continued to innovate and evolve to ensure it remains effective against users. Addressing the overall threat that ransomware presents requires organizations to be aware that adversaries will continue to evolve. Utilizing a multi-layered defensive approach will help organizations be able to detect and protect against threats like CryptoWall. Talos will continue to monitor CryptoWall as it evolves to identify better detection methods and build better defenses to protect our customers. We strongly encourage users and organizations to follow recommended security practices, such as installing security patches as they become available, exercising caution when receiving messages from unknown third-parties, and ensuring a robust backup solution is in place. These practices will help reduce the threat of a compromise and should aid in the recovery of any such attack.

PROTECTING USERS

IOC DETAILS

You can find a downloadable copy of these IOCs here.