From a fake wallet to a JRAT

This malware came in a phishing e-mail – disguised as a Bitcoin wallet. After clicking the link, user receives a JAR file: wallet.aes.json.jar



Analyzed sample

  • 851bc674d181910870fbba24763d5348 – the dropped sample (wallet.aes.json.jar)
    • 2eb123e43971eb2eaf437eaeffeeed8e – stage 2
      • 24840e382da8d1709647ee18e33b63f9 – stage 3 (core)

Behavioral analysis

After being deployed, the malware runs silently. If we observe it via Process Explorer, we can spot it deploying some scripts.


Indeed, during the installation some new files are being dropped into the %TEMP% folder: vbs scripts, reg file for the registry modification, and a DLL.


The vbs scripts are used to detect installed security products (AV, firewall) and they are deleted immediately after being deployed. Example of the captured script:

Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\.rootSecurityCenter2")
Set colItems = oWMI.ExecQuery("Select * from FirewallProduct")
For Each objItem in colItems
  With objItem
    WScript.Echo  "{""FIREWALL"":""" & .displayName & """}"
  End With

The application installs itself as a hidden file in a hidden folder. After disabling the attribute we can see the jar, copied as Windows.Windows:


Persistence is achieved with the help of a registry key:


The first visible symptom of infection is an attempt of running the reg file that triggers UAC popup. If we accept it, soon we can see another pop-up informing about UAC being disabled.

The malware establishes connection with the server: (


Fragment of the captured communication:



This malware comes solidly obfuscated. There are three jars nested one in another. Two inner JARs were encrypted using strong cryptography (RSA + AES). The last (third) layer is a core module – the jRAT.

Stage 1

Trying to decompile the code (i.e. with the help of JD-GUI) we can notice that it is not readable. As we can find by reading strings, it has been obfuscated by Allatori Obfuscator v6.0 DEMO.

Fortunately, using this free java deobfuscator ( it was possible to get some improvement. Example of the settings used:

java -jar deobfuscator-1.0.0.jar -input wallet.aes.json.jar 
-output deobfuscated.jar 
-transformer general.SyntheticBridgeTransformer 
-path /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar

However, even after preprocessing by the deobfuscator, the popular decompiler JD-GUI (and some other) were not able to give a valid output code. Finally, I managed to get a valid code with the help of CFR decompiler ( In order to unpack other files, like resources from inside of the jar, I changed it’s extension to zip and decompressed it.


Manifest points, that execution of the code starts from the class MANAGER:


In the main folder, we can see several other classes with obfuscated names. There are also 2 subfolders. Opening them leads to some encrypted files, as well as two identical JPEGs with the following content:


Although their content is curious (it is a photo of a document, probably a driving license) – they are most likely added just as junk for the purpose of obfuscation.

The deobfuscated code still needed a lot of manual cleaning before it started getting a readable shape. Not only classes, but also all the strings are obfuscated.
After all, we could find out, that first some file is being decrypted. It’s path and the used key are stored in the class called i:

public final class i {
    public static String b = c.a(f.a("t'VdU:t/b;H,"));
    public static String a = c.a(f.a("J U{u0015$C'B @"T$Q'"));

The same class after manual deobfuscation:

public final class i {
    public static String key = "lks03oeldkfirowl";
    public static String path = "/lp/sq/d.png";

Decryption involves two steps, executed by two classes:

byte []dec_content = b.a(c.a(input_data, key.getBytes()));

See the full decryptor:

The result is an XML file:

The file has lot of junk fields, that are used only to make the content less readable. Only two fields are used further:


First field – SERVER – refers to a resource path containing one more encrypted fie. Second field – PASSWORD – is an AES key.
The used algorithms are exactly the same like in the previous case. After applying them, we get another JAR – stage 2.

Stage 2

Similarly, I cleaned the jar by the same deobfuscator. Then, I decompressed the jar to view resources.


The execution starts in a class JRat in the folder operational:


Even after cleaning by the automated deobfuscator, the code is still far from being readable. (You can see it here).

Finally, after manual refactoring we can find out, that this is just another loader, meant to unpack next stage JAR and then to run it.

Deobfuscated decryptor class:

package w;

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

public class kyl {
    private byte[] encryptedAesKey;
    private byte[] encryptedBuffer;
    private static int mode = javax.crypto.Cipher.DECRYPT_MODE;

    public kyl() { }
    public void setEncryptedBuffer(byte[] value) {
    this.encryptedBuffer = value;
    public void setEncryptedAesKey(byte[] value) {
    this.encryptedAesKey = value;
    public byte[] decryptContent(Object object2) throws GeneralSecurityException {
        Cipher object = Cipher.getInstance("RSA");
        object.init(2, (RSAPrivateKey)object2);
        Cipher cipher2 = Cipher.getInstance("AES");
        byte []aesDecrypted = object.doFinal(this.encryptedAesKey);    
        SecretKeySpec sKey = new SecretKeySpec(aesDecrypted, "AES");
        Cipher arrby = cipher2;
        arrby.init(mode, (Key)sKey);
        return arrby.doFinal(this.encryptedBuffer);

See the full decryptor:

Resources of the file contains RSA private key, encrypted AES key and the encrypted content. After deobfuscating the code, and applying them properly in order to decrypt the content, we can see one more XML file:
Each of the properties is a path leading to other resources.
SERVER_PATH points to the encrypted resource with yet another JAR (the core of the malware). PASSWORD_CRYPTED is an RSA enctypted AES key. PRIVATE_PASSWORD is a private RSA key.
Additionally, we can see a link to the official website of the JRAT tool. Following the link we can find a commercial description provided by the authors/resellers of this RAT.


The same decrypting function must be applied once again on the content read from the resource files, defined in the XML. As the result we get another (third) JAR.

Stage 3

I used the same automated deobfuscator to clean this stage as well. Again, JD-GUI was still not capable of decompiling all the classes:


Fortunately, the other decompiler -CFR – gave much better results. See the code:

Not all the classes of this module are obfuscated. Only the classes in the server directory – that are core of the RAT – are scrambled.

Anyways, looking at the internal structure we can find familiar elements that ensure us, that this is the core of this malware. For example, the functionality used to infect particular system (windows, mac, linux). In folders key and protect we can find the DLLs that are being dropped in %TEMP% folder on Windows. Also, there are classes responsible for network communication over SSL.

In the folder resources we can find some interesting files: Key1.json, Key2.json and config.json.


It was easy to guess, that they are encrypted by the same way as the previous layer: Key1 was a serialized RSA private key, Key2 -encrypted AES key, and config.json – an AES encrypted configuration file. Indeed, deploying the decryptor I made in order to defeat the previous layer worked. We got a configuration of the rat.

See the full file:

We can recognize familiar elements that we saw during the behavioral analysis:


As we can see, the jar is installed in the folder Windows, under the name Windows and with the extension Windows. Folder PuXpErTFKpK is used to store eventual plugins. The configuration file includes also the content of the .reg file that is we observed being dropped in the %TEMP% folder and deployed. There is also a blacklist of the AV/security products.


JRAT is described in details on the dedicated support page, that is linked to a github account:


The project was created in 2013 and till now is actively maintained. JRAT 5.4 has been released on the 7th of October 2016.

JRAT bot can be configured by a dedicated builder in order to communicate with the chosen C&C and use custom encryption keys.

The basic functionality provides ability to view the system status, monitor the running applications, and browse the folders – but also to download and run other applications and visit links.

Additionally. there is a set of plugins that extends RAT’s capabilities. Quoting from the webpage, they are:

  • Window Controller
  • Webcam
  • Password Recovery
  • Reverse SOCKS
  • Keylogger
  • Disable Webcam Lights


According to authors, JRAT is a tool developed without malicious intents and dedicated to perform multiple administrative operations remotely. However, the features provided overlap with various commodity malware. As the described example shows, we can encounter cases when the tools like this are being used in typical malicious campaigns.

Click here for best antivirus and antispyware software

Powered by WPeMatico