Deobfuscating the Nemucod Downloader Script

Matt Decker from sent me this script he received via email and asked for help deobfuscating this so here we go…

Here’s the WSF file he sent me:


About half-way down the script, I come across this. Two variables should have caught your eye.


Doing a search for the first variable name, I end up at the variable “vista” which references that blob and then the function is immediately called.


To view the value of “vista”, I do this. I don’t want the script to run any further so I do a quit right after the popup.


And this is what I get. It shows several functions like reading and writing to a file and three conversion functions. This decrypts the download file which I’ll get to in a bit.


Searching for the other variable, brings us here. It’s inside of a for-loop and the variable “efioppocsonny5HORDA6” appears to be building up URLs then calling a function named “efioppocsonny5_a2”. Notice that the URLs are being passed in the first argument.


Now let’s search for this function. It’s going back up to here. Based on what’s in the function, it looks like it’s preparing and making AJAX calls.


So our goal is to see the URLs and block the HTTP request for now. Here’s the changes I make.


When I run it, I get the URLs one at a time.


If you want to pull down the payload then search for “.Run” and comment out that line so the payload won’t execute and interrupt our analysis.


Based on the script, it will download and save a file into the Temp folder, read it in, decode it, write it out to a DLL file, then execute it. However, this particular script doesn’t seem to have domains that answer so I have to find another script with live domains.

Here’s another one I got from VirusTotal Intelligence:


And make the same change.


This time I get the payload, the script decodes it then writes it out to a DLL file which turns out to be Locky/Odin.


Let’s have a look at the original downloaded file and the DLL file from the Temp folder. I wrote this program to analyze the files. I load up the binary files into each input box (only the first 1,024 bytes are read to save time).


Then I choose the “XOR” method as my first guess.


I get this result. Do you see a pattern in the output box?


How about now?


I can use Converter to XOR the original file using the same XOR pattern (converted to hex).


And get the same result as the original.


Now let’s see if we can find this in the script. Near the bottom there’s a long string that gets sent to the function VGRA3 (that function is from the blob we deobfuscated earlier). Then later when the payload is downloaded, the variable holding this key is used to XOR the file. It’s the same string.


We’re done!

But I did want to show you another related script I found. It’s basically the same as the one above, however, the JScript is inside of an HTML file. This is an important distinction because we have to deobfuscate this differently.


At the bottom of the script, we see that it’s functionally similar to the script we just looked at. Do you see that function call at the “if” statement? Let’s search for that. By the way, the blue arrow is pointing to the XOR key.


Here’s the function that takes in some arguments passed from the call at the bottom. The first argument is the URLs just like the previous script.


If I search for the variable name, we see that there’s two other variables prepending it.


Let’s see what these three variables are by adding the following line then have it stop running the rest of the script. Notice I have to use “alert” and “stop” instead of “WScript.Echo” and “WScript.Quit”.


Now I can execute the script by running it in IE. You can’t use another browser because this script uses an ActiveX control.


You can continue to alert on variables to better understand what it’s doing but you’ll find that it’s doing the same thing as the WSF script from above.

Good luck!

This entry was posted in Malscript, Tools and tagged , , , , , , . Bookmark the permalink.