JSWorm: The 4th Version of the Infamous Ransomware

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

Hash 46761b8b727f3002d1c73fa6c8568ebcf2ec0066666251f66dcda9d4268e03e8
Threat JSWorm
Brief Description JSWorm 4.0.2
Ssdeep 3072:77LlFWt1yDzVwq4wk+KdXqSmT9C8Fi7FvSJv+R1Y:77a2XC9+KBJmT9BihSlw+

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”

Figure 1: Infection ID and Contact E-mail 

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.BINSystem Volume InformationMSOCache. Also, for each encountered file, the malware compares it with the excluded paths and if they match, a conditional jump is taken.

Figure 2: Excluded paths

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.

Figure 3: Extensions excluded from encryption
Figure 4: Content of “key” file contained in “C:\ProgramData”

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:

vssadmin.exe delete shadows /all /quiet Delete the Shadow Volume Copies
bcdedit /set {default} bootstatuspolicy ignoreallfailures -y Disable Windows Error Recovery on startup
bcdedit /set {default} recoveryenabled No -y Disable Automatic Startup Repair
wbadmin delete catalog -quiet Delete the backup catalog
wmic shadowcopy delete -y Another attempt to delete the Shadow Volume Copies
/c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v “zapiska” /d “C:\ProgramData\JSWRM-DECRYPT.txt” -y Set persistence on startup
/c taskkill.exe taskkill /f /im store.exe Kill “store.exe” process (related to MS Exchange)
/c taskkill.exe taskkill /f /im sqlserver.exe Kill “sqlserver.exe” process
/c taskkill.exe taskkill /f /im dns.exe Kill “dns.exe” process
/c taskkill.exe taskkill /f /im sqlwriter.exe Kill “sqlwriter.exe” process

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.

Figure 5: Disassembled routine for shadow copies deleting

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.

Figure 6: Embedded initial string used to generate AES key

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.

Figure 7: RSA-1 public key in Base 64 encoding (on the left) and in binary encoding (on the right)

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

Figure 8: Entire control flow to encrypt the AES key

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.

Figure 9: Imported RSA key through “CryptImportKey” API

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

Figure 10: Parameters for the “CryptEncrypt” function

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 =)”.

Figure 11: Mutex creation

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/

The post JSWorm: The 4th Version of the Infamous Ransomware appeared first on Security Affairs.