Saturday, April 16, 2016

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:

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:


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:

Saturday, April 9, 2016

Python web scraping OSCTI

Essentially Python scripts can be used to scrape a bunch of open source cyber threat intelligence sources like, to extract easy low level IOCs (lower in the IOCs pyramid of pain) and make this raw output available to be consumed by both inline solutions (NGFW, NGIPS, etc) as well as monitoring solutions infrastructure like SIEM. The raw output could be formatted into CEF and streamed as syslogs or in simple formats such as XML, csv etc

With rising deployments of Endpoint Detection and Response (EDR) aka the next generation endpoint security solution, this kind of raw output could also be formatted into yara rules or some other format which can be consumed by these EDR solutions.

A typical methodology could be to first visit the source which need to be scraped and use the web browser to inspect the page structure by looking into the HTML tag tree structure

Once the structure is analyzed, we can begin coding. We will rely on two common Python packages to do the heavy lifting, Requests and Beautiful Soup.

Check the documentation out at:

We need to load the page by requesting (request.get). The request once received is parsed using BeautifulSoup(r.text). Once the HTML is parsed we can simply look for the relevant tag within which the IOCs of interests are enclosed. In our case we are looking specifically for malicious ip addresses.

Once the strings of the parsed <td> tags are acquired. It is iterated and ip addresses are extracted from the array

We do the same thing for all the remaining 32 pages by observing the URL structure and iterate through all of the pages by replacing the parameter in the URL with a number in the range. Here I have hard coded the number 33 as I saw there are 33 pages of data in the source. However, this range could be made dynamic by scraping the last page number on the first page using similar method as above and using that for the page iteration loop.

Another point to note is that once this list is consumed by SIEM etc, then the script can be modified to generate the raw feed based on date/time stamp so that data duplication does not occur. This would require to also inspect the date/time stamp <td> item.