CryptoWall, a well known piece of ransomware, has been plaguing networks since at least early 2014. In November of 2015, news of the latest variant, CryptoWall 4.0 broke, but the samples found seemed identical to CryptoWall 3.0 in terms of how the malware communicated with its Command and Control servers. However, in recent weeks we've discovered that this is not the case. In fact, CryptoWall 4.0 has changed its network communications--potentially breaking existing detection methods and making analysis difficult for security practitioners.

I wanted to share our findings on this blog, including a Python script for decrypting the parts of the network communications that have changed, as well as a list of known domains that are being used for Command and Control from the sample we studied. Our hope is that this new information will help others combat this particularly insidious piece of ransomware.

Recently, we investigated network traffic from a host infected with a CryptoWall 4.0 variant. The user was browsing a well known hotel chain's web page that contained a section listing a number of links for attractions in the area. One of these links led to a website that had been compromised and contained an Angler Exploit Kit (EK) redirect. After being redirected to the Angler EK, the host was successfully exploited and installed a CryptoWall 4.0 variant. Within approximately twenty seconds of visiting the compromised website the malware had been installed and was calling out for the additional information needed to begin the encryption process. Approximately 15 minutes later, the encryption process was complete and the user received the message informing them their data had been encrypted and could only be decrypted by paying a ransom.

Although the computer was successfully compromised, having full PCAP from the host, which our Cloud Network DVR recorded, made it possible to quickly reveal the initial infection vector, an important step when assessing the scope of a particular threat on a given network. Additionally, the traffic showed a change in network communications from other known CryptoWall variants, another important step in the detection process.

There have been a number of articles and blogs describing the network communications of CryptoWall 3.0 and CryptoWall 4.0. The malware communicates via HTTP and contains strings in the bodies of POST requests and server responses. These strings are hexadecimal and represent encrypted data sent by the malware. The data is RC4 encrypted using a key that can be found in the URL. The key is 10 - 15 alphanumeric characters long and is randomly generated for new HTTP connections. To decrypt the data, the key must be sorted low to high from how it appears in the URL. However, the traffic we found did not decrypt properly and some requests contained hexadecimal strings that were an odd number in length. Early CryptoWall 4.0 research suggested the network communications were identical to CryptoWall 3.0, but this sample contained a tweak in the obfuscation of the traffic; either additional characters were added to the string or subtracted from it.

Reversing network encryption methods can be very difficult and is typically done by conducting in-depth analysis of the sample. CryptoWall 4.0 has a number of anti-debugging techniques, making the option of analyzing the sample less appealing, however since previous CryptoWall variants have similar looking network traffic, it seemed plausible to deduce the changes from the captured PCAP. Figure 1 below shows what the initial POST request looks like from the sample we studied.

cryptowall-4.0 Blog Post Fig 1.png

Figure 1: CryptoWall 4.0 variant initial request

Examining the hexadecimal string in the initial POST request, it appeared that the beginning of the string did not look as random as a typical hexadecimal representation of encrypted data should. Notice in Figure 1 the large amount of numeric characters at the beginning of the string, suggesting the data may not be as random as the output from the RC4 cipher. Doing a simple brute force of subtracting characters two at a time (one character initially, if the total length was odd) and checking the output, using the same method to derive the key as previous variants, revealed the string had been padded from the front. It would be unusual for the Command and Control server to brute force the string to decrypt the data, so there was likely something in the request that indicated how much padding the data contained. After examining multiple requests it became apparent the RC4 key contained this information. The sum of the numeric digits in the key is equal to the number of characters to trim from the beginning of the hexadecimal string. Figure 2 contains a Python script that may be used for decrypting these padded strings.

import binascii

        def rc4(data, key):
            j = 0
            s = range(256)
            for i in range(256):
                j = (j + s[i] + ord(key[i % len(key)])) % 256
                s[i], s[j] = s[j], s[i]

            out = ''
            i, j = 0, 0
            for c in data:
                i = (i + 1) % 256
                j = (j + s[i]) % 256
                s[i], s[j] = s[j], s[i]
                out += chr(ord(c) ^ s[(s[i] + s[j]) % 256])
            return out

        def decode_hex_string(key, hex_string):
            padding_index = sum([int(e) for e in key if e.isdigit()])
            print rc4(binascii.unhexlify(hex_string[padding_index:]),\


Figure 2: Sample Python script for decrypting CryptoWall 4 request containing padding

Interestingly enough, we only observed this padding behavior in the initial HTTP requests. Responses from the server did not attempt to pad the data they sent. Why is this the case? The decrypted data in the initial HTTP request didn't contain any particularly sensitive information (Figure 3), however the malware will only work if it receives a payload from a Command and Control server containing a public encryption key as well as other information unique to the host. A simple change to the beaconing behavior may indicate attempts to evade existing network detection techniques, in particular those that would block these types of requests.


Figure 3. Decrypted output from Figure 1

Regarding detection, the samples we saw follows a pretty regular pattern. These are HTTP POST requests to a ".php" resource. The ".php" is preceded by six alphanumeric characters of both uppercase and lowercase ([A-Za-z0-9]{6}). The ".php" is followed by a query string containing a single variable which is a random lowercase character [a-z]{1} followed by the RC4 key which contains 10 - 15 characters, alphanumeric, lowercase only ([a-z0-9]{10,15}). The resulting regular expression looks like:

POST /[A-Za-z0-9]{6}.php?[a-z]{1}=[a-z0-9]{10,15}

The POST body contains the hexadecimal string mentioned above in a variable that is a single lowercase character. This character matches the last non-numeric character in the RC4 key before sorting. Hexadecimal strings have ranged from 113-143, however some lengths outside of this range should be expected.

CryptoWall is a difficult threat to deal with as it can quickly accomplish its objectives within a matter of minutes. To stop this threat it must be prevented from being installed or denied the ability to make its initial communication with one of its Command and Control servers. While this is not a trivial task, we hope the information about its network communications can be helpful in blocking the communications. Additionally, the command and control servers from the sample we examined (md5: 3abba64ff7043510d5a3c211c80bb749) can be found in Figure 4 below.

Figure 4: Command and Control domains used in CrypoWall 4 sample (md5: 3abba64ff7043510d5a3c211c80bb749)

Wei Ding, Data Scientist and Tom Hegel, Threat Researcher at ProtectWise contributed integral research to this blog post.


Yonathan Klijnsma (@ydklijnsma on Twitter), Senior Threat Intelligence Analyst from Fox-IT provided us with some valuable insight in regards to the absence of padding from the server responses. The domains listed act as proxies between the victim and the actual Command and Control server. The padding is stripped by the proxies as the real Command and Control server speaks the original protocol. For an in-depth history of CrypoWall's evolution check out his slides from his talk at Botconf 2015 at

Next blog post