Technical Analysis of Khonsari Ransomware Campaign Exploiting the Log4Shell Vulnerability

Originally published at:

The Log4J vulnerability, which is being actively exploited in the wild, has led to a significant spike in ransomware attacks, and has paved the way for more. Joining the list of low effort ransomware groups that are adding the Log4shell vulnerability to their arsenal, we have the Khonsari ransomware, which is a skidware. 

The Khonsari ransomware is written in C# .NET, with minimal code complexity in terms of features and capabilities. Recently it has been observed that the group has started dropping Orcus RAT to gain initial entry, by exploiting Log4shell vulnerability, to execute loaders written in Java to deploy the RAT.

Modus Operandi of the Khonsari Campaign

The Khonsari group targets vulnerable Log4shell systems to drop multiple Java payloads that act as secondary stagers for either ransomware code or Orcus RAT deployment. In this report, we cover technical details of Khonsari campaigns in the wild.


Analysis of Orcus Rat Dropper

  • By exploiting Log4shell vulnerability the Khonsari group executes the Java class hxxp:// to download a secondary payload.
  • The secondary payload is a dropper written in Java that detonates Orcus RAT, on the target system, to gain initial access .

  • The payload Main.class, when executed, downloads a hxxp:// file from an external resource controlled by the attacker, as highlighted by the red box in the image below.

  • The above Java code creates a file fengvp.peedee in the temporary directory of the user and the contents of dorflersaladreviews.jar, retrieved from the URL, are written to the file.
  •  Later as highlighted by the yellow box, in the above image, the .pedee file is executed on the target system leading to execution of Orcus RAT.
  • dorflersaladreviews.jar (fengvp.peedee) is a Java dropper that deploys the infamous Orcus RAT on the target system. 
  • The Java Dropper package consists of 3 classes that perform various malicious functions on the system, including:
    • Retrieving the Orcus RAT shellcode hosted on attacker infrastructure
    • Executing the shellcode using Win32 APIs
    • Using a custom encoding of strings to hinder analysis, since all of the strings used in the code are encoded. 
  • As seen in the image below, the dropper then makes an HTTP connection to the URL hxxp:// that contains the Orcus RAT shellcode.

  • The following section of the dropper finally executes the shellcode on the system using various native Win32 APIs. 

  • The process of shellcode execution involves:
    • Creating a new process (console host) via Win32 API CreateProcess()
    • Allocating a memory region, in the remote process, via Win32 API VirtualAllocEx()
    • Writing the Orcus RAT shellcode, into remote process memory allocated previously, via Win32 API WriteProcessMemory()
    • Finally executing the shellcode by creating a thread via Win32 API CreateRemoteThread()

Successful execution of Orcus RAT gives the attacker access to the target system. Subsequently, the attacker can deploy ransomware on the target system or laterally move across the network to hunt down high value targets such as Domain Controllers in the MS Active Directory environment.

Analysis of Khonsari Ransomware Code

  • Khonsari ransomware is written in C# .NET with an x86 architecture. 
  • The developer has obfuscated the code by changing class and object names to random strings as shown in the image below.
  • 5 classes are present in the code that perform various malicious activities on the target system. 

Obfuscated Classes

  • Throughout the code we see the use of encoded string values. This behaviour is inherent to a malware developer to enforce operational security by hiding important string values through a custom encoding mechanism. 
  • Custom decoder can be found in the code as shown below, which is a simple rolling XOR encoding scheme. The below logic can be reproduced in any language by the analyst to decode the strings used in the malware.

Initialization of Encryption Keys

  • The execution starts with initializing the class constructor of the class that has the main function defined in it. 
  • Inside the constructor, the malware initialises the AES key and Initialisation Vector (IV), used for encryption of user data on the target system, as shown in the red box in the image below.  
  • The encoded strings are ransom note contents. The contents of the ransom note is generated and stored in a class field.

Generation of the Ransom Note

  • As highlighted in the yellow box in the image below, the PruZnHLM method is responsible for encrypting the AES key and IV using the RSA cryptographic algorithm. In essence, the malware uses the ransom note contents to store the critical data needed for decryption of user data. 
  • If the user deletes the ransom note then the data cannot be recovered. At this stage, the ransomware only initializes variables with generated data.

Initialization phase

  • The generated ransom note contains the AES key and IV encrypted with the RSA algorithm. The Key and IV are very crucial elements in the decryption process. The data cannot be recovered if the ransom note is deleted or modified. 

Server Connection Check

  • After the encryption process, the main() function of the program is executed. The first task of this function is to get a remote text file from an external resource on the Internet controlled by the attacker. 
  • The encoded string represents the following information: hxxp://3[.]145[.]115[.]94/zambos_caldo_de_p[.]txt
  • Based on our analysis, this phase does not have any significant role in overall functionality of the ransomware. Our assumption is that it is used as a status check, since no data can be seen flowing between the victim and server. However, when the malware is not able to reach the server it stops executing. Indicating that this is used as a control to detonate the malware. 

Directory Enumeration

  • After the connection check, the malware immediately starts enumerating the directories of the target system. 
  • As highlighted in the image below, the red box shows the malware performing a check to exclude the C:\ drive, where the string is dynamically decoded by the XOR scheme. However, the remaining drives of the target system are added to a list to be encrypted later. . 
  • As highlighted by the yellow box in the image below, the malware adds user Downloads (decoded string), along with Desktop directory, to target directories for encryption.

Directory Enumeration

Encryption of Victim Files

After the directory enumeration process, the malware starts the encryption process:

  • Directory traversal logic is implemented in the function bXUaefgt shown in enum-1a. The code logic is simple; each directory added to the list by the malware is traversed to return an array containing the files. 

  • As seen in Encr-1a, the contents of the directory are encrypted. The method rVWZTCXX is responsible for implementing AES cryptography as shown in the image Encr-1b.
  • After encrypting the user data, the malware stores the encrypted contents in a new file with the extension .khonsari (decoded string)as highlighted in the yellow box in Encr-1a.

  • While encrypting, the malware checks for the file extensions, as shown in the image below. And files with .khonsari, .ini, and ink are skipped from locking. It is interesting that the ransomware encrypts .ink files because of the typo in the last check, where the developer has used ink instead of .ink.

Creation of the Ransom Note

  • Finally, the ransomware code writes the ransom note into the user’s Desktop directory with the file name HOW TO GET YOUR FILES BACK.TXT.

  • Following table summarises the contents of class fields HtqeFwaI and rbTApefo shown in the image Ransom_note_1a:
Class Field Data Value
HtqeFwaI C:\Users\<user_name>\Desktop\HOW TO GET YOUR FILES BACK.TXT
rbTApefo RSA encrypted(AES key and IV) along with ransom note content

Indicators of Compromise (IOCs)