{"id":11926,"date":"2018-04-04T08:10:02","date_gmt":"2018-04-04T16:10:02","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2018\/04\/04\/news-5695\/"},"modified":"2018-04-04T08:10:02","modified_gmt":"2018-04-04T16:10:02","slug":"news-5695","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2018\/04\/04\/news-5695\/","title":{"rendered":"LockCrypt ransomware: weakness in code can lead to recovery"},"content":{"rendered":"

Credit to Author: Malwarebytes Labs| Date: Wed, 04 Apr 2018 15:00:54 +0000<\/strong><\/p>\n

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.<\/p>\n

At the moment, the most popular ransomware is GandCrab. However, a lesser-known family called\u00a0LockCrypt has been creeping around under the radar since\u00a0June 2017<\/a>. Since it is spread via RDP brute-force attacks that must be manually installed, it has never been a massive threat\u2014and therefore had never been described in detail.<\/p>\n

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.<\/p>\n

Analyzed sample<\/h3>\n

99a3d049f11474fac6844447ac2da430<\/a><\/p>\n

Behavioral analysis<\/h3>\n

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.<\/p>\n

Once it is run, it deletes the original sample and drops itself in C:Windows<\/code> under the name wwvcm.exe<\/code>:<\/p>\n

\"\"<\/p>\n

It also adds persistence using a registry key:<\/p>\n

\"\"<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

The names of the encrypted files are obfuscated\u2014first encrypted and then converted to base64. The random ID is also a part of the name. The extension used is ‘1btc’.<\/p>\n

The ransom note is dropped as a TXT file:<\/p>\n

\"\"<\/a><\/p>\n

Which pops up at the end of the execution.<\/p>\n

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

\"\" \"\"<\/p>\n

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)<\/a>. After looking inside the code, we will know more about it.<\/p>\n

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:<\/p>\n

\"\"<\/p>\n

Network communication<\/h3>\n

The malware is capable of encrypting without an Internet connection. However, if we run it on a connected machine, it beacons to its CnC. The CnC IP is 46.32.17.222 (located in Iran)<\/a>.<\/p>\n

Here’s a fragment of the communication:<\/p>\n

\"\"<\/p>\n

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:<\/p>\n

WThSQVNVNDczUjZUMzVjNycsJ1dpbmRvd3MgNyBQcm9mZXNzaW9uYWx8dGVzdGVyfEM6XFVzZXJzXHRlc3RlclxEZXNrdG9wXGxvY2tjcnlwdC5leGU=  <\/pre>\n
Decodes to:<\/p>\n
Y8RASU473R6T35c7','Windows 7 Professional|tester|C:UserstesterDesktoplockcrypt.exe  <\/pre>\n
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.<\/p>\n
Inside the code<\/h3>\n
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.<\/p>\n
\"\"<\/p>\n
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.<\/p>\n
Then, it creates a thread that continuously enumerates all the running processes and tries to terminate them.<\/p>\n
It reads the registry to check if it was already deployed. Finding the appropriate keys can stop the infection\u2014the malware will recognize the machine as already attacked. Otherwise, it will proceed further.<\/p>\n
Encryption<\/h3>\n
The infection starts from the attempt to communicate with the CnC.<\/p>\n
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.<\/p>\n
\"\"<\/p>\n
It turns out that this buffer is like a pad used for the encryption schema. The authors probably wanted to achieve something like a\u00a0one-time-pad encryption<\/a>. However, they reused the buffer, and because of this, they made their algorithm vulnerable for a plain text attack.<\/p>\n
If for some reason downloading the buffer from the Internet is not possible, it is generated by a simple, pseudo-random algorithm:<\/p>\n
\"\"<\/p>\n
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.<\/p>\n
Looking inside the encryption routine, we can see that the file is scrambled by a pretty simple function:<\/p>\n
\"\"<\/p>\n
The scrambling algorithm has two different rounds. The reconstructed code of both rounds can be seen below.<\/p>\n
Round 1<\/h4>\n