The Qrypter Payload Malware Has Been Finally Decrypted

This article is about findings from Cybaze-Yoroi ZLAB’s discovery and the dissection of new Qrypter malware and its resulting evolution.

It all started with Yoroi’s discovery of a few malicious emails during routine monitoring in the past few weeks. Upon finding these emails, the Yoroi team sent them to certain organizations and found that the malware was targeting Italian users. The contents of the message included a warning to the user that they had been summoned by the court and that they should immediately view the case details in the attached lawsuit document. The file name itself was called “Avviso del tribunale.jar.”

Upon dissecting the attachment, the Cybaze-Yoroi ZLAB team was able to track the malware’s complete evolution.

Technical Analysis

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

The JAR file is missing a few critical classes which is an immediate red flag that points to the fact that it’s corrupted. As soon as the file is opened it launched a ClassNotFoundException through the Java Virtual Machine, and in relation to a “qua.qrypter.Runner” class name.

Qrypter Payload Malware

Qrypter is commonly used in conjunction with AdWind/jRAT malware as a Malware-as-a-Service. But, judging from the new sample findings, there are some new protection techniques in play that weren’t present in the documented cases.

You can clearly see the internal structure as soon as you open the JAR filer through a dedicated archive manager, and it shows that a majority of the files have been encrypted. Only the “p14603/p14604/p14605.class denotes a working Java Class.

Within the “p14605.class” file is a Java Man and that’s what the developer uses to decrypt and launch the payload. It’s possible to see the emergence of the Qrypter capabilities when you reverse this class.

The decryption technique works by using Java reflection in an effort to complicate the analysis. If you look at Figure 4, you’ll see the runtime that’s used to load every malware object. This system requires the malware to attribute the System.out object to a “f11131465014074101” local variable.

Only a few code lines are used to develop the malware’s entry point parameters. This is the primary static method and it provides the right parameters from which to create the actual decryption route.

A switch approach is used by the decryption routine to apply a finite state machine (FSA). This is a very well-known computational method that’s often used by Computer Scientists and Information Engineers alike. The initial stage is fixed at “24”.

The switch instruction checks the “currentState” variable value over and over again and it repeatedly shows the last machine’ state. Based on its value, the switch instruction then jumps over to the right case statement.

Inside each case is a decryption routine step and instruction combo that can be used to jump to the next state. In figure 7 you can clearly see how the decryption phase instructions are carried out. The malware attempts to load “qua.qrypter.Runner class through different reflection layers, and you’ll find their name within the “f11131464987745335” variable. This allows the class to activate the exception as a result of the missing class.

We were able to write a custom decipher that can be used to extract the sample’s next stage by deconstructing the payload protection mechanism and using the details within. We then reconstructed the malware behavior using this information through static analysis.

Through this process, we saw the encryption key cleverly hidden in one of the reflective invocation variables as follows:

This information allowed us to go a step further and decrypt all of the protected files inside the JAR archive. We did this by imitating the Qrypter behavior. Basically, the “SecretKeySpec” was developed and delivered to an AES initialized “Cipher” article. But, this is not exactly plain-text just yet, but a GZIP compressed stream, which means it has been passed onto another “GZIPInputStream” object.

Among the decrypted files is a serialized “LinkedHashMap” object filled which contains several key-value entries that represent both the fake/encrypted names and the original file names. This object is the key to reconstructing a payload structure.

Qrypter Payload virus

When looking deeper into the hashmap entries we found a number of class names. These names show that there’s an AdWind/jRAT as final payload. Files like “”, “” and “”, are all popular artifacts that usually come with configurations and private keys.

Decrypting them enables you to see the AdWind/jRAT configuration schema clearly.



Whether or not the final payload is a popular malware is beside the case. The Qrypter is able to hide payloads from different antivirus engines quite well, and the latest version of this malware has gone through an evolution and now comes with a state-machine approach and lots of reflection techniques that researchers were not familiar with.

Qrypter was mostly known for its MaaS model but they seem to have changed their M.O., and the malicious author behind it was able to weaponize the AdWind/jRAT payload using this new version of Qrypter.