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.

Interesting Related Read:

https://heimdalsecurity.com/blog/security-alert-teslacrypt-infections-rise-spam-campaign-hits-companies-europe/

https://www.fireeye.com/blog/threat-research/2015/05/teslacrypt_followin.html

http://www.antiy.net/wp-content/uploads/TECHNOLOGICAL-AND-CHARACTERISTIC-ANALYSIS-OF-NEW-VARIANT-OF-RANSOMWARE-FAMILY-TESLACRYPT.pdf

Threat Intel:

File Name: 70.exe in random folder under appdata temp folder

Malicious Domains Contacted: marvellrulesqq(dot)com, marvellrulescc(dot)asia

Analysis of the weaponised java script:

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:

The object is used to run the ransomware binary: