The Gunra ransomware group, which began its activities in April 2025, has been launching continuous attacks against various industries and companies around the world. Cases of damage have been reported in Korea as well. The distributed Gunra ransomware is available in two formats: an EXE file format for Windows environments and an ELF file format for Linux environments. This post will analyze the main features, encryption methods, and technical reasons that make decryption possible for the ELF version of the Gunra ransomware, so that readers can effectively respond to similar threats in the future.

 

The Gunra ransomware group began its activities in April 2025, and it has been launching continuous attacks against various industries and companies around the world, targeting Windows and Linux systems. Like other ransomware groups, they encrypt files on infected systems, steal sensitive data from affected companies, and threaten to disclose the information if a ransom is not paid.

 

 

Analysis

During the early stages of execution, Gunra ransomware performs a validity check on the arguments it receives. It only executes its main routine if all required arguments are provided.

 

Arguments	Behavior	Requirement
-t, –threads	Number of threads to use for encryption	Required
-p, –path	Path to encrypt	Required
-e, –exts	Extension of files to encrypt	Required
-r, –ratio	Encryption rate (MB)	Required
-k, –keyfile	RSA public key file path	Required
-s, –store	Path to store the ChaCha20 encryption algorithm key	Select
-l, –limit	Maximum encryption size (GB)	Select

Table 1. Behavior by argument value

 

 

Encryption Preparation

The Gunra ransomware performs encryption on the path provided through the –path argument. The encryption method can be broadly categorized into file encryption and disk encryption depending on the type of the path. In the case of file encryption, an independent encryption thread is created for each file to perform the encryption process. The number of threads created can be set from a minimum of 1 to a maximum of 100 based on the –threads argument.

 

The extension of the files to be encrypted is specified through the –exts argument. If “all” is provided, encryption is performed on all files in the path. If a specific extension is provided, up to 32 extensions can be set. The behavior of the encryption process varies depending on the type of the path. If the path is a file, an encryption thread is created immediately and encryption is performed without extension checks. However, if the “encrt” value is set for the –exts option, the file is not encrypted.

 

If a folder path is provided, the files in all subdirectories are checked to exclude any files from encryption. Afterward, an extension check is performed, and files with the specified extension have an encryption thread created for each file to perform the encryption process. If a disk path is provided, the entire disk is encrypted only when the “disk” value is set for the –exts option and an encryption key storage path is specified through the –store argument.

 

Files and Extensions Excluded from Encryption
R3ADM3.txt, .encrt

Table 2. Files and extensions excluded from encryption

 

 

File and Disk Encryption

The encryption of the file target works whether the –store argument value is set or not. The ChaCha20 encryption algorithm is used, and a 32-byte key and a 12-byte nonce value used for encryption are newly created each time. When the –store argument value is set, the key used in the ChaCha20 encryption algorithm is encrypted once with an RSA public key, and then it is stored with the .keystore extension in the path. On the other hand, when the –store argument value is not set, the key is inserted at the end of the encrypted file.

 

Figure 1. The ChaCha20 encryption algorithm

 

Figure 2. Encryption key storage method according to the –store argument value

 

File encryption is performed in different ways based on the encryption limit and ratio set by the –limit and –ratio options. The encryption process involves encrypting 1MB of data first. If the –ratio option is set, the next MB of data is then skipped by the specified value before encrypting the next 1MB of data.

 

If the size of the file to be encrypted is larger than the value passed to the –limit option, the encryption is performed from the beginning of the file up to the specified size. On the other hand, if the size of the file to be encrypted is smaller than the value passed to the –limit option, the entire file is encrypted.

 

Encryption of disk targets only operates when the –store argument is set to “disk”. The ChaCha20 encryption algorithm is used, and the 32-byte key and 12-byte nonce value used in encryption are newly generated each time. The encryption method is the same as file encryption, but it is applied differently based on the encryption limit and ratio set by the –limit and –ratio arguments.

 

 

Data Decryption

Each encryption thread performs encryption using the ChaCha20 encryption algorithm. A cryptographic vulnerability was found in the function that generates the 32-byte key and the 12-byte Nonce value used in this process, resulting in the creation of a highly insecure random number.

 

The function that generates a random number receives the current time in seconds through the time() function and uses this to create a seed value to be used by the rand() function. However, the 32nd and 12th iterations of the loop that creates the seed value are executed within a very short period of time. As a result, there is a high possibility that the same seed value will be used. This causes the rand() function to generate the same byte value, ultimately resulting in a 32-byte key and a 12-byte nonce array with the same byte values in a sequence. In other words, a key and nonce value that are extremely vulnerable from a cryptographic perspective are being used.

 

Figure 3. Cryptographically weak functions used to generate encryption keys and nonce values

 

Below is an array that contains the key and nonce values of the ChaCha20 encryption algorithm generated by this vulnerable random number generation function. As shown in Figure 4, the key and nonce values are generated in a form where the same byte is repeated.

 

Figure 4. ChaCha20 key and nonce values generated by the vulnerable random number generation function (before RSA encryption)

 

Due to this weak random number generation method, files encrypted by the Gunra ransomware of this version can be decrypted with a high probability using the Brute Force technique based on the 256 byte values from 0x00 to 0xFF. Figure 5 below shows an example of using the Brute Force technique on an encrypted file to identify the random number used for encryption and then using this information to decrypt the file.

 

Figure 5. Decryption result (PDF file signature)

 

 

ELF Format vs. EXE Format

 

The Gunra ransomware in ELF format uses the ChaCha20 encryption algorithm. It uses a cryptographically weak random number generation function to generate the key and nonce values required for encryption. As a result, the encrypted data can be decrypted with a high probability using a brute-force attack.

 

On the other hand, the EXE version of Gunra ransomware uses the ChaCha8 encryption algorithm, and the key and nonce values are generated using the CryptGenRandom() API based on the Cryptographic Service Provider (CSP). This method generates random numbers in a cryptographically secure manner, making decryption virtually impossible.

 

	ELF Format	EXE Format
Encryption Algorithm	ChaCha20	ChaCha8
Method of Generating Random Numbers	Using the rand() function based on the time() function	Using the CryptGenRandom() API
Possibility of Decryption	Possible	Impossible

Table 3. Comparison of characteristics between the ELF and EXE versions of Gunra ransomware

 

 

AhnLab’s Response Status

 

The diagnostic names and engine dates of the AhnLab product lines are as follows:

[V3 Diagnosis]

• Ransomware/Win.Gunra.C5755872 (2025.05.20.03)
• Malware/MDP.Ransom.M1355 (2016.12.13.00)
• Ransom/MDP.Decoy.M1171 (2016.07.15.02)
• Ransom/MDP.Event.M1946 (2018.06.06.00)
• Ransom/MDP.Event.M1785 (2017.11.22.00)
• Ransom/MDP.Magniber.M1876 (2018.03.09.03)
• Ransom/MDP.Event.M4428 (2022.09.05.02)
• Ransom/MDP.Event.M4353 (2022.07.14.02)

[EDR Diagnosis]

• SystemManipulation/EDR.Event.M2506 (2022.09.24.00)
• Ransom/EDR.Decoy.M2470 (2022.09.30.00)
• Ransom/MDP.Event.M1946 (2018.09.07.03)
• Malware/MDP.Ransom.M1876 (2018.09.07.03)
• Suspicious/MDP.Ransom.M12560 (2025.04.04.01)

 

MD5

94b68826818ffe8ceb88884d644ad4fc