CryptoDefense: The Ransomware Games have begun

If you see a text and / or HTML document on your Desktop called HOW_TO_DECRYPT with the following contents: then you were unfortunate to be a victim of another crypto-ransomware. Recently, several of our field engineers encountered this piece of ransomware encrypting files on victim machines. This new ransomware is being distributed via Java drive-by-downloads and it’s likely that more victims could be targeted with this new attack vector. We were able to capture the sample inside a micro-VM implemented in our product so we have all the files and traffic involved in the attack. This allows us to skip the Java exploit and 1st layer dropper for now and focus on the actual malware dropped. If we find something noteworthy in other parts of attack we’ll post a follow up article.

Infection scenario and comparison to Cryptolocker

This is quite a complex infection workflow, but interestingly it doesn’t require any privilege escalation. Instead of writing code to the existing process it creates a new one (say, svchost.exe) so that it runs with the same privilege level. Thus it can write data into the created process memory, create threads etc. This piece of malware appears to be a competitor of Cryptolocker. There was an article published a while ago by Symantec explaining how to use Windows shadow copies and system restore to recover the files affected by Cryptolocker. In the case of CryptoDefense this won’t work. It makes sure system tools cannot recover the files – the shadow copies are removed and system restore is disabled. According to another report by Symantec the CryptoDefense first showed up at the end of February 2014 (this is when the first BitCoin transaction was made). It appears that by the end of March there were at least 11 000 detections (the real picture might be bigger already) and $34,000 were earned by the gang behind this. In contrast Cryptolocker has made millions of dollars already (around $27 million reported late last year). So clearly, underground gangs are warming up to the idea of crypto-ransomware and we expect similar ransomware to come up. The Symantec report says that the malware was distributed via spam dissemination. But in our case it was a drive-by-download attack. Interestingly Cryptolocker was also reported to be spreading by spam email letters or installed by bots on the already infected systems (here, here and here). However there’s no evidence that drive-by-download attacks were not involved as well. Now this version seems even more plausible since it’s one of the ways Crypto Defense gets on the machines. Before getting to the analysis of the sample let’s compare Cryptolocker and Crypto Defense.

* This flaw almost certainly will be fixed in the next update of the malware, since it’s widely discussed and reported in several security related blogs. Some details on how to decrypt your data can be found here.

Interesting details about Cryptolocker versions 1 and 2 can be found in the ESET blog article. Now let’s look at the implementation details of the sample we acquired. MD5: 5b855b96822a1d9e0bbabc5610769308

Analysis of second stage dropper

The second stage dropper stores the payload in the code section as a sequence of instructions populating stack array as pictured below. The following snippet shows how the de-obfuscated payload is called.

After that it “brute-forces” the JPEG resource by id. The ID of the resource is actually 53. Interestingly this payload sometimes executes the following sequence: This might be a way of making a random length delay. It could be used as an anti-emulation/tracing technique aimed at AV emulators. There’s also an interesting anti-debugging/emulation technique: segment register manipulation. Olly or Immunity Debugger cannot process the following code snippet correctly:

The code above jumps to yet another de-obfuscated piece of code, which on its turn launches a copy of the calling process (i.e. the second stage dropper) and replaces its image with the final payload. It starts the process in a suspended state and calls ZwUnmapViewOfSection, and then it allocates the memory in the created process and writes down the unpacked payload. Finally it calls ResumeThread. Now explorer.exe is running the malicious code.

Scratching the surface of Crypto Defense

From this point the style of code changes and we can assume that up to this moment it was one big dropper. The final executable is well obfuscated, doesn’t have any imports and almost no strings. API calls are resolved at run time and strings are stored in the code section. So it requires a bit of work before we can get to static analysis. First, we need to resolve all the API calls. The addresses of the functions are resolved by CRC32 and stored in the array or a structure. The get_proc_addr_by_CRC32 gets a handle to a DLL and iterates through its export table looking for the function name with the matching CRC32 hash value (passed as the second argument). The address of the function is then written to the corresponding offset of the global array (or structure) IAT. This is good because we can look the IAT up in the debugger after it’s populated. Let’s see how our Trojan calls the function:

GetIAT simply returns the address of IAT array. Clearly there’s a pattern here and we can throw together a script to comment the code for us and list all the cross-references to the API functions (the IAT array is shortened here to save space, you can find the full version at the end of the article).

[code language=”python”]
# IAT as it was looked up in the debugger

IAT = [

‘ntdll.ZwClose’,

‘ntdll.LdrLoadDll’,

‘ntdll.LdrGetProcedureAddress’,

‘ntdll.ZwAllocateVirtualMemory’,

‘ntdll.ZwFreeVirtualMemory’,

…

‘GDI32.CreateCompatibleDC’,

‘GDI32.CreateCompatibleBitmap’,

‘GDI32.GetDeviceCaps’,

‘gdiplus.GdipGetImageEncoders’,

‘gdiplus.GdipSaveImageToStream’
]

# Address of the getIAT function
GET_IAT_FUNC_ADDR = 0x401A00

# Cross reference count
xrefs = {}

# Iterate through all the cross-references to getIAT
for addr in CodeRefsTo(GET_IAT_FUNC_ADDR, True):
# Get next instruction mov reg32, [reg32+offset]
next_inst = NextHead(addr, addr+100)

# Get the offset in bytes
val = GetOperandValue(next_inst, 1)

# Get the offset in array
iat_offset = val/4

# Resolve function name
func_name = IAT[iat_offset]

# Comment the address where the IAT entry was accessed
MakeComm(next_inst, func_name)

The most interesting thing about the IAT is that it has we couldn’t find any cross-references to the CryptDecrypt function. It appears that this particular application is incapable of decrypting files. Perhaps another module is responsible for it. Finally we need to decode the strings that are stored in the code section. In malware analysis data is often much more important than code so it would be great to have a list of strings and cross-references before diving into in-depth analysis. The strings are initialized in one of two ways depicted below: Again there is a clear pattern, which allows for the decoding of strings (if not then we can handle the outliers manually later). Here’s the script to output the strings and addresses where they are initialized:

The list of strings can be found in the Appendix section at the end of the article. The good thing about this approach is that we can see all the crucial elements of the malicious workflow such as structure of HTTP requests to C&C and what information is collected from the victim machines. Crypto Defense stores CRC32 hashes of the file extensions it’s after. We ran a simple brute force script checking the extensions of size up to 5 characters:

We’ve got 137 out of 142 file types hardcoded in the binary. So this Trojan tries to encrypt pretty much everything starting from documents, source files to certificates and databases. Interestingly it doesn’t seem to care about archives. Now we can correlate the results of dynamic and static analysis and sum up the activities of the Trojan:

Connecting to C&C located (allegedly) on one of the hard coded IP addresses

Given that there are file system I/O operations and crypto related DLLs, the nefarious claim in the HOW_TO_DECTYPT file is true.

Finally almost in every folder (Documents, User home directory, etc.) several files named HOW_TO_DECRYPT are created. The text comes from C&C, which means that it can be different on each victim machine.

Payment Web Site

Unlike Cryptolocker, this malware requires a user to visit their personal page on the CryptoDefense web site. The service seems pretty good so far – a number of languages available. This also tells us that the country-wise attack surface is pretty big. Turns out we failed to pay in time (although no deadlines were given), so now we need to pay 1000 USD/EUR (it’s unfair given the dollars-euro exchange rates!). An interesting feature of the “service” is decrypting one file for free: Since we captured this drive-by-download malware sample inside a Bromium microVM, it was isolated from the actual user data. So no damage was done to the end user and nothing really was encrypted; so we didn’t really try out this feature.

Conclusion

The rate of new crypto malware attacks seems to be increasing. It appears to be a profitable business for the underground crimeware gangs. With the widespread success and proliferation of such ransomware, it’s obvious that traditional approaches to end user security are failing to offer countermeasures against this kind of threat. It is worth considering Isolation based security technologies that put a barrier between your real host computer, and this any malware of this nature. If you’re trying to fight this threat using legacy security technology, may the odds be ever in your favor!