The story of the fight against the file-encryption trojan - a trip to the key control center

Introduction

The story began when a call rang at the beginning of the day. The excited voice of the client said that the computer does not load, documents do not open, and instead of the usual desktop on the screen there is a threatening inscription with an approximate meaning: “pay us the money and we will return the desktop and documents to you”. The situation is familiar to many: most likely there is another winlocker on the computer, work on cutting the ransomware will take a maximum of 10 minutes.

For the sake of removing the winlocker, in 10 minutes I did not want to go to the other end of the city, so we agreed that they would bring the system engineer to me, I would put it in order and return it.

I got the system, turned it on. Booted up XP. A desktop appeared - no signs of a winlocker, at first glance everything is fine. However, trying to open the first document that came across from the desktop, I received a “scary” message in response:



Naturally, like any person who is not the first to encounter ransomware Trojans, I reacted to this text with a fair amount of skepticism. Surely, I thought, this is all a matter of a regular program that reconfigured itself to open files with the extension .doc and .xls in order to frighten inexperienced users with text with incomprehensible words. To verify this assumption and catch a hooligan program, I booted up the computer from the system recovery image, opened the C drive in the file manager and saw a completely unhappy picture: all the files on the local drives suddenly acquired the M5bFu extension, and their contents looked like the result of the generator random numbers. There is no trace of the previous contents of the files.

So, the message that the files were encrypted turned out to be pure truth. All files less than 2 gigabytes in size with the extension doc, xls, dbf, avi, jpg, txt, rar, zip were encrypted - in general, everything that can be of value to the owner of the information. Among the encrypted files - 1C base and important documents. If 1C could still be restored from a fresh backup, then the loss of valuable documents and photos could greatly affect the health of the client. Thus, there was no choice - I had to tackle the decryption of the data.

Stage 1. Search for encryption algorithm

Again, being slightly mistrustful by nature, I decided, despite the explicit indication of the encryption algorithm in the message, to independently determine which cryptographic algorithm encrypted the data in the files (suddenly everything is not as scary as it is written). First, we check the simplest and most common replacement ciphers: Caesar's cipher, XOR, etc.

For analysis, we take two dbf files: one encrypted from the infected system, the other untouched from a fresh backup and compare them with each other. Regions of the source dbf file filled with consecutive identical bytes, for example, with a value of 0, may indicate a primitive replacement cipher. Fortunately, dbf files do not differ in high density of stored information, and there are plenty of zero bytes in them.



The figure shows fragments of the source file with several zeros in a row and what these zeros turned into an encrypted file. Simple in-line replacement ciphers, where the plaintext character is converted to the same cryptogram character, have disappeared immediately. A deeper analysis showed that a simple character-based XOR plaintext with a keyword also does not take place here. In the end, it was possible to find out that the cipher is block, without feedback and gamming. The block length is 16 bytes.

Thus, I had to accept the use of the RC6 cipher as a hypothesisspecified in the message from the creators of the trojan. Subsequently, the hypothesis was confirmed, namely, the encryption was performed by the RC6 algorithm with a block length of 16 bytes, and it is used "lock", according to the block diagram. The authors of the implementation did not even bother to encrypt incomplete blocks, less than 16 bytes, leaving them as they are, unencrypted.

So, the algorithm is known. The only thing left is to find the key.

Stage 2. Key Search

To search for the key, we first find the body of the malicious program (or what is left of this body). In the% SYSTEMROOT% \ System32 directory we find 2 "extra" exe files: system.exe and another executable file with a random name (H3w2DWg.exe). Both files are part of the Trojan that infected the system, however, none of the files at the time of detection (April 2012) were recognized by antiviruses as malicious. At the moment, some antiviruses recognize the Trojan correctly as Trojan.Encoder.136 (DrWeb) or as Win32 / Filecoder.AF (ESET-NOD32), however, most antiviruses at best think that this is just a slightly suspicious file. Here is a link to virustotal .

Once the Trojan is not recognized by antiviruses, you will have to dissect it yourself. Armed with hiew32, OllyDbg and a virtual machine, he proceeded to an autopsy. An autopsy revealed that the Trojan’s files were not packaged, not encrypted, and written in Borland Delphi. Inside, links to encrypted files account.cfg, config.cfg and lock.cfg were also found, which are also in% SYSTEMROOT% \ System32. By debugging in the bowels of the exe files, a certain key was also found in the form of a 32-character string “1kv9yha029v9vi71xioa7h812ga811n9” of length 32. Using this key, the Trojan decrypted the lock.cfg file.
It remains to understand how this string is converted to an RC6 key. The length of the RC6 key is from 128 bits or more. As a first attempt, we will try to convert each character into an 8-bit representation using an ASCII code. As a result, we obtain a key of length 32 * 8 = 256 bits. We write a program in C ++, submit the key and the lock.cfg file to the program for input. We start the decryption process. Failure. The file was not decrypted.

What are the options left? The longest and most painstaking is to pull the algorithm for generating the key with the debugger from the executable file. I left this option as a last resort because of its excessive laboriousness. Instead, let's think a bit and put ourselves in the shoes of the creators of the malware. It is unlikely that the authors of the Trojan independently implemented an encryption algorithm. With a high probability, the finished implementation of the algorithm on the dolphin was downloaded from the Internet. Also, ready-made compiled libraries were hardly used, in them the cryptographic algorithm would be implemented much better and certainly would not leave less than 16 bytes blocks unencrypted. We conclude that the Trojan most likely used a student curriculum, the sources of which the attackers stole from the Internet.

We climb into Google and look for something with the keywords Delphi RC6. We find the link http://www.delphi-club.ru/delphi/rc6_encryption.html . So it is, a module on Delphi, which encrypts the file with blocks without gamma and leaves the last block less than 16 bytes long unencrypted. We take the key generation features from the implementation, rewrite them in C ++, compile the decryption program. We feed the program a 32-character key, try to decrypt the lock.cfg file. Again failure.

There was an option with OllyDbg and the body of the Trojan. I will not bore with the details of obtaining the secret algorithm by which the key was generated, especially since the procedure itself did not take so much time. The secret was simple. A string of characters with a key was read from ASCII encoded file resources (32 characters = 32 bytes), then (apparently by Delphi itself) converted to UTF-16LE - 64 bytes were obtained (in practice, bytes were simply diluted with zeros). And this result was already fed to the well-known, thanks to the source on the dolphin, algorithm for obtaining the key. The key length at the output is 512 bits.

The lock.cfg file was successfully decrypted with the received key. Inside the file, there was a key to the files config.cfg and account.cfg, as well as a list of domain names of sites to be blocked through the hosts file and a list of “harmful” processes (antiviruses, firewalls), which are also likely to be blocked, according to the Trojan.

The account.cfg file contained a couple of additional keys (in the same 32-line string format), an account number for Money.ru, someone’s e-mail address, information about the infected computer and some other small information. In the config.cfg file, among other things, there was an IP-address of the computer, which, by all indications, was the control server of the malicious program.

However, sadly, none of the keys found in the files was suitable for decrypting the files on the disks of the infected computer. Another statement by the attackers turned out to be true: the key for decrypting files is really not stored on the computer. The last hope remained - to shake the key from the control server of the malicious program. According to the message from the authors of the Trojan, the key is stored there for 7 days, it is at this time that it needs to be obtained, otherwise the files cannot be decrypted - it will take decades to select a 32-character key from a combination of numbers and Latin letters in upper and lower case, and files with valuable documents urgently needed.

Stage 3. To the key control center

Before you go to the control center, you need to find out several features of its operation, namely: which transport protocol is used to connect to the server, whether the connection is encrypted or not, how the client and server exchange data with each other. To address these issues, the most obvious option was to deploy the Trojan to a clean system and observe its network exchange with the management server.

A clean operating system was installed on the virtual machine, WireShark was launched on the main machine, and a Trojan on the virtual machine. It turned out that the connection uses an unencrypted connection via TCP port 80. During the initial infection, computer data (OS, processor, memory) is sent to the server, and additional Trojan modules are downloaded from the server, as well as SSLeay dll files, which are then used to work with the site Money@Mail.ru.

Most likely, when sending computer data to the server, a computer account is created on the server (this was a hint in a message from the authors, in the section on reinstalling the operating system). Along with the account, a unique key is supposedly created, which subsequently encrypts the data on the hard drive. This key is what you need to get.

When the Trojan is restarted on the infected computer, it also contacts the management server. At the same time, the Trojan no longer reports data about the computer, but provides the server with a key, which is stored in the account.cfg file. It is this key that is the identifier of the infected computer and it is with this key that we will receive the key for decrypting files.

Exchange with the management server is in the format: "client command - server response." Rummaging through the bowels of the malware, I pulled out a list of valid commands: mail, rekey, key, check_pay, get_masks, ssl, winlock, and many others. From WireShark I learned the format of client commands and parameters. It is time for experimentation. Having entered the server using telnet and posing as an infected computer (client_info command with a parameter in the form of a key), I entered the key command, in response to which I received a ready-made key for decrypting the files.

As a result, I added a program in C ++ that decrypts all the files on the disk. The client received back all his files and the desktop in addition.

Conclusion

I do not consider myself a virus analyst at all and I think that in this case, on the way to victory, several obvious mistakes of the attackers helped me. Firstly, the authors of the malware themselves revealed a lot of important information in their message to the user: the encryption algorithm and the fact that the key is stored on the server. Secondly, the exchange with the server was carried out through open channels using a fairly simple text protocol - this significantly accelerated the process of obtaining the key. Thirdly, the authors of the Trojan did not bother too much about protecting their product from decompilation and debugging, which ultimately simplified the analysis of the encryption and key reception algorithm. And the general impression: someone just wanted to quickly cut down money, not really worrying about protecting their product from hacking.

It is hoped that in the future such malicious programs will not gain wide popularity. Better harmless winlockers are better than such extortionists, thanks to which you can lose your files forever.