A decryptor for the Nemty ransomware based on analysis of its cryptography

The Nemty ransomware family has recently been discovered and described in detail by FortiGuard Labs. Tesorion researchers have investigated the same binary, and have found a couple of minor but crucial deviations from the default AES-CBC encryption algorithm mentioned in their write-up. These deviations make it impossible to use common cryptographic libraries to decrypt a file encrypted by Nemty, even if the AES key and initialization vector (IV) are known.

Based on our analysis of the Nemty ransomware, we have been able to develop a process that can in some cases recover the original files for a Nemty infection without involving the threat actor and thus without paying the ransom. To avoid suggesting possible improvements to the ransomware authors, we will not publish the details of our research.

Update: Our decryptor is available for download at the NoMoreRansom website.

Introduction

Recently, FortiGuard Labs published a blog post describing the newly discovered Nemty ransomware. Their blog describes many aspects of the ransomware very well, including the process it uses for encrypting the victim’s files. Tesorion has independently analysed the same Nemty binary used by the FortiGuard researchers and can confirm many of their findings. During our analysis we ran the malware in a sandbox and a debugger to get a better understanding and to be able to peek at data that would later be encrypted, such as AES keys and IVs. However, when we took an AES key and IV combination for a file and tried to decrypt the corresponding file using AES-128-CBC (the algorithm described in the FortiGate write-up) we were unsuccessful. When diving deeper into the actual file encryption code, we encountered several minor (but important) differences between the actual code, and the description of its workings by FortiGuard. These differences concern the AES key size, the AES algorithm key scheduling phase, and the CBC mode of operation for the AES algorithm. As we will see, Nemty does not use a standard AES implementation, and the code used in Nemty is incompatible with the standard AES algorithm. This means that even if the AES key and IV for a file are known, we still need to account for these differences to successfully decrypt a file encrypted by Nemty.

Cryptography 101

Let’s start with a brief refresher on cryptography. The data to encrypt is commonly referred to as the ‘plaintext’ and the corresponding encrypted data is called the ‘ciphertext’. Encryption algorithms, or ‘ciphers’, fall roughly into two broad categories: symmetrical and asymmetrical. A symmetrical cipher uses the same key for encryption and decryption. An asymmetrical cipher has two separate keys: a public key used for encryption, and a private key used for decryption. Symmetrical ciphers are typically used to exchange information between two parties that have access to a shared but otherwise secret key. Asymmetrical ciphers are typically used where many different parties have the same public key and need to be able to encrypt data that can subsequently only be decrypted by a single party that is in possession of the private key.

If we look at the cryptography that is currently most commonly used and considered safe (enough), then the symmetrical ciphers are usually a lot faster than the asymmetrical ones. A common pattern therefore is to generate a key for a symmetrical cipher (such as AES), use that to encrypt a lot of data, and then use an asymmetrical cipher (such as RSA) to encrypt the key itself using the public key of the intended recepient and send the combination of the encrypted data and the encrypted key to them. This pattern benefits of the speed of the symmetrical cipher for the large amount of data, while using the properties of the asymmetrical one for sharing the key only with the intended recepient.

Symmetrical ciphers can be stream or block based. We will only discuss block ciphers here as this is what Nemty uses for file encryption.

Block ciphers split the data in blocks of a fixed size, e.g. 128 bits (16 bytes) and perform the encryption itself only on individual blocks. If we encrypt the blocks individually without taking the other blocks of the plaintext into account, this is called ECB (electronic code book) mode. There are however also other so-called modes of operation for block ciphers. One of the most commonly used is CBC (cipher block chaining). When using CBC, a random initialisation vector (IV) is provided for each encryption. This IV is then XORed with the first plaintext block before applying the block cipher. The output of the block cipher is the first block of the ciphertext. The first block of the ciphertext is then XORed with the second block of the plaintext before applying the block cipher to the second block, and so on. The IV is usually distributed together with the ciphertext and does not necessarily have to be kept a secret, as it is only of use when the encryption key itself is also known.

AES: keys and key scheduling

AES is a block cipher based on the Rijndael block cipher. AES has a fixed block size of 128 bits (16 bytes) and supports three different key sizes: 128 bits, 192 bits and 256 bits. In cryptography we can broadly state that larger key sizes within the same algorithm are usually more secure, but also usually take more computing time for encryption and decryption.

Contrary to the original description by the FortiGuard team that mentions AES-128, in our analysis we actually found that Nemty uses a 256 bits (32 bytes) key for AES. This is the largest possible key size for AES and could be considered as overkill for file encryption in a ransomware, especially as it slows down the encryption process.

AES encryption or decryption consists of roughly two phases: first the encryption key (256 bits in the case of Nemty) is expanded to a set of so-called round keys that are derived from the encryption key itself. This phase is often referred to as ‘key scheduling’. (Readers interested in the details of the AES key scheduling process can read the in-depth description on Wikipedia.) After the key scheduling, the actual encryption or decryption of a 128 bit block proceeds over a number of iterations, called rounds, using the round keys. The number of rounds used by AES is dependent on the key size: 10 rounds for 128 bit keys, 12 rounds for 192 bit keys and 14 rounds for 256 bit keys. As each round requires a different set of round keys, the number of round keys that is generated during key scheduling depends also on the size of the key. Furthermore, the algorithm for the key scheduling also works slightly differently for different key sizes. In particular, in the case of 256 bits it contains an additional calculation for some round keys that is absent in the 128 and 192 bit versions.

From the Nemty file encryption code it is clear that 14 AES rounds are performed, implying the use of a 256 bit key. This is also confirmed by the fact that a 32 character random string is generated as AES Key, as described by FortiGuard. However, the implementation of the AES key scheduling algorithm in Nemty contains a bug: their implementation does not contain the special additional calculation required for 256 bit keys, and is rather more similar to the 128/192 bit algorithm extended to the number of round keys required for 256 bits. We expect that this is why the FortiGuard team mentioned 128 bit as the key size in their write-up: in the absence of the special calculation for 256 bits keys, the code simply looks more like the 128 or 192 bit variant.

When we investigate a malware binary, we often use virtual machines, sandboxes and debuggers to trace its execution and gain access to data that is otherwise unreachable, such as the AES encryption keys and IVs. But even when we were sure that we had the right AES Key and IV, we were still unable to decrypt files encrypted by Nemty. It was only after finding this bug in their AES key scheduling that we understood why our attempts were doomed: standard AES implementations such as those offered by the Windows cryptography provider or OpenSSL are incompatible with the AES variant used in Nemty due to this bug! Only after developing our own AES implementation containing the same bug in the key scheduling were we able to successfully decrypt the first blocks from Nemty encrypted files.

AES: mode of operation

The bug in the AES key scheduling is not the only non-standard behaviour in Nemty’s AES implementation; the mode of operation is non-standard as well. According to the FortiGuard blog post, CBC is used as mode of operation for AES. However, on close inspection of the code, we noticed that this is not the case. Nemty indeed generates a 128 bit IV for each individual file. However, this IV is XORed with each block before AES encryption, whereas in CBC the IV is only used in the encryption of the first block and the subsequent plaintext blocks are XORed with the preceding ciphertext blocks.

Effectively in Nemty each plaintext block is individually XORed with the same file-specific IV and then AES encrypted in ECB mode.

After extending our custom Nemty AES implementation with this ‘ECB-with-IV’ mode, we could finally successfully decrypt an encrypted file with the corresponding AES key and IV!

Availability of a decryptor and (not) assisting malware authors

Using the knowledge gained during our extensive investigation of the Nemty ransomware we were able to develop a process that can in many common cases decrypt files from a Nemty-infected system without contacting the Nemty authors and paying the ransom. This led us to the next (albeit less technical) problem: what to do with these tools? On the one hand we want to freely contribute our decryptor for the benefit of any Nemty victim, on the other hand we don’t want to assist malware authors in fixing their mistakes.

Let’s make one thing very clear: although we are a commercial enterprise, we do not want to put victims in a position where they have to choose between paying the ransom or paying us for a decryptor that we have already built.

Tesorion believes in the NoMoreRansom initiative where decryptors for several well-known ransomware families are made available online for anyone to download, and we would have liked to contribute our decryptor for the benefit of all victims. Often, these decryptors are based on things like leaked RSA private keys or data from confiscated servers. If the malware authors are still active after such data has been leaked, they build a new version of the malware with e.g. different keys and the whole game has to start over again. Our decryptor however is not based on such leaked data, but rather on a couple of mistakes in the Nemty code. And by publicly providing our tools we provide the authors of Nemty or other ransomware families with the opportunity to analyse our process and learn from these mistakes, making it harder, if not impossible, for us and others to build decryptors for future ransomware variants.

We have therefore decided at this point in time to not make our tools publicly available, but rather try a different approach to see if we can stretch the time before the authors fix their bugs while still helping victims at no cost. We offer to provide a custom decryptor to legitimate victims of the Nemty ransomware for free to assist them in recovering their files. This custom decryptor will often be able to recover many important files such as photos or office documents.

Update: As we discovered a way to develop a working decryptor and published this blog post, we contacted Europol regarding their NoMoreRansom project. We were initially hesistant to publish our decryptor on the NoMoreRansom website, because we did not want to show the Nemty authors how to fix the bugs that allowed us to decrypt. While working on our decryptors for Nemty 1.5 and 1.6 we had a number of good discussions with Europol, and together we arrived at a setup where the actual ‘cracking’ of the encryption could be performed on our servers. This enabled us to distribute a simple decryptor binary that could use the result from our servers to decrypt the actual files on the victim’s machine. Our decryptor is now available for download at the NoMoreRansom website.

Conclusion

In this blog post we describe several peculiar details of the AES implementation in the Nemty ransomware that make it behave different from a standard AES-256-CBC implementation. These differences are important for anyone who aims to develop a decryptor for files encrypted by Nemty. Tesorion has developed such a decryptor capable in many cases of decrypting files without paying the ransom.