Telsacrypt 4.0: In-depth analysis of a weaponised JS

TelsaCrypt 4.0 is being delivered through various
means like spam email, Angler EK and one of the vectors is that a weaponised js
or vbs file is delivered inside archive files through various channels
including emails and infected downloads.

The weaponised script has various levels of obfuscation and
several function calls to formulate the malicious URL and also to formulate the
calls to create various ActiveX objects. The attacker is relying on the social
engineering technique to convince user to double click and execute the
javascript file in the downloaded archive, which would be executed in the
context of windows scripting host and download the malicious Telsacrypt binary
and run it.

I had to fix the script for it to run and so that I could
debug it.

Got this error message because this script was intended to
run using the windows script host (wscript or cscript) and not in the IE script
interpreter context. So it threw this error:

So I had to locate this in the script and change it to new ActiveXObject instead of WScript.CreateObject:

Secondly I was getting this error while reaching to a point
whereby ADODB.Stream object was being created, most probably to write binary
bytes (the downloaded Telsacrypt binary):

I had to remove this registry entry which basically blocks
the automation server to create this object for security reasons:

Once I removed this registry key and restarted the computer
then this error was fixed and I was able to proceed:

I copied the notepad.exe to the honeypot server web server
directory, renamed it to 70.exe and started the web server and fakedns on the
honeypot in order to intercept the DNS and GET requests and provision the
payload (70.exe):

We start debugging the script. After URL deobfuscation we
see that WScript.Shell ActiveX object is created

We see that this object is used to get hold of the TEMP
environment string and placed in an array and returned:

The URLs:

The acquried value for the TEMP env variable:

This is one of the techniques usually the malicious script breakdown
suspicious strings so that they could evade the AV or other malicious script
behavior identification engines in form of addins/plugins:

Next we see another ActiveX object being created to access
the file system on the local machine:

A folder is created in the temp folder:

Next we see another ActiveX object being created
MSMXML2.XMLHTTP for communicating with the malicious URLs:

Next we see the ActiveX object created for writing locally
binary file:

There is a loop which iterates through values and perform
GET request and in case of failure catches the exception and go back to the
loop until the malicious URL is acquired:

The loop:

The GET Request

Exception handling:

Success:

We see some hex strings used to create string
"send" for the HTTPRequest object:

As soon as the request is "Send", we see following
traffic in Wireshark:

WE also see at the end of honeypot fakedns that the DNS
request was intercepted:

We see transmission of 70.exe (the notepad.exe which we
copied to the honeypot webserver root), from honeypot to the infected system.
We can see the PE header "MZ" in the traffic payload:

We see that the response is 200 OK and the finishing off the
TCP session:

We can see the response object in the javascript, which is
not yet written to a file in the TEMP directory:

A creepy way to check whether the response status is 200
(534-334) or not:

Next we see opening of the object stream (the response):

Next we see that the type of the stream is set to 1 (binary)
from 2 (text):

Next the responsebody is acquired:

Another tricky way to write the responsebody to a binary
object "mFsXb", using hex representation, array objects:

Next the size of the binary response is acquired:

As expected this size is checked if it is greater than 186975:

In our case this will still hold true and next we see the
70.exe (notepad.exe) being written to the TEMP folder as another binary:

Next we see the initial position (0) of the object stream
being acquired:

Next we see the object stream saving to the file:

We see the file created in
the TEMP folder:

Next another ActiveX object Wscript.Shell is created, most
probably to execute the downloaded file: