A new ransomware family has appeared on the already too crowded scene over the past couple of weeks: Nefilim. Bleeping Computer had some of the first coverage on this ransomware. They describe an obvious link between this new ransomware family and Nemty, a ransomware family that we have extensively covered ourselves in the past (blog 1, blog 2, blog 3 and blog 4). The two ransomware families share much of their file encryption code, and there has already been some speculation on how this came to be: has the code perhaps been leaked or stolen? Or could (some of) the same actors be behind the two different ransomware families? In this post we present our technical analysis of the Nefilim ransomware and compare it to the recent Nemty 2.6 ransomware. Our analysis seems to support the theory that the actors behind Nemty and Nefilim are at least rather close to each other, if not the same.
Not all ransomwares are created equal
File encrypting ransomware can roughly be divided into two categories:
– Ransomware that is used in large scale attacks on mostly small victims.
– Ransomware that is used mostly in targeted attacks on large victims.
The first category is often managed using a Ransomware-as-a-Service (RaaS) model: the ransomware author makes it available to affiliates that are responsible for spreading the ransomware to the victims. Any ransom paid is usually split between the author and the affiliate (and possibly other parties involved). Many well-known ransomware families work in this way, for example Sodinokibi and Nemty. Usually, a decryptor tailored to a single system is required for each infected system and will be made available after payment of the ransom.
The second category usually works a bit differently: when a large organisation is hit by a targeted ransomware attack, all files on the different servers are often encrypted in such a way that a single decryptor can be used to decrypt everything. This clearly makes the work of both the victim and the attacker easier as it saves a lot of administrational effort on both sides. A RaaS model can still be used if one actor develops the ransomware and another actor uses it in a targeted attack, but the model is then usually less complex.
Of course, the division between the two categories is not so clear cut: some ransomware is used both for targeted attacks and wide-spread distribution.
From its code, Nefilim appears to be squarely in the second category. The ransomware has no traces of features for a RaaS business model and the cryptography indicates that a single decryptor can be built for a victim regardless of the number of infected machines. Trend Micro has an interesting post containing some details of an actual Nefilim attack. The fact that the ransom note only contains email as a means of contacting the actors also supports the notion that Nefilim is not meant to be used against a large number of victims, but is rather used in targeted attacks. In such an attack, the actor manually deploys (e.g. using simple scripts) the Nefilim binary on the compromised systems. The ransomware then encrypts the files and removes itself after its work is done. The actors behind Nefilim also threaten to release data captured from their victims if the ransom was not paid.
A brief analysis of Nefilim
As Nefilim is clearly meant to be used only as a tool to encrypt files on an already compromised server, its code base is a lot less complex than most ransomware from the RaaS category. There is for example no networking functionality, whereas RaaS ransomware often calls in to report each infection as well as some related statistics.
The code of Nefilim performs roughly the following steps when executed:
1. A mutex is created to prevent multiple instances of the ransomware to run concurrently on the same system
2. The decryption key for the embedded encrypted ransom note is generated
3. A 2048 bits RSA public key that is embedded in the ransomware binary is loaded
4. If a path or filename was provided on the command line, only this path or file is encrypted, otherwise the ransomware iterates over all drives of the system, drops a ransom note in the drive’s root directory and starts a separate thread to encrypt each of them
5. If the ransomware was used to simply encrypt all drives, it removes itself afterwards using a call to cmd.exe
The code corresponding to these steps has some noteworthy details that we will briefly discuss before moving on to the comparison of the code and functionality to Nemty 2.6.
The ransom note text is stored encrypted within the binary. To decrypt it, first a SHA1 hash is computed over a hard-coded string, and then the first 16 bytes of the hash are used as an RC4 key to decrypt the base64-encoded ciphertext of the ransom note.
For its file encryption, Nefilim uses AES-128 in Counter mode. A random 128 bit key and 128 bit initial counter value are generated for each file. A part of the file is then encrypted with AES using this key and counter value (the amount of encrypted data depends on the size of the file). The encrypted file contains a footer with the AES key and initial counter value both (separately) encrypted using the RSA public key. Finally, the footer contains the literal string ‘NEFILIM’.
Nefilim’s code also contains some interesting artefacts that may have just been left there for researchers. For example, there are some unused strings in the code such as “how to fuck all the world?” (probably never a good idea, but especially not during times of social distancing). And the name of the mutex is a part of the lyrics of the recently released Russian song ‘Drip Catcher’ by the artist ‘Kizaru’.
Nefilim: the child of Nemty?
As mentioned before in the post by Bleeping computer, the code of Nefilim looks a lot like the code of Nemty. The first striking similarity is the file encryption code: both encrypt data using AES-128-CTR (whereas AES-128-CBC is more common in ransomware) and the code that performs for example the key and initial counter generation, or the RSA encryption is also (nearly) identical. We deem it highly likely that at least this part of the code is compiled from (nearly) identical source code. However, identical source code of course does not necessarily imply identical actors.
Another remarkable similarity is the code that is used to encrypt certain embedded strings. Although this is only used in Nefilim for the decryption of the ransom note, whereas Nemty uses encrypted embedded strings all over the code, the algorithm that is used is identical: a literal string is first hashed using SHA1 and the first 16 bytes of the result are subsequently used as an RC4 key to decrypt the strings themselves.
A third and very interesting link between the two is in the list of file extensions that Nemty ignores in its encryption process: files with the extension ‘NEFILIM’ are explicitly ignored in Nemty 2.6! (The converse is however not the case: files previously encrypted by Nemty are happily encrypted a second time by Nefilim.) The list of extensions that are checked to ignore for encryption is identical between Nefilim and Nemty 2.6, down to the exact order of the checks. If we look back at an older Nemty version, for example Nemty 2.2, we see largely the same list of extensions (in the near opposite order), although some additional extensions have been added since, but ‘NEFILIM’ is not present in that code.
EXTENSIONS Nefilim
EXTENSIONS Nemty 2.2
Nemty 2.6 and Nefilim also contain the same list of directories to skip for encryption. Nemty 2.2 contains a very similar list, but the last couple of entries are missing when compared to Nefilim/Nemty 2.6. This may imply that the list that is found in both Nemty 2.6 and Nefilim is a logical extension of the list in Nemty 2.2.
DIRECTORIES Nefilim
DIRECTORIES Nemty2.2
Finally, but this might of course just be a coincidence: Nemty is the name of an Egyptian god, while Nephilim is a Hebrew term related to the offspring of gods. If there is a common actor behind the two, he or she might be interested in mythology. Or maybe the actor(s) just thought these were kick-ass names…
Conclusion
Inspection of the code of Nemty and Nefilim makes it abundantly clear that the two are related on a source code level. However, the exact reason behind shared code is hardly ever trivial to determine based on just the code.
It is unlikely that Nefilim was built by an unrelated actor using leaked or stolen code from Nemty: Nemty 2.6 clearly contains the string ‘NEFILIM’ in its file encryption code.
It is equally unlikely that Nemty 2.6 simply used the stolen or leaked encryption code from Nefilim without any other link between the two: the list of whitelisted directories in both Nemty 2.6 and Nefilim seems to be a logical evolution of the whitelist in Nemty 2.2.
In summary: Nefilim seems to be based on code from Nemty, and Nemty seems to contain code from Nefilim. Based on our analysis of the code, we thus believe it is likely that the source code of Nefilim was either authored by the same actor that also brought us Nemty, or the code was willingly shared with the author behind Nefilim, as Nemty recently started whitelisting .NEFILIM files in its encryption process.
As published by ZDNet and Bleepingcomputer, the actors behind Nemty have also just announced they will cease its public Ransomware-as-a-Service (RaaS) operation within a week. This makes it only more likely that Nefilim is just their new and rebranded business and that also explains how Nemty 2.6 already contains the mention of Nefilim as they were probably already planning this transition when Nemty 2.6 was released.
Indicators of Compromise
SHA256 hashes of the ransomware binaries used in this research:
– Nemty 2.2 : b2c11e6126a7de326e5fef14679279bf9fa920b7ba7142984d99790d89155b69
– Nemty 2.6 : 448e350455d2de1262d3884478df7fc2d6c47faa8759f90d7fb26629d8715557
– Nefilim : 08c7dfde13ade4b13350ae290616d7c2f4a87cbeac9a3886e90a175ee40fb641
