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.
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:
As usual, having a process named VBoxService in the background is a great way to save PC from infection.
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.
Finally, ransom message is shown and files from %TEMP% are removed again:
Sample hash: 1817853fdaf2d35988ca22a6db2c939e0f56664576593d325cfd67d24e8fb75c
Ransom email: [email protected]
Extension after encryption: .file0locked