Dissection of a Java Malware (JRAT)

Le jeudi, 24 août 2017. Posté dans Blog

Introduction

Recently, Alliacom cybersecurity team has received a Java malware sample with the name of “Scan_20170620_094711_pdf.jar”. The malware is a JAR file that transferred as an attached file in e-mail spam campaigns.

Through the analysis of the malware, it reveals that it is a RAT (Remote Access Trojan) called “JRAT” which is a commercial RAT tool with malicious functions. The fact that the malware is written in Java gives it the ability to run on multiple platforms having JVM (Java Virtual Machine) environment installed.

The malware is composed of two main parts: droppers and the JRAT tool. The droppers are used to decrypt and install the JRAT tool on the target machine.

In the following sections, we focus on how the droppers inside the malware install the RAT tool on the victim machine and our analysis on the RAT tool ending with the conclusion.

Droppers

To evade detections of anti-spam or anti-virus measures, the malware hides its encrypted payloads in files with .tiff extension which is normally used to store graphics images. When the user double-clicks the jar file and in case the JVM environment is installed on the user’s machine, the “main” method in “com.total.Main” class will be executed. The class and resources files in the “Scan_20170620_094711_pdf.jar” are shown in Figure 1.

Figure 1: The file architecture of “Scan_20170620_094711_pdf.jar”

Figure 1: The file architecture of “Scan_20170620_094711_pdf.jar”

 

Actually, the “com.total.Main” class is the first dropper used to decrypt and load other classes from the encrypted .tiff file. This dropper calls later three other droppers and finally install its payload (the real JRAT jar file) on the victim machine as shown in Figure 2.

Figure 2: the process to install JRAT on the target system by droppers

 

Stage 1

After decompiling the java package “com.total”, we find that the main class is obfuscated and implements 71 subclasses within it. To protect itself from being analyzed, the main class uses an object array to hold all data generated in runtime and a long string composing with digital numbers used as indexing in the previous array as shown in Figure 3.

Figure 3: The obfuscated “com.total.Main”

To get a more readable code, we replace the old index values in all occurrences of the object array “N1427_.N1426_[ ]” by a new calculated index values. We find that the “N2327_” class is used to decrypt a .tiff file and to get another class named “qeaqtor.Loader”. The decryption of the class bytecode is simply a XOR operation on each byte of .tiff file (see Figure 4 below).

Figure 4: The byte XOR operation to decrypt another class bytecode from a .tiff

The decrypted “qeaqtor.Loader” class bytecode is then loaded as a java class by calling the “defineClass” method in “java.lang.ClassLoader”. Figure 5 shows that the “go” method in the “qeaqtor.Loader” class is finally invoked.

Figure 5: Triggering “go” method implemented in the loaded “qeaqtor.Loader” class

Stage 2

In the “qeaqtor.Loader” class, three methods named “resource”, “criminal”, “bytes” are related to the decryption of .tiff files.

The decryption process is similar to the one used in stage 1, except for the XOR buffer, which is generated from the combination of class name hash, class name length and a hard-coding seed. After the XOR operation, the buffer is then decompressed as .zip file to get class bytecodes. The main decryption mechanism is implemented in “bytes” method as shown in Figure 6. In total, this dropper loads four new classes and calls the “go” method in the “qeaqtor.Header” class.

Figure 6: The decryption method implemented in “qeaqtor.Loader” class

Stage 3

As shown in Figure 7, the third dropper reuses the decryption method implemented in “qeaqtor.Loader” to load the “operational.Jrat” class from .tiff files, then invokes the “main” method in it.

Figure 7: “operational.Jrat” class is loaded and its “main” method is called.

Stage 4

The final class named “operational.iiiiiiiiii” is decrypted (using the same decryption method as the one in stage 3) in this dropper.  Although it is decrypted as a java class file, it is actually a jar file which contains the JRAT tool.

 

Figure 8: The JRAT tool dropped to disk and ran with java executable

JRAT

The dropped jar file is identified as a commercial RAT tool named “JRAT”. It is composed of a number of files and directories as shown in Figure 9. Most of these files are encrypted. As the JRAT jar has already been analyzed by many other security analysts [1], we know that the RAT jar has also a dropper to drop the real payload. Using the decryption tool available on the github [2], it is possible to manually obtain the dropped payload which consists of files shown in Figure 10.


Figure 9: Files and directories in JRAT.jar


Figure 10: Real payload dropped by the JRAT jar

 

Table 1: JAR files written to the disk

Conclusion

As shown in our analysis, the malware is probably developed based on the commercial RAT tool called JRAT written in Java. The Cybercriminals added multiple protection layers to avoid detection by anti-spam products. However, the dropped JRAT is easily detected by anti-virus products based on its signature since the malware writes them directly on the disk.

References:

[1] https://www.codemetrix.net/decrypting-adwind-jrat-jbifrost-trojan/

[2] https://github.com/mhelwig/adwind-decryptor

Rédigé par : Xu Jianqiao