How we (almost) defeated DirCrypt

Translation of an article from the company Check Point's Malware Research Team.

DirCrypt is one of the worst types of Malawary money extorting money. It does not just encrypt all found user files, demanding a ransom for decrypting them, but remains in the system, picking up and encrypting the files saved by the user on the fly. After its appearance, work on the computer turns into a torment.
')
Victims of such malware are usually recommended to restore files from an early backup. But if there is no such backup, we face a difficult choice - to accept the loss of data or pay the attacker. However, we (Check Point's Malware Research Team) managed to find a way to recover almost all data in the case of DirCrypt, taking advantage of its weak points in the implementation of encryption.

A typical victim of DirCrypt learns about the attack only on the fact of its commission. Malvar combing hard drives in search of documents, images and archives. After that, the line ".enc.rtf" is added to the name of the files found. If you try to view their contents in “raw” form - you will not see a trace of old data. And after opening this file as an RTF document, you will be presented with instructions on how to pay the money to the scammer.


File system before file encryption


File system after file encryption

Here we begin our investigation. The disassembled code of the program is confused and obfuscated, and we have to find in it the code that performs the encryption. Since the suffix ".enc.rtf" is added to each processed file, it is possible to make a logical conclusion that somewhere in the region of the encryption functions we will see a link to this line. But after a cursory inspection at Hex-Rays' IDA-Pro, we find that most of the strings and the binary are obfuscated. Thus, we face the first task: to decipher these lines.

One way to search for encrypted strings is to simply examine all sections for the presence of a block of seemingly random data at first glance. After that, you need to find a function with a cross-reference (DATA XREF) to this piece of binary data. If an index is placed in this function that is in certain limited limits, then we have found what we were looking for.

It turned out to be quite easy to find the area with encrypted data - it is a big chunk in the .data section.


Encrypted strings

Having studied the cross-references to this data block, we learn that several functions access it, one of which is called 170 times in the code. Turning directly to the places of its call, we see that in it the first parameter is the index. Bingo, we caught you!

The code itself for decoding strings is quite long and complicated. Since our goal is to decipher the lines as soon as possible, we did not reverse this algorithm, but wrote a small script for Windbg, which did the hard work for us:

.while (@$t0 < 0xe1) { .printf “\n%02x”, @$t0; r eip = 0x40456a; p; p; p; eb esp @$t0; p; du @eax; r $t0 = @$t0 + 0x01 } 

This code in the loop calls the decryption function, passing in turn the index values ​​from the range, and the decoded lines themselves are output to the terminal window.


Sample output of decoded windbg strings

Now we need to transfer the received lines to IDA-Pro for the convenience of static analysis. We decided to include them in the text as comments in the places where they are used. To do this, IdaPython wrote a small script that accepts a file (“strings.txt”) with a Windbg output dump and inserts strings where the function is being called to decrypt them. Now we can quickly navigate through cross-references to strings of interest from the DecryptString dialog.



Now in the table of such links we find ".enc.rtf" and find that it is used only in one place. Since the suffix is ​​added to files after encryption, we can safely assume that we are close to the code that executes it.

The code for the function that refers to ".enc.rtf" is pretty obvious, and IDA-Pro did some of the work for us, correctly defining its argument as a file name. At the beginning of the function, another function is called, after which the ".enc.rtf" suffix is ​​received and decoded, and then the file is renamed. That is, it is clear that the encryption process itself takes place before renaming in that very first function.

Having moved to it, we find a volume code with a repeating pattern: data is read from the file by chunks, which are then changed and written back to the file. This is the classic behavior of crypting functions, so you can be sure: we found what we were looking for. Now the fun begins.


External wrapper function that performs encryption

The malware in the loop reads chunks of the contents of the file, encrypts them in memory and writes them at the same offsets, erasing the previous data.


Encryption loop

Climbing a little deeper, we understand that there are actually two encryption functions. The first is called for each chunk of read data and thus encrypts the entire file. As an argument, a pointer to the object, the data for which is created in the second function, is passed to this function. An experienced eye will recognize here the initialization of the S-box RC4 algorithm.

Encryption is performed for each file separately, and the S-box initialization is performed with the same key for each file.


Initialization and operation of the RC4 algorithm

If you have ever seen bloopers in cryptography, here you just can not believe your eyes. And since the S-box is constantly reinitialized, then the same key stream is used for each file. It remains for us to take the final step: if we know the original contents of the encrypted file on the victim's computer, then to obtain the key stream, we need to perform a XOR operation between original and encrypted data, byte-by-bye.

OK, we need to find the file that is guaranteed to be on the Windows file system. These are, for example, standard images for the desktop background. Their size is about 100 Kb, so that, without spending much effort, we can get a keystream of the same size.

And only this thought flashed through our heads, as the following code rushed into our eyes:


Supplement RC4 key to the end of the encrypted file

Having picked up the jaw from the floor, we begin to pity the author of this unfinished Malvari seriously. Probably confused about where to save the key, he somehow decided to append it to the end of the file, where everyone can find it. For some reason, this idea seemed to him suitable.

This is also beneficial for us: now we can use the same RC4 to completely decrypt the file.

But wait. Here we have another problem: not only RC4 is used to encrypt files.


Encryption of the first 1024 bytes of RSA

The first chunk of 1024 bytes is encrypted using the RSA algorithm. Inside the file, the private key is not saved, so one of the ways to obtain it is to pay money to the attacker in exchange for the key. Assuming that we will not pay the money (and we will not attack the key issuing server), the only way out is to save everything except the first 1024 bytes.

In some cases (depending on the format of the file being restored) this task can be successfully solved. Let's take a standard .doc file for example. In it, starting at offset 0x1A00, is the text of the file in unicode. Let DirCrypt encrypt our experimental file and compare its contents “before” and “after”:


Experimental document created in Microsoft Word


Document in hex editor before encryption


Document in hex editor after encryption

In the case of .doc files, we wrote a simple Python script that extracts the RC4 key, decrypts the file with it (except for the first 1024 bytes) and saves the text in ASCII. By running it for our experimental file, we were able to completely recover the text of the document.


Extracted text

Afterword

In this article, we talked about tricks that will help you find vulnerabilities in crypto-mall. The original goal for us was to demonstrate that the attacks that this category of malware makes are amenable to analysis to a greater or lesser extent, and the defending party can almost always detect and use the unsuccessful moves of the attacker.