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:
The first look at this e-mail should immediately raise alerts, at least the archive icon of the attachment is very suspicious. The attachment was a ZIP file that contained a single JavaScript file named addition-XXX.js (XXX is a random number). I unpacked the .js file and submitted it to my favorite sandbox that I use frequently when I’m too lazy to do the analysis myself. Unexpectedly, the analysis ended with an error:
This was weird, so I decided to try to run it in my local VM and to my surprise it worked. After some digging I found that the main difference between the sandbox and my local VM was the version of JavaScript interpreter. The local VM had a newer version whereas the Sandbox had an older one (for obvious reasons). I don’t know if the authors of this JS downloader did this on purpose or just a coincidence, but if you happen to have an older version of IE on your system, you are most likely protected from this downloader 😀
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:
Conclusion:
Locky is back after a 3 week hiatus. It seems that not much changed during this period. The distribution path is the same and there doesn’t seem to be any major changes in the payload itself. I kept this article really short because since yesterday there are a lot of other more detailed descriptions out there. Take care and don’t open JavaScript archived in mail attachments 🙂