LockCrypt ransomware: weakness in code can lead to recovery

At the start of the year, it seemed that 2018 was going to be all about cryptominers. They so overwhelmingly dominated the landscape that it looked like no other threat had a chance. However, ransomware is not giving up the field so fast. There have been new variants popping up every couple of months, peering rather shyly around the corner.

At the moment, the most popular ransomware is GandCrab. However, a lesser-known family called LockCrypt has been creeping around under the radar since June 2017. Since it is spread via RDP brute-force attacks that must be manually installed, it has never been a massive threat—and therefore had never been described in detail.

But recently we were contacted by some victims of LockCrypt, so we decided to take a closer look. Our investigation led to some interesting findings, especially when we discovered that the ransomware authors decided to ignore popular advice not to roll your own crypto. As we could easily guess, it introduced weaknesses to the code, along with the possibility to recover the data in some cases.

Analyzed sample

99a3d049f11474fac6844447ac2da430

Behavioral analysis

In order to execute properly, the malware must be run as an Administrator. Due to the fact that it is deployed manually by attackers, it doesn’t use any tricks or exploits to automatically elevate its privileges.

Once it is run, it deletes the original sample and drops itself in C:Windows under the name

wwvcm.exe

It also adds persistence using a registry key:

This ransomware encrypts all the files it can possibly reach. During the process, it enumerates and tries to terminate all running applications so that they will not be blocking access to the attacked files. Executables are also attacked.

The names of the encrypted files are obfuscated—first encrypted and then converted to base64. The random ID is also a part of the name. The extension used is ‘1btc’.

The ransom note is dropped as a TXT file:

Which pops up at the end of the execution.

Looking inside the encrypted files, we saw that they have pretty high entropy. The example below shows a BMP file before and after encryption:

“>

Our initial assessment of the image was that the authors didn’t use a trivial XOR here. It may also look like a file encrypted by stream ciphers (or any ciphers in CBC mode). After looking inside the code, we will know more about it.

Looking at the changes made in the registry, we found more data left there by the ransomware, such as the unique ID of the victim:

Here’s a fragment of the communication:

The bot sends base64 encoded data about the attacked machine, such as the random ID, username, operating system, and the path from where the malware was deployed. Example:

WThSQVNVNDczUjZUMzVjNycsJ1dpbmRvd3MgNyBQcm9mZXNzaW9uYWx8dGVzdGVyfEM6XFVzZXJzXHRlc3RlclxEZXNrdG9wXGxvY2tjcnlwdC5leGU= 

Decodes to:

Y8RASU473R6T35c7','Windows 7 Professional|tester|C:UserstesterDesktoplockcrypt.exe 

The server sends back a block of bytes, which looks like some random or encrypted data. Its exact role we will find out by looking into the code.

Inside the code

The sample is not packed by any external crypter, nor is it obfuscated. Once we open it, we can directly see all that it has inside.

At the beginning, the ransomware checks the folder from which it is running. It tries to make a copy in the Windows folder and redeploys itself from that location.

Then, it creates a thread that continuously enumerates all the running processes and tries to terminate them.

It reads the registry to check if it was already deployed. Finding the appropriate keys can stop the infection—the malware will recognize the machine as already attacked. Otherwise, it will proceed further.

Encryption

The infection starts from the attempt to communicate with the CnC.

Looking inside this function, we could now understand the role of the mysterious buffer of bytes seen during the behavioral analysis. The downloaded buffer is validated by its CRC32 checksum. Then, it sets in a global variable for the further use of the encryption routine.

It turns out that this buffer is like a pad used for the encryption schema. The authors probably wanted to achieve something like a one-time-pad encryption. However, they reused the buffer, and because of this, they made their algorithm vulnerable for a plain text attack.

If for some reason downloading the buffer from the Internet is not possible, it is generated by a simple, pseudo-random algorithm:

The authors did not make the best choice for the random generator. Rather than using a cryptographically strong one, they went for the GetTickCount function.

Looking inside the encryption routine, we can see that the file is scrambled by a pretty simple function:

The scrambling algorithm has two different rounds. The reconstructed code of both rounds can be seen below.

Round 1

https://gist.github.com/hasherezade/781c18d902bbba023cef6a272c0b0624

This round uses only XOR operation, but there is a twist that prevents you from recovering the original key. Although the DWORD from the input is XORed with a DWORD from the key, the input is also tainted with the previous output. On every step, the first half of the input DWORD is taken from the previous output, while only the second half is fresh. That makes it a simple stream cipher.

Round 2

https://gist.github.com/hasherezade/ed8366cf0fd007a2a416f2531d5251e4

This round looks more complicated—Not only is XOR operation used here, but also ROL and bitwise swap. However, there is no input tainting this time, so it is easily reversible.

Those two simple rounds, together with the “pad” buffer that is 2,500 bytes long, were able to generate the output with pretty high entropy.

File names obfuscation

The names of the files are first XORed with the pad buffer, and then base64 encoded. The offset of the XOR key is 1111 characters from the beginning of the buffer.

The part of code responsible for this:

Sloppy, unprofessional code is pretty commonplace when ransomware is created for manual distribution. Authors don’t take much time preparing the attack or the payload. Instead, they’re rather focused on a fast and easy gain, rather than on creating something for the long run. Because of this, they could easily be defeated.