The executable file sample can be found at app.any.run.
Hash of the executable sample :
Indicators of Compromise:
1. Drops jar files in different directories based on Operating System
Desktop/01082019_docx.jar (all other OS)
2. Creates Persistence by modifying registry:
3. Connects to a URL using unusual port:
134[.]19[.]176[.]26 on port 3260.
Decompiling the sample using JD-GUI it is found the sample is obfuscated and is unreadable. So we run strings to see what we get.
The last line of strings output suggests the sample is obfuscated using Allatori Obfuscator. A quick search on Allatori Obfuscator suggests there are tools available to deobfuscate the sample.
I made use of Java byte-code analysis/deobfuscation tool from contra and deobfuscated the sample.
Now let’s load it on Java Decompiler and figure out the main class. The class names are still obfuscated and is almost impossible to deobfuscate. The main class is iiIIiiiiii as generated by Allatori Obfuscator.
Now navigating to the main class we can see all the imports to the sample jar.
Looking at the imports we can say the sample jar has ability to read/write files, connect to a URL, Encrypt/Decrypt files and display Graphical user interface. Looking further into the decompiled code we see the sample tries to detect the underlying operating system and assigns a unique id based on the operating system.
Depending upon the underlying operating system the sample looks for the hosts file which contains the mapping of IP address to Hostnames and writes it to host.dat for temporary access.
It then drops executable jar payload in several locations based on the underlying operating system using the following code segment. Notice that this code segment is just creating files and the files are empty.
Now we know the files are dropped in various locations there must be some logic to inject bytecode to the dropped files. We noticed there are two unusual files in the resource of the sample named e and k. And the code reads 16 bytes at a time from those two files and loads it in localObject1 and localInputStream1 using getResourceAsStream() method.
Further analysis of the code reveals the file e contains AES encrypted bytecode. The AES cipher is then initialized and 16 byte(128 bits) key is read from the file k. The bytecode it then decrypted and injected into the files that are dropped in various locations.
It then hides the actual payload file which is the actual RAT(Remote Access Tool) using attrib -h in windows and concatenates dot(.) before filename for other operating systems which does the same.
The sample then creates a persistence for the dropped payload using registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run and executes the actual payload using Runtime.getRuntime().exec();
This runs the actual Jacksbot RAT(Remote Access Tool), which communicates with attackers Command and Control servers.
The file also tries to gain superuser access using some common methods which invokes the User Account Control.
The sample also declares registry access methods and has a capability to open, close, query, create, delete registry keys.
During our dynamic analysis we found that the RAT will not execute if it detects the presence of tools used for analysis such as ProcMon, API Monitor, etc. However using wireshark we were able to find the command and control server’s IP address that the malware tries to communicate with. The IP used by the sample was
The sample uses base64 encoder and decoder to encode and decode the network traffic from and to the C&C server which might be further encrypted using AES encryption scheme.
The java jacksbot has a limited set of commands. However those commands are enough to disrupt the services or steal sensitive information from the infected machine. Some C&C commands associated with JacksBot are:
Stay tuned for more analysis and other amazing stuff. If you love and support my work use the below link to buy me a coffee and help me with my research.