New Java STRRAT ships with .crimson ransomware module

The following sections will describe the infection chain in detail. Here is an overview involving initial infection, intermediate files, unpacking layers and hardcoded downloads by the payload. The numbering of files in the image corresponds to numbers in the IOC listing at the bottom of the article.

The infection starts with a rather ordinary spam email^[1] that has a malicious attachment named NEW ORDER.jar^[2].

I found this email via VirusTotal graphs which shows a relationship to our Jar file. It is not clear if the uploader of the email redacted the email body or if the threat actors didn't want to take their time to add any content. It should be noted that Outlook prevents access to email attachments with .jar extension. In this case I applied a registry hack to have it shown anways.

The NEW ORDER.jar^[2] is a simple dropper. It retrieves a VBScript^[3] from the resources, saves the script as bqhoonmpho.vbs^[3] to the home directory of the user and executes it using wscript.exe.

The VBScript^[3] has a large string in it and uses PowerShell to replace characters in this string. The resulting base64 string is subsequently decoded and executed by PowerShell.

The unpacked layer is again a VBScript. This script will copy the packed version of itself to %APPDATA%\edeKbMYRtr.vbs. It will also download a Java Runtime Environment (see picture below) and add it to the registry. That way it may be prepared to infect systems that don't have Java installed. It even has a built-in check that runs javaw.exe with the -version parameter to verify that the JRE has the version 1.6, 1.7 or 1.8.

The email attachment already requires a Java Runtime Environment (JRE) on the system, which means the current infection chain misses the opportunity to work regardless of the JRE installation. If this VBScript is ever shipped with a different initial infection step, it may enable the RAT to work on more systems.

What striked me first about the Jar payload is the package name strpayload and one of the dependencies listed in the MANIFEST.MF named system-hook-3.5.jar.

A quick search for the library turns up a GitHub repository by user kristian stating that "Java (low-level) System Hook provides a very light-weight global keyboard and mouse listener for Java". We can already estimate that the malware may use it to log keystrokes.

We see immediately that the Jar file is obfuscated by Allatori. Upon opening the Main.class we find a URL reference to hxxp://jbfrost.live/strigoi/lib.zip
The URL provides a ZIP bundle of all the dependencies listed in the MANIFEST.MF. The malware will probably not work correctly if this site is down.

Due to the use of Allatori most of the strings in the Jar file are encrypted with AES. Method arguments and local variables mostly use the name 'a' which creates non-working decompiled Java code. Although Java bytecode saves variable names, it uses indices to reference them. So using the same name several times doesn't cause an error in the bytecode but causes one in decompiled code because it's not clear anymore which variable was referenced by 'a'.

An example is seen in the image below. The left side shows decompiled Java code with both arguments named 'a'. The right side shows the same method in Java bytecode. The first argument 'arg0' is later referenced by it's index via 'adload0'.

Method f in class strpayload.r builds a string with information about the infected system. Among others it shows name and supposedly version number of the malware, which is "STRRAT 1.2".

To combat string encryption by Allatori I used 'Deobfuscator' by Github user 'Java Deobfuscator'. Deobfuscator has a variety of options to choose from. I applied Allatori.StringEncryptionTransformer which successfully decrypted the strings.

In a resource of the malware I found an encrypted configuration file. The malware code shows it is encrypted with AES using the password "strgoi". I made a quick and dirty decrypter by copying the decompiled code for the decryption method and repairing it, so the double names are not causing compile errors. Then I added a few lines to read and write the config. My configuration decryption code is listed below.

import java.io.File;
import java.nio.ByteBuffer;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;

public class ConfigDecrypter {
	
       public static void main(String[] args) throws Exception {
    	   File config = new File("config.txt");    	   
    	   byte[] configBytes = Files.readAllBytes(config.toPath());

    	   byte[] decryptedConfig = decryptConfig("strigoi", configBytes); 
    	   Path output = Paths.get("config_decrypted.txt");
    	   Files.write(output, decryptedConfig);
       }

       public static byte[] decryptConfig(String password, byte[] data) throws Exception {
    	   int var2;
    	   ByteBuffer a;
    	   if ((var2 = (a = ByteBuffer.wrap(data)).getInt()) >= 12 && var2 <= 16) {
		byte[] var6 = new byte[var2];
		a.get(var6);
		SecretKey var3 = createKey(password, var6);
		ByteBuffer var10001 = a;
		byte[] var8 = new byte[a.remaining()];
		data = var8;
		var10001.get(var8);
		Cipher var4 = Cipher.getInstance("AES/CBC/PKCS5PADDING");
		IvParameterSpec var7 = new IvParameterSpec(var6);
		var4.init(2, var3, var7);
		return var4.doFinal(data);
    	   } else {
		throw new IllegalArgumentException("Nonce size is incorrect. Make sure that the incoming data is an AES encrypted file.");
    	   }
       }

       public static SecretKey createKey(String password, byte[] data) throws Exception {
		PBEKeySpec a = new PBEKeySpec(password.toCharArray(), data, 65536, 128);
		byte[] d = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1").generateSecret(a).getEncoded();
		return new SecretKeySpec(d, "AES");
       }
}

The resulting plain text configuration of our sample is in the picture below. It reveals, among others, the C2C server.

The commands used for the ransomware component are rw-encrypt for "encrypting" files, rw-decrypt for "decrypting" files and show-msg for displaying the ransom note.

Ransomware "encrytion" and "decryption" methods are in the class strpayload.l. The "encryption" method is seen in the screenshot below.