Malware researchers decrypted the Qrypter Payload

Malware researchers at Cybaze-Yoroi ZLAB team dissected a new sample of Qrypter malware that revealed an interesting evolution of the threat.

Introduction

During the last weeks, Yoroi’s monitoring operation intercepted some malicious emails required further attention: they were sent to a very few organizations and the content was specifically tailored for Italian speaking targets. This messages warned the users about imminent summons against them, inviting them to read the attached lawsuit, a not so innocent looking file named “Avviso del tribunale.jar”.

This attachment has been dissected by Cybaze-Yoroi ZLAB team, revealing an interesting evolution of the Qrypter malware threat.

Technical Analysis

Sha256	4ede0d4787f2e5bc471de3490e5c9327b459985530e42def9cf5d94ea4c2cb2b
Threat	Qrypter-encrypted jRAT
Brief Description	Jar file contains jRAT
Ssdeep	12288:vimJ+fjGuiwDBA19F7/8fDFsJTVjODmYae:vimkiwDB6z8fZsN3Yae

The JAR file seems to be corrupted due to the absence of some classes. In fact, when it is started, the Java Virtual Machine launches a ClassNotFoundException related to a suspicious class named “qua.qrypter.Runner”.

Qrypter is a Malware-as-a-Service, especially popular for its usage in combination with AdWind/jRAT malware, as described in older analysis too. However, this new sample seems to exhibit different protection techniques with respect to the previously documented ones.

Opening the JAR file through an archive manager it is possible to see its internal structure: most files are encrypted and only one of them, the “p14603/p14604/p14605.class”, represents an runnable Java Class.

So, the “p14605.class” file contains a Java Main which is responsible for decrypting and launching the actual payload. Reversing this class, the Qrypter capabilities emerge.

The decryption routine takes advantage of Java reflection to make the analysis harder: every single object used by the malware is loaded at runtime in a similar manner as shown in Figure 4, where the malware assigns the object System.out to a local variable called “f11131465014074101”.

The “main” static method, initial entry point of the malware, is composed by few code lines setting up the right initial parameters for the actual decryption routine. 

Interestingly, the decryption routine implements a finite state machine (FSA) using the switch approach, a classical formal computational method commonly adopted by Information Engineers and Computer Scientists. The initial state is set to “24”.

The switch instruction repeatedly checks the value of the “currentState” variable, indicating the last machine’ state, and then it jumps in the right case statement depending on its value. Each “case” contains a decryption routine step and an instruction used to move from the current to the next state. Figure 7 shows one of the instructions belonging to the decryption phase. Using different reflection layers, the malware tries to load the class “qua.qrypter.Runner”, whose name is contained into “f11131464987745335” variable; this is the point where the class launches the exception due to the missing class.

However, statically analyzing the decryption routine it was possible to reconstruct the malware behavior uncovering the details of the payload protection mechanism, enabling us to write a custom decipher to extract the next stage of the sample. 

Inspecting the code we noticed the encryption key is stored in a particular variable among the huge number of reflective invocations:

With this information, we managed to decrypt all the protected files contained into the initial JAR archive mimicking the Qrypter behaviour. In detail, a “SecretKeySpec” has been created and then passed to a AES initialized “Cipher” object, but this first result is not plain-text yet, it actually is a GZIP compressed stream, so it has been forwarded into an additional “GZIPInputStream” object.

One of the decrypted files is a serialized “LinkedHashMap” object filled with a series of key-value entries representing the mapping between original file names and the fake/encrypted names. This object is fundamental to reconstruct the actual payload structure.

In fact, inspecting the hashmap’s entries, many class names emerge. Their names confirm the presence of AdWind/jRAT as final payload: the “drop.box”, “sky.drive” and “mega.download” files are well-known artifacts (Figure 10), containing malware private keys and configurations. Decrypting them, it was possible to recognize the AdWind/jRAT configuration schema, similar to the one previously analyzed in our report (The Story of Manuel’s Java RAT).

Conclusion

Even if the final payload is a well-known malware, like jRAT, the Qrypter crypter made it invisible for several antivirus engines. Moreover, this version of Qrypter seems to be different than the older ones: the intensive use of reflection techniques and the state-machine approach have never been mentioned in the previous analysis. Qrypter was popular for its MaaS model, but at this moment the web service is unreachable, so it is not clear how the malicious author used Qrypter to weaponize its AdWind/jRAT payload.   

Additional technical details, including Indicators of Compromise and Yara rules are reported in the analysis published on the Yoroi blog.

https://blog.yoroi.company/research/decrypting-the-qrypter-payload/

[adrotate banner=”9″]

[adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – Qrypter, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]