In Bad Company: JScript RAT and CobaltStrike

06/06/2024
G DATA Blog

Remote Access Trojans (RATs) that are based in JScript are gaining traction. We have looked at a recent example that emerged in mid-May. It turns out that this RAT has some companions on the way that we are familiar with.

A few weeks ago, Ksenia posted on Twitter about a potential new JScript based RAT. We delved deeper into the case and offer our analysis in this article. 

Attack overview

The attack pattern is illustrated below. Over the past years, it has been noted that JScript based RATs have often been distributed via phishing campaigns. We suspect that this attack uses the same technique. Once the initial loader script is executed, it contacts a command and control (C&C) server, which responds with a new malicious script. This is the second stage loader and is executed on the fly. The second stage loader communicates with the C&C server to get the RAT component, once again scripted with JScript. The RAT component has the capability to continue running until directed to stop, and execute additional commands received from the C&C server. 

The initial loader

The initial loader is obfuscated. The obfuscation and execution flow are rudimentary. 

  • Initially, a blob of obfuscated code is deobfuscated. It contains a function object for the eval function. 
  •  Then the obfuscation proceeds to decrypt a string with XOR key. 

  •  The decrypted string is indeed another piece of JScript which would then be executed via the previously obtained eval function. 

  • It then sends a XMLHttpRequest to the C&C server and executes the received response as a script. 

  • The URL path for C&C ends with ‘/stage’, suggesting that this could be a preliminary step before the actual deployment of the malware. 

The second stage

 The second stage loader can be described as follows: 

  • Obfuscated in the same manner as the initial loader 

  • While the initial loader makes a XMLHttpRequest to receive a response, the second stage loader employs a WinHttpRequest to contact the C&C server to determine the next course of action. 

  • This time around the response is a binary stream which turns out to be RC4 encrypted. 

  • The reason behind using WinHttpRequest might simply be because of the ease of using it to deal with the binary response. 

  • The script decrypts the content with a hardcoded key and the resulting JScript is then once again executed on the fly. 

  • The next stage URL ends with ‘/rat/’ hinting at the fact that the decrypted script is indeed the main Remote Administration Tool (RAT) component. 

The RAT component

The main body of the RAT can be seen in the image below. 

  • The main body implements an infinite loop to keep polling the C&C server for further commands. 

  • The body ensures a random amount of pause between polling by implementing a simple ‘Sleep’ functionality (See image)

  • The script contacts the C&C server to obtain a session identifier and uses it for further communications with the server. 

  • Requests are RC4 encrypted and then base64 encoded before being sent to the C&C server. 

  • Responses are RC4 encrypted as well. They are then decrypted by the script and executed as script entities. 

What is known - and what is not

  • The C&C server was not active at the time of this research. Therefore, further command capabilities could not be documented in this article. 

  • Ksenia reported about this case in May 2024. We investigated further using the “RetroHunt” tool on Virustotal and found similar cases starting from February 2024. Following the trail of other servers proved unsuccessful. 

  • Incidentally, the C&C server we found appeared to be operating a CobaltStrike server 

  • While the C&C server in this case was in the public IP range, a few other cases that we discovered on Virustotal appeared to have a local IP range (192.168.XXX.XXX). We can offer two potential reasons for this: There could be instances of simulated attacks as part of red team exercises in the sample set. Alternatively, the presence of private IPs in earlier cases might stem from internal tests of the malware that were performed by the threat actors. 

Sample used in this analysis

B3c38e68a626f8f1e5893cd157b697a4b871153230f6658f0d34a8eba929cdbf 

Other, similar samples

 c1f3e0ac0304f947fdd617c3972f4388c13cd23639f486d530ab1b3a5d5f971f 
76aa4f684481d2072ce85d80b14a2660bc912dcc47c787faad44cc21f01d7b9a 
87852d6fdfe29086212810bf0f8e769bac46ad462cab145bf5543eab988c7d3b