The history of the fight with the file-encrypting Trojan - a trip to the control center for the key

Introduction

The story began with the fact that at the beginning of the day the bell rang. The agitated 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 money and we will return your desktop and documents to you”. The situation is familiar to many: most likely another winlocker on a computer, the work on the extortioner drank will take a maximum of 10 minutes.

For the sake of removing a vinloker in 10 minutes, I didn’t want to go to the other end of the city, so we agreed that they would bring a system officer to me, I would put it in order and return it back.

I got a sistemnik included. Windows XP was loaded. A desktop appeared - no sign of a winlocker, at first glance everything is fine. However, trying to open the first document from the desktop, I received in response a “terrible” message:


')
Naturally, like any person who is not the first time faced with Trojans, extortionists, I treated this text with a fair amount of skepticism. Surely, I thought, it’s all a matter of the usual program, which reconfigured the opening of files with the .doc and .xls extensions in order to scare inexperienced users with text with incomprehensible words. To make sure of this assumption and catch the hooligan program, I booted the computer from the system recovery image, opened drive C in the file manager and saw a very sad picture: all files on local drives suddenly acquired the M5bFu extension, and their contents became similar to the result of the generator random numbers. There is not a trace of the previous file contents.

So, the message that the files are encrypted turned out to be true. All files smaller than 2 gigabytes with the extension doc, xls, dbf, avi, jpg, txt, rar, zip turned out to be encrypted - in general, everything that may be of value to the information owner. 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 photographs could seriously damage the client’s health. Thus, there was no choice - I had to take up the decryption of data.

Stage 1. Search for encryption algorithm

Again, being by nature slightly untrustworthy, I decided, despite the explicit indication of the encryption algorithm in the message, to independently determine how the cryptographic algorithm encrypts the data in the files (all of a sudden it’s not as bad as it is written). First, we check the simplest and most common replacement ciphers: Caesar cipher, XOR, etc.

For analysis, we take two dbf files: one is encrypted from the infected system, the other is untouched from a fresh backup and compare them with each other. We can indicate to the primitive replacement cipher areas of the source dbf file filled with consecutive identical bytes, for example with a value of 0. Fortunately, dbf files are not distinguished by 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 in an encrypted file. Simple inline replacement ciphers, where the plaintext character is converted to the same cryptogram symbol, disappeared immediately. A deeper analysis has shown that a simple, character-based, XOR plaintext with a keyword also does not hold here. In the end, we managed to find out that the cipher is block, without feedback and gamming. Block length is 16 bytes.

Thus, we had to accept as a hypothesis the use of the RC6 cipher indicated in the message from the creators of the Trojan. Subsequently, the hypothesis was confirmed, namely, the encryption performed by the RC6 algorithm with a block length of 16 bytes, and it is used “vlob”, according to the flowchart. The authors of the implementation did not even bother to encrypt incomplete blocks, less than 16 bytes, leaving them as is, unencrypted.

So, the algorithm is known. It remains the case for small: find the key.

Stage 2. Key search

To find the key, we first find the body of the malicious program (or what remains 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 a Trojan that infected the system, but none of the files at the time of detection (April 2012) were identified by antivirus as malicious. At the moment, some antiviruses recognize the Trojan program as Trojan.Encoder.136 (DrWeb) or as Win32 / Filecoder.AF (ESET-NOD32), but most antiviruses at best think that this is just a slightly suspicious file. Here is a link to virustotal .

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

What are the options? The longest and most painstaking is to pull out the key generation algorithm by the debugger from the executable file. Left this option as a last resort because of its excessive complexity. Instead, we will think a little and put ourselves in the place of the creators of the malicious program. It is unlikely that the Trojan authors independently implemented the encryption algorithm. Most likely, the finished implementation of the algorithm on the Delphi was downloaded from the Internet. It is also unlikely that ready-made compiled libraries were used, the cryptographic algorithm in them would be implemented much better and certainly would not leave unencrypted blocks of less than 16 bytes. We conclude that the student’s curriculum was most likely used in the Trojan, the sources of which the attackers had stolen from the Internet.

Zalazim in Google and looking for something on the keywords Delphi RC6. Find the link http://www.delphi-club.ru/delphi/rc6_encryption.html . So it is, a module on Delphi, which encrypts a file with blocks without gamming and leaves the last block with a length of less than 16 bytes unencrypted. From the implementation we take the key generation features, rewrite them in C ++, compile the decryption program. We feed the program 32-character key, trying to decrypt the file lock.cfg. Again, failure.

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

The received key file lock.cfg was successfully decrypted. Inside the file, a key was found for the files config.cfg and account.cfg, as well as a list of domain names for blocking through the hosts file and a list of “harmful” processes (antiviruses, firewalls) in the Trojan’s opinion — probably also for blocking.

The account.cfg file contained a couple of additional keys (in the same format of a string of 32 characters), an account number on Dnehny@Mail.ru, someone's e-mail address, information about the infected computer and some other small information. In the config.cfg file, among other things, was the ip-address of the computer, which, by all indications, was the managing server of the malware.

However, sadly, none of the keys found in the files were suitable for decrypting files on the disks of an infected computer. Another statement by the attackers turned out to be true: the key for decrypting files is not really stored on the computer. The last hope is to shake the key out of the malicious server’s managing server. According to a message from the authors of the Trojan, the key is stored there for 7 days, it is during this period that you need to retrieve it, otherwise it will not work to decrypt the files - selecting a 32-character key from a combination of numbers and uppercase and lowercase Latin letters will take decades, and files with valuable documents are needed urgently.

Stage 3. In the control center for the key

Before you go to the control center, you need to find out several features of its work, namely: what transport protocol is used to connect to the server, whether the connection is encrypted or not, how the client and server exchange data between themselves. To address these issues, the most obvious option was to implement the Trojan on 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 was launched on the virtual machine. It turned out that the connection uses an unencrypted connection via TCP port 80. During the initial infection, the computer’s data (OS, processor, memory) goes to the server, and additional modules of the Trojan are downloaded from the server, as well as the SSLeay dll files, which are then used to work with the site Dengi@Mail.ru.

Most likely, when sending computer data to the server, a computer account is created on the server (this was hinted at in a message from the authors, in the section on reinstalling the operating system). Along with the account, a unique key is presumably created, which subsequently encrypts the data on the hard disk. This is the key and need to get.

When the Trojan is restarted on the infected computer, it also accesses 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 the help of this key that we will receive the key for decrypting files.

The exchange with the managing server is carried out in the format: "client's command - server response". Having rummaged in the depths of the malicious program, I pulled out a list of valid commands: mail, rekey, key, check_pay, get_masks, ssl, winlock and many others. From WireShark'a learned the format of client commands and parameters. It's time to experiment. Logging on to the server using telnet and presenting himself as an infected computer (client_info command with a parameter in the form of a key), entered the key command, in response to which he received a ready-made key to decrypt files.

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

Conclusion

I do not consider myself to be a virus analyst, and I think that in this case, several obvious misses of the intruders helped me on the way to victory. First, 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 greatly accelerated the process of obtaining the key. Third, 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 algorithm and obtaining the key. Yes, and the general impression: someone just wanted to quickly cut the money, not really worrying about protecting your product from hacking.

It is hoped that in the future such malware will not gain wide popularity. It is better to harmless Vinlockers than such extortionists, thanks to whom you can lose your files forever.