Concerned about recent PAN-OS and other firewall/VPN CVEs? Take advantage of Zscaler’s special offer today

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

Targeted Attacks on Indian Government and Financial Institutions Using the JsOutProx RAT

May 11, 2020 - 11 min read

It is not uncommon for cybercriminals to target specific countries or regions. They often employ this strategy

In April 2020, ThreatLabZ observed several instances of targeted attacks on Indian government establishments and the banking sector. Emails were sent to organisations, such as the Reserve Bank of India (RBI), IDBI Bank, the Department of Refinance (DOR) within the National Bank for Agriculture and Rural Development (NABARD) in India with archive file attachments containing JavaScript and Java-based backdoors.

Further analysis of the JavaScript-based backdoor led us to correlate it to the JsOutProx RAT, which was used for the first time by a threat actor in December 2019 as mentioned by Yoroi.

The Java-based RAT provided functionalities similar to the JavaScript-based backdoor in this attack.

In this blog, we describe in detail the email attack vector of this targeted campaign, the technical analysis of the discovered backdoors, and our conclusions on this attack.


Email analysis

Below is the email that was sent to the government officials in NABARD, which contained a malicious archive file attachment.



Figure 1: Email sent with malicious attachment to NABARD.

The email attachment filename is:

This archive contains an HTA file inside it that performs the malicious activities.

The MD5 hash of the HTA file is: 23b32dce9e3a7c1af4534fe9cf7f461e

The theme of the email is related to KCC Saturation, which relates to the Kisan Credit Card scheme and is detailed on the official website of NABARD.

Attackers leveraged this theme because it is relevant to the Department of Refinance, making this email look more legitimate.

We used the email headers to trace the origin to, which is a hosting provider in Poland as shown below:

X-Auth-ID: [email protected]

Received: by (Authenticated sender: with ESMTPSA id 0928BE00BD;

         Mon, 20 Apr 2020 21:33:53 -0400 (EDT)

X-Sender-Id: [email protected]

Received: from WINDEB0UPGVCUK ( [])

         (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384)

         by (trex/5.7.12);

         Mon, 20 Apr 2020 21:34:40 -0400

The same HTML Application (HTA) file was also sent in an archive attachment to IDBI bank as shown in Figure 2.

IDBI Email

Figure 2: The email sent with a malicious attachment to IDBI bank.

Based on the email headers and the infrastructure used to send the previous emails, we were able to identify more instances of these attacks and were able to attribute them to the same threat actor.

Figure 3 shows an email sent to RBI with an archive file that contains a Java-based backdoor.

RBI Email

Figure 3: The email sent with a malicious attachment to RBI.

Figure 4 shows an email that was used to send an archive file with a Java-based backdoor to Agriculture Insurance Company of India (AIC).


AIC of India

Figure 4: The email sent with a malicious attachment to AIC India.

The contents of the email are in the Hindi language.

In both of the cases above, the Java-based backdoor has the same hash and only the filenames used were different.

The hash of the JAR file is: 0ac306c29fde5e710ae5d022d78769f6


Technical analysis of JsOutProx

The MD5 hash of the HTA file is: 23b32dce9e3a7c1af4534fe9cf7f461e

Upon execution, the HTA file displays junk data in a window that flashes quickly on the screen before auto-closing.

This HTA file contains a JavaScript that is executed by mshta as can be seen in the file header in Figure 5.

HTA header

Figure 5: The HTA header in the file.

There is a long array of encoded strings present at the beginning of the JavaScript as shown in Figure 6.

Array of encoded strings.

Figure 6: A long array of encoded strings.

This array of strings will be referenced throughout the JavaScript. They are base64 decoded and RC4 decrypted at runtime at the time of execution.

JavaScript code in this HTA file is heavily obfuscated as shown in Figure 7.

Obfuscated JavaScript code.

Figure 7: The heavily obfuscated JavaScript code.

The string decoding and decryption routines are shown in Figure 8.

String decoding and decryption routine.

Figure 8: The string decoding and decryption routines.

After analyzing the string decryption routine, we can see that RC4 algorithm was used.

The process of string decryption can be summarized in the following steps:

  1. The string decryption routines are invoked with calls such as: b(‘0x4’, ‘qP52’). The first parameter is the index of the encoded string in the long array declared at the beginning of the JavaScript. The second parameter is the RC4 decryption key.
  2. The string is base64 decoded using atob() JavaScript function.
  3. An S-box is generated using a for loop to generate the sequence: 0x0 to 0x100.
  4. S-box is permutated using the decryption key.
  5. The permutated S-box is used to perform XOR decryption of the encrypted string.

After decrypting all the strings in this JavaScript, we can see the main configuration as shown in Figure 9.

Config file of JSOutProx.

Figure 9: The main configuration file of the JsOutProx backdoor.

Some of the critical parameters in the above config file are:

  1. BaseURL: This is the C2 communication URL. In this case, it makes use of Dynamic DNS (* and a non-standard port.
  2. Delimiter: This is the delimiter that will be used while exfiltrating information about the system.
  3. SleepTime: The duration for which the execution needs to be delayed.
  4. Delay: Similar to the SleepTime parameter.
  5. Tag: This is a unique indicator that is appended to the data during exfiltration. In this case the tag is: Vaster. The first time this JavaScript based backdoor was discovered in December 2019, the value of this tag was: JsOutProx.
  6. IDPrefix: This parameter corresponds to the Cookie name that will be set in the HTTP POST request sent by the backdoor to the C2 server at the time of initialization.
  7. RunSubKey: This is the Windows Registry Key that will be used for persistence on the machine.

The script checks whether it is being executed by mshta, wscript or by an ASP Server as shown in Figure 10.

Check source of execution.

Figure 10: Checks for source of execution.

This also indicates that the script has the capability to execute in different environments, including web servers. The first instance of JsOutProx discovered in December 2019 was a JavaScript file. The instance we discovered in April 2020 was an HTA file with the JavaScript code obfuscated and embedded inside. So we are observing this threat actor deploy the backdoor using different methods in the wild.

The script also has the ability to delay execution as shown in Figure 11.

Delaying execution methods.

Figure 11: Delaying execution.

The init() routine is the initialization routine, which gathers different types of information from the system and sends it in an HTTP POST request to the C2 server as shown in Figure 12.

Init routine.

Figure 12: The main initialization routine.

The individual fields collected during init() routine are:

Volume serial number: Fetches the volume serial number using WMI query: “select * from win32_logicaldisk” by inspecting the volumeSerialNumber field.

UUID: This is randomly generated using the getUUID function in the script. The format of the UUID used is: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

ComputerName: Host name of the machine.

UserName: User name of the machine on which this script is executing.

OS caption: This value is fetched using the WMI query: “select * from win32_operatingsystem” by inspecting the Caption field.

OS version: This information is also gathered using WMI query similar to OS caption.

Tag: This is the tag defined in the configuration of the backdoor. In our case, the tag is Vaster.

The last keyword is “ping,” which is added by the receive() method.

All these values are separated by the delimiter “_|_” and concatenated, then hex encoded and set in the Cookie header called “_giks” of the HTTP POST request sent to the C2 server as shown in Figure 13.


Figure 13: First HTTP POST request sent to the C2 server.

The command and control communication between the backdoor and the C2 server is synchronized using the Cookie in the HTTP request and responses.

The last field in the cookie indicates the type of client command.

For example, if the cookie is:

Cookie: _giks=46464646464646465f7c5f65363261396233322d323434352d346166612d393233622d3836653530306530363665655f7c5f486f73746e616d655f7c5f41646d696e6973747261746f725f7c5f4f535f4e616d655f7c5f56657273696f6e5f7c5f5661737465725f7c5f70696e67

Then the client command can be identified as:

  1. Hex decode the cookie to get: FFFFFFFF_|_e62a9b32-2445-4afa-923b-86e500e066ee_|_Hostname_|_Administrator_|_OS_Name_|_Version_|_Vaster_|_ping
  2. Split the decoded content using the delimiter: “_|_” to get: ['FFFFFFFF', 'e62a9b32-2445-4afa-923b-86e500e066ee', 'Hostname', 'Administrator', 'OS_Name', 'Version', 'Vaster', 'ping']
  3. Extract the last field from the above list. In this case the command is: ping.

Figure 14 shows the main subroutine in the code that handles all the commands.

JSOutProx C2 Commands.

Figure 14: The C2 command handler subroutine in JsOutProx.

The description of the commands are included in the table below.





Download and execute the script.


Re-launch the script.


Similar to rst command.


Exit the execution.


Reboot the system.


Shutdown the system.


Shutdown the system.


Use eval() to execute the JavaScript sent by server.


Use ActiveXObject to execute the VBScript sent by server.


Uninstall the backdoor.


Install the backdoor.


Invokes the File Plugin.


Invokes the Download Plugin.


Invokes the ScreenPShellPlugin.


Invokes the ShellPlugin.


Technical analysis of the Java-based backdoor

The MD5 hash of the JAR file is: 0ac306c29fde5e710ae5d022d78769f6

The JAR file is heavily obfuscated in this case. The structure of the JAR file is shown in Figure 15.

JAR file structure in stage 1

Figure 15: The JAR file structure.

There is an AES-encrypted resource present in this JAR file with the name: “jkgdlfhggf.bvl”.

This resource will be loaded and decrypted at runtime as shown in Figure 16.

Stage 1 resource decryption.

Figure 16: The Stage 1 resource decryption routine.

This resource gets decrypted to another JAR file, which will be dropped in the %appdata% directory on the machine with the name jhkgdldsgf.jar

The dropped JAR file contains all the functionality for this Java-based backdoor. Figure 17 shows the main structure of the JAR file.

JAR file structure in stage 2.

Figure 17: The JAR file structure of the Java-based backdoor.

All the strings in this JAR file are obfuscated by an obfuscator called Allatori. The string decryption routine is as shown in Figure 18.

Stage 2 string decryption routine.

Figure 18: The string decryption routine.

We described this string decryption routine in more details in an earlier blog, which also includes the Python implementation of the decryption routine.

The JAR file connects to the C&C server: at port 9050.

This Java-based backdoor is modular in structure and contains several plugins. Figure 19 shows the main network controller code that handles the C&C communication and dispatches the commands to corresponding plugins for further processing.

Network controller commands.

Figure 19: The network controller command handler.

The controller receives the command along with an array of strings that represent the parameters for the corresponding command.

Each of the C&C commands are used to invoke a plugin that executes the command sent by the server.



Invoked Plugin


Screen plugin.


Log plugin.


Command plugin.


Downloader plugin.


Filemanager plugin.


Startup plugin.


Base plugin to exit execution.


Base plugin to restart execution.


Now, we will describe two main plugins in this Java-based backdoor and the commands processed by them.

Filemanager plugin: This plugin is responsible for managing all the file system related actions which can be performed by the attacker remotely. The plugin supports multiple commands and the summary is in the table below.


Plugin command



Get list of system drives (including CD drive.)


Get list of files and folders in a directory.


Create a new directory.


Execute a command using Runtime.getRuntime().exec()

Start a new system shell based on the type of OS.


Copy contents of one file to another.


Change the permissions of a file using chmod command (only for Linux and Mac).

Move a file from one location to another.


Delete a file.

Rename a file.


Similar to chm command.


Download a file from the system. Contents of the file are Gzip compressed and Base64 encoded before downloading.


Upload a file to the system. Contents of the file Gzip decompressed and Base64 decoded before dropping on the file system.


Screen Plugin: This plugin uses the java.Awt.Robot class to perform all the mouse and keyboard simulations on the machine as well as to take screen captures. The commands for this plugin are detailed in the table below.


Plugin Command



Fetch the screen size width and height information.

Simulate mouse actions like double click, scroll up and scroll down.

Move the mouse cursor to specified co-ordinates.


Take a screen capture.

Send keystrokes to the machine.


Persistence: To ensure that this JAR file is executed automatically when the system reboots, a Window run registry key is created as shown below:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v jhkgdldsgf /d '\'C:\Program Files\Java\jre1.8.0_131\bin\javaw.exe\' -jar \'C:\Users\user\AppData\Roaming\jhkgdldsgf.jar\'' /f


Cloud Sandbox detection

Figure 20 shows the Zscaler Cloud Sandbox successfully detecting the Java-based backdoor.

Cloud Sandbox Detection for Java-based backdoor.

Figure 20: The Zscaler Cloud Sandbox detection for this Java-based backdoor.

Figure 21 shows the Zscaler Cloud Sandbox successfully detecting the HTA-based backdoor which contains the JsOutProx RAT.

Cloud Sandbox Detection for HTA-based backdoor.

Figure 21: The Zscaler Cloud Sandbox detection for the HTA-based backdoor.



This threat actor has a specific interest in organisations located in India and the content of the emails indicates a good knowledge of topics relevant to each of the targeted organisations. The backdoors used in this attack are uncommon, such as JsOutProx, which has only been observed in the wild once before in December 2019.

The Zscaler ThreatLabZ team will continue to monitor this campaign, as well as others, to help keep our customers safe.






Obfuscated Files or Information - T1027

Software Packing



Registry run keys / Startup folder - T1060

Screen Capture


System Shutdown/Reboot




File and Directory Discovery


Uncommonly Used Port


Windows Management Instrumentation



Indicators of Compromise (IOCs)


23b32dce9e3a7c1af4534fe9cf7f461e – HTA file (JSOutProx)

0ac306c29fde5e710ae5d022d78769f6 – Java-based Backdoor

Network indicators



form submtited
Thank you for reading

Was this post useful?

dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.