Evil: A poor man’s ransomware in JavaScript

Date of publication: 18/01/2017, Jarosław Jedynak



Initially Evil was brought to our attention by an incident reported on 2017-01-08. By that time the Internet was completely silent on that threat and we had nothing to analyze.

We found first working sample day later, on 2017-01-09. In this article we will shortly summarize our analysis and conclusions. Since then, we had relatively high number of infections reported, so we predict that this family of ransomware may become a bigger threat in near future.

This malware follows recent trend, and doesn’t have any decryption panel (like CryptoMix) – instead of this, an email address is provided. Sure, why complicate things if simple solutions work good enough.


World changes and so does malware. This specific sample is interesting because it is coded 100% in javascript. This isn’t completely new (Ransom32 did it half a year ago), but unusual. Is it the future? We don’t know, but it certainly simplifies our work.

But some things are problematic to do in javascript, so malware authors resorted to external programs. A picture is worth a thousand words, so let’s look at the process tree:


As we can see, firstly every executable file is removed from %TEMP% and %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup folders. This is probably to complicate analysis and recovery of the sample and to remove other malicious files that could be installed on victim’s machine.

After that, a list of files to be encrypted is generated using dir /b /s /x command (!), and then all files from that list are encrypted using a mysterious 443.exe program. This program turned out to be AESCrypt – encryption is hard, so criminals increasingly often resort to use ready-made solutions. Finally, ransom message is shown (using default browser), and that’s basically everything.

The only thing left to be answered now, is how is the encryption key generated? The reason is that weak key generation could allow us to recover encrypted data.

The code is heavily obfuscated, so we can’t understand it straight away. Snippet of the code:

But we were able to deobfuscate this (using modified mak’s script we shared in an earlier article: https://www.cert.pl/en/news/single/newest-addition-a-happy-family-kbot/) and get relatively clean looking code.

Basically, everything is the same thing we deduced from process tree alone:

    • Removing files from directories:

    • Generation of file list:

    • A bit of antidbg

As usual, having a process named VBoxService in the background is a great way to save PC from infection.

    • Key generation

And now for the interesting part, key generation and encryption:

Tough luck – looks like the key is not generated on the client side, but sent from the server (in an X-Token header). This is problematic because there is no way we could predict it.

    • Final cleanup

Finally, ransom message is shown and files from %TEMP% are removed again:

Other information

Sample hash: 1817853fdaf2d35988ca22a6db2c939e0f56664576593d325cfd67d24e8fb75c

Ransom email: [email protected]

Encrypted extensions:

Extension after encryption: .file0locked

Ransom message: