I received a nice spam mail today. Normally the anti-spam plugin on the mail server does a really nice job to filter these out but this one got through. As I had some spare time, I decided to check what’s going on. First look at the mail revealed that it is a malicious downloader. Naturally, I was curious about the payload, so I decided to investigate further.
Here is the screenshot of the e-mail:
After running the JS script in my local VM, I captured the network communication with Wireshark. I must admit, I was too lazy to de-obfuscate the JS itself, I just wanted to know the download URL. In my case it first tried iminlife.com/cqoanbzr and then hrlpk.com/s5ibqz1 which was successful:
The domain itself is compromised and hosts an encrypted version of the payload that was saved under to %AppData%\Local\Temp\XnN52GYn. The script then continues with decrypting the payload to create %AppData%\Local\Temp\XnN52GYn.exe which is the actual Locky executable. The encrypted version if 4 bytes longer than the decrypted executable, so chances are that the decryption key is in the encrypted blob but I did not bother to check. If you would run this executable, it would result in a crash. That is intentional as it expects an argument from the command line to run correctly. Indeed, when I looked at the procmon logs captured during the JS downloader execution, it revealed that the script starts the Locky executable with the command line argument 123. This is a clever way from Locky authors to avoid detection in automated malware analysis systems.
For fun, I decided to run the Locky sample too, just to have a quick look if something changed. I could not observe any obvious changes from previous versions but to be fair I only spent 5 minutes with it. The malware still uses .locky extension for the encrypted files:
Decrypt instructions look pretty much the same:
Locky support a LOT of languages: