Pierluigi Paganini September 04, 2019

Malware researchers at Yoroi-Cybaze ZLab have analyzed the fourth version of the infamous JSWorm Ransomware.

Introduction

The ransomware attacks have no end. These cyber weapons are supported by a dedicated staff that constantly update and improve the malware in order to make harder detection and decryption. As the popular GandCrab, which was carried on up to version 5 until its shutdown, also other ransomware are continuously supported with the purpose of creating revenues for cyber criminals. One of them is JSWorm, which has been updated to version 4. 

Despite the name could remind to JavaScript language and a possible “worm” logic, the malware does not include either of the two characteristics.

Technical Analysis

Table 1: Information about JSWorm 4.0.2 version

JSWorm encrypts all the user files appending a new extension to their name. Unlike other ransomware, the extension is composed by many fields, reporting the information the user needs to move on the ransom payment phase. These fields are the same shown in the ransom note, that are: “Filename.originalExtension.[Infection_ID][Attacker_email].JSWRM”

Moreover, in the ransom note there is also a backup email, “[email protected]”, to ensure availability in case of blacklisting. During the encryption phase, the ransomware creates an HTML Application “JSWRM-DECRYPT.hta” in each folder it encounters. The HTA file corresponds to the ransom window shown in Figure 1.

To ensure the correct machine functionalities, the ransomware excludes from the encryption phase several system directories (Windows, Perflogs) and junction points like Document and Settings, $RECYCLE.BIN, System Volume Information, MSOCache. Also, for each encountered file, the malware compares it with the excluded paths and if they match, a conditional jump is taken.

Unlike most ransomware, JSWorm does not embed a list of file extensions to encrypt, but uses a set of extensions to exclude during the cipher step. The malware encrypts all the files whose extension is not present in the list.

During the encryption phase, JSWorm writes a suspicious file named “key.Infection_ID.JSWRM” in “C:\ProgramData”.It contains the AES key used to encrypt the files. Unfortunately, the key is processed with an additional RSA encryption step before its storing. The following figure shows an example of the encrypted key. 

Moreover, to maximize the impact of the encryption phase, the ransomware:

• deletes the shadow copies and other system restore points automatically created by Windows;
• kills some processes related to common programs, like SQL server, to proceed with the encryption of the files on which these programs were operating;
• adds a registry key to the autorun path to show the ransom note window also after a system reboot.

The commands invoked by JSWorm to perform the above-mentioned actions are:

Table 2: Commands executed by the malware

An example of how the malware invokes the commands using the “ShellExecuteA” API is shown in the following figure.

The Encryption Scheme

The AES key the malware encrypt is generated starting from an embedded Base64 seed “MI2i6BWRFhcswznItBEl33UaIoDOwqI=”, which is converted into a byte array through CryptStringToBinaryA API before proceeding with low-level manipulation.

The fixed string is combined with a random one to make the derived AES key different for each infection. Not even the malware writer knows the final AES key to decrypt the files, so when the user asks to recover his files, he must send the key file stored in “C:\ProgramData”. On the other side, the attacker will receive the file, then he will decrypt the content using his private RSA key and will proceed to extract the AES key useful to decrypt the user files.

To encrypt the AES key, JSWorm uses an RSA public key embedded into it in Base64 form, as shown in the following figure.

The control flow used to encrypt the AES key is based on Windows Cryptography API, as visible in the following figure.

After decoding of RSA public key and the initialization of a new PROV_RSA_FULL cryptographic service provider (CSP) through the “CryptAcquireContextA” function, the ransomware import the decoded RSA key using the “CryptImportKey” API. 

The last step is the encryption routine, which is done using the “CryptEncrypt” function, as shown in the following figure.

A funny piece of the malware code is the Russian string used to instantiate a new mutex, “kto prochtet tot sdohnet =)” which means “who reads will die =)”.

Conclusion

The analyzed case has some features in common with most of the ransomware, including encryption scheme and the deletion of shadow copy and persistence. About the encryption scheme, the ransomware uses an AES key generated starting from an embedded Base64 seed which is converted into a byte array through CryptStringToBinaryA API. It is very common to find Ransomware relying on this library (CryptoAPI) for cryptographic task mainly for reliability and for reducing the time for development.

Another interesting element is the presence of a mutex containing the string “kto prochtet tot sdohnet =)” in Russian language. This leads us to think that the authors could have Russian hands. Obviously, this could also be a false flag, but the Russian underground have a long tradition in such kind of cyber-crime activities: in fact, according to an Anton Ivanov research, senior malware analyst at Kaspersky Lab, even back in 2016 the Russian underground gave birth to about the 75% of the new crypto-ransomware tracked in that year, evidence of a consolidated malware writing capability.

Technical details, including IoCs and Yara Rules, are available in the analysis published the Yoroi blog.

https://blog.yoroi.company/research/jsworm-the-4th-version-of-the-infamous-ransomware/

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – JSWorm, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]