Napoleon: a new version of Blind ransomware

The ransomware previously known as Blind has been spotted recently with a .napoleon extension and some additional changes. In this post, we’ll analyze the sample for its structure, behavior, and distribution method.

Distribution method

So far we are not 100 percent sure about the distribution method of this new variant. However, looking at the features of the malware and judging from information from the victims, we suspect that the attackers spread it manually by dropping and deploying on the hacked machines (probably via IIS). This method of distribution is not popular or efficient, however we’ve encountered similar cases in the past, such as DMALocker or LeChiffre ransomware. Also, few months ago, hacked IIS servers were used as a vector to plant Monero miners. The common feature of samples dropped in this way is that they are not protected by any cryptor (because it’s not necessary for this distribution method).

Behavioral analysis

After the ransomware is deployed, it encrypts files one-by-one, adding its extension in the format [email].napoleon.

Looking at the content of the encrypted test files, we can see that the same plaintext gave different ciphertext. This always indicates that different key or initialization vectors were used for each file. (After examining the code, it turned out that the difference was in the initialization vector).

Visualizing the encrypted content helps us guess the algorithm with which the files were encrypted. In this case, we see no visible patterns, so this leads us to suspect an algorithm with some method of chaining cipher blocks. (The most commonly used is AES in CBC mode, or eventually in CFB mode). Below, you can see the visualization made with the help of the file2png script: On the left is a BMP file before encryption. And on the right, after encryption by Napoleon:

At the end of each file, we found a unique 384-long block of alphanumeric characters. They represent 192 bytes written in hexadecimal. Most probably this block is the encrypted initialization vector for the particular file):

The ransom note is in HTA format and looks like this:

It also contains a hexadecimal block, which is probably the victim’s key, encrypted with the attackers’ public key.

The GUI of Napoleon looks simplified in comparison to the Blind ransomware. However, the building blocks are the same:

It is common among ransomware authors to prepare a tor-base website that allows automatic processing for payments and better organizes communication with the victim. In this case, the attackers decided to use just an email—probably because they planned for the campaign to be small.

Below is the cache file dropped by the Blind ransomware (the predecessor of Napoleon):

Inside the code

The malware is written in C++. It is not packed by any cryptor.

The execution starts in the function WinMain:

The flow is pretty simple. First, the ransomware checks the privileges with which it runs. If it has sufficient privileges, it deletes shadow copies. Then, it closes processes related to databases—Oracle and SQL Server—so that they will not block access to the database files it wants to encrypt. Next, it goes through the disks and encrypts found files. At the end, it pops up the dropped ransom note in HTA format.

Comparing the code of Napoleon with the code of Blind, we see that not just the extension of encrypted files has has changed, but also many functions inside have been refactored.

This attacker’s public key is later used to encrypt the random key generated for the particular victim. The random key is the one used to encrypt files – after it is used and destroyed, it’s encrypted version is stored in the victim’s ID displayed in the ransom note. Only the attackers, having the private RSA key, are capable to recover it.

The random AES key (32 bit) is generated by the function provided by Crypto++ library:

All the files are encrypted with the same key, however the initialization vector is different for each.

Encrypting single file:

Inside the function denoted as encrypt_file, the crypto is initialized with a new initialization vector:

The fragment of code responsible for setting the IV:

Setting initialization vector:

Encrypting file content:

The same buffer after encryption:

Conclusion

Napoleon ransomware will probably not become a widespread threat. The authors prepared it for small campaigns—lot of data, like email, are hardcoded. It does not come with any external configuration like Cerber that would allow for fast customization.

So far, it seems that the authors fixed the previous bug in Blind of dropping the cache file. That means the ransomware is not decryptable without having the original key. All we can recommend is prevention.