Tesorion has previously released decryptors for the Nemty ransomware up to version 1.6. Recently, new versions of Nemty have appeared in the wild. In this blog post we describe how a weird variant of AES-128 counter mode (CTR) encryption is used in Nemty 2.2 and 2.3 for its file encryption. We also announce the availability of a free decryptor for common office documents encrypted by Nemty 2.2 and 2.3.
Introduction
After we published our blog post on a decryptor for Nemty 1.4 several months ago, the Nemty author responded as expected by quickly releasing Nemty 1.6, in which they even explicitly thanked us for our article. We were however still able to release a free decryptor for Nemty 1.6 shortly afterwards. After this, it took a while before new Nemty versions were again encountered in the wild, but the Nemty author does seem to have been busy and several new Nemty versions have recently been spotted. In this blog post we analyse versions 2.2 and 2.3 of the Nemty ransomware.
In Nemty 1.5 and below the author used a custom AES-256-CBC implementation that suffered from several bugs. Fortunately in Nemty 1.6 an ordinary AES-128-CBC was used, making everybody’s life a lot easier. However as we will see below, in Nemty 2.2 and 2.3 the author has again resorted to a custom implementation of the cryptography, and two bugs in the cryptographic code have been introduced.
In the remainder of this blog post, we take a look at the cryptographic algorithm used to encrypt files, and we announce the general availability of a free decryptor for common office documents encrypted by Nemty 2.2/2.3.
The file encryption of Nemty 2.2 and 2.3
First of all, when analysing the new Nemty code, we were happy to see that the bug causing corruption during the encryption of large files in Nemty 1.6 and below seems to be fixed in Nemty 2.2/2.3: the author now uses the SetFilePointerEx function (as also suggested in our blog post) instead of the SetFilePointer function. We have not yet extensively verified that files of any size can now always be reliably decrypted, but we are definitely hopeful that corruption due to a bug in the encryption process is now a thing of the past.
Moving on to the actual encryption of the data, we see that the core cipher is still the standard AES-128. However instead of using ‘cipher block chaining’ (CBC) as Nemty 1.6 did, this newer Nemty code uses a custom implementation of ‘counter mode’ (CTR). Counter mode is a mode of operation where a block cipher such as AES is turned into a stream cipher. (The interested reader is refered to the explanation of different modes of operation on Wikipedia.) Using CTR instead of CBC is uncommon, but not necessarily a bad choice from the ransomware author’s point of view: both modes are usually considered secure from a cryptographical point of view (when used correctly).
As has become somewhat of a tradition with Nemty, their custom implementations of cryptography have some non-standard behavior (that some might consider bugs). The first thing that stands out in their CTR implementation, is that the first 128 bits of the ciphertext is XORed with the counter value for each of the subsequent blocks. This is something we needed to take into account when writing our decryptor, as a standard AES-128-CTR implementation is not compatible with Nemty 2.2/2.3!
The second bug is in the function that increases the counter value: it is not uncommon to use a function here that adds one to the current counter value for each block. An easy way to implement this, is to first increase the value of the last octet, and when that value overflows from 0xFF to 0x00, increase the value of the preceeding octet by one, and so on and so forth. Just like ordinary counting with decimal digits. However, the implementation of this increment operation in Nemty 2.2/2.3 is flawed: instead of stopping at the first octet that DOES NOT overflow, the Nemty code stops at the first octet that DOES overflow. In most cases this means that all of the octets in the counter value are updated for each block, instead of only the least significant one. Again, something to take into account when writing our decryptor, as a standard AES-128-CTR implementation does not work this way.
Finally, we have seen in previous versions that Nemty does not encrypt large files in their entirety, but rather selects some parts to encrypt, and leaves other parts unencrypted. This is still the case in Nemty 2.2 but the calculations for which parts to encrypt are different when compared to Nemty 1.6. And in Nemty 2.3 these calculations again differ from the calculations in Nemty 2.2. We can only guess why the author keeps changing this.
An early christmas gift for Nemty 2.2/2.3 victims
Based on our analysis of the cryptography of Nemty 2.2 and 2.3, we have again been able to build a decryptor. Due to technical reasons, our decryptor for Nemty 2.2/2.3 only supports decryption of a rather limited set of file formats: the current version will only decrypt most docx, xlsx and pptx files. We are still investigating whether it will be possible for us to expand the list of supported file formats in the future, but we wanted to release our current version as soon as possible so Nemty 2.2 and 2.3 victims can at least attempt to recover their office documents for free.
Support for office documents encrypted by Nemty 2.2 and 2.3 has been added to our existing Nemty decryptor on the NoMoreRansom project.
In 2019 ransomware was still a large threat to consumers and enterprises alike. And even though free decryptors for different ransomware families are being added to NoMoreRansom on a regular basis, prevention is still to be preferred. So we end on a familiar note with some common advice: make sure to keep your systems up-to-date and secure, be careful with files from unknown origins, and always have backups!
Indicators of Compromise
SHA256 of the Nemty binaries used in this research:
- Nemty 2.2 : b2c11e6126a7de326e5fef14679279bf9fa920b7ba7142984d99790d89155b69
- Nemty 2.3 : 2a5f9e5d72b4841538a73ee2556865d8ed76e3da38571f00148368874edf55c8
