The Green Blood ransomware group, which has been active since January 2026, has been targeting countries in South Asia, Africa, and parts of South America, and is characterized by its Golang-based ransomware payload. In this post, we analyze the main characteristics of the Green Blood ransomware, its encryption method, and the technical reasons why it is decryptable, in order to provide insights to help you effectively respond to similar threats in the future.

 

The Green Blood ransomware group, like other ransomware groups, uses file encryption on infected systems to steal sensitive data from victimized organizations, and pressures victims for ransom payments through threatening messages that promise to permanently destroy the encryption key if the ransom is not paid.

 

 

What We Found

Green Blood v2.0 ransomware creates mutexes in the early stages of execution to prevent duplicate execution, and the mutex names it uses are as follows.

 

Mutex Name
Global\\GREENBLOOD_ENCRYPTOR_MUTEX_2A3B4C5D

[Table 1] Mutex names used to prevent duplicate execution

 

The crypto/rand.Read function is then called to generate a cryptographically secure 32-byte random number, which is used as the key for the AES-256 encryption algorithm. then, it generates a unique value, Machine ID, to identify the current environment. To do this, it collects environment information such as Host Name, Windows Version, and MAC address of the current environment, and generates a 16-byte Machine ID based on it. If this process fails, the Machine ID is generated based on the current time information.

 

After that, a Recovery Token is generated to be used by the threat actor in the decryption process, and the value is generated by XOR operation of the 32-byte AES-256 encryption algorithm key and the 16-byte Machine ID.

 

[Figure 1] Routine to generate Recovery Token by XOR operation of AES-256 encryption key and Machine ID

 

 

Preparing for Encryption

Green Blood v2.0 ransomware creates two types of workers: one that performs the actual file encryption, and one that scans for files to be encrypted and enrolls them in a queue of files to be encrypted.

 

The worker that scans for encryption targets calls the GetLogicalDrives API to obtain the bitmask values of drives in the user environment and selects a fixed drive, such as a hard disk drive, as a target drive for encryption based on the values. then, it recursively traverses the directory of the selected fixed drive and generates a ransom note if the target is a directory, and checks whether the target file is encrypted if it is a file.

 

First, it checks whether the file extension is “.tgbg” to see if the file is already encrypted, and does not perform additional encryption for files that are already encrypted. On the other hand, if the file is not encrypted, the file extension is converted to lowercase, and then compared to the list of excluded encryption extensions to determine whether it is excluded from encryption.

 

File extensions excluded from encryption
Exe, dll, sys, drv, ocx, cpl, scr, msi, msu, cab, mui, mun, edb, jrs, log, tmp, temp, lnk, url, pif

[Table 2] File extensions excluded from encryption (20)

 

Then, it compares it with the list of encryption target extensions again to finally decide whether it is an encryption target file or not, and if it is confirmed as an encryption target file, it registers the file in the encryption target file queue.

 

File extensions targeted for encryption

Doc, xls, ppt, pdf, txt, rtf, odt, ods, odp, csv, xml, yml, sql, mdf, ldf, mdb, dbf, myd, myi, frm, ibd, bak, old, arc, bck, bkf, log, err, inf, ini, cfg, cpp, hpp, css, php, ps1, vbs, jpg, png, gif, bmp, psd, mp3, wav, mp4, avi, mov, wmv, mkv, flv, m4a, aac, zip, rar, tar, bz2, tgz, vmx, vhd, iso, img, pst, ost, eml, msg, mae, trn, dmp, wal, key, pem, crt, pfx, p12, cer, pub, gpg, pgp, asc, ora, rsp, msi, lnk, htm, sln, lck, docx, xlsx, pptx, json, yaml, back, log1, log2, info, conf, java, html, jpeg, tiff, indd, flac, vmdk, vhdx, dump, priv, accdb, error, audit, prefs, mssql, db, py, js, ts, go, rs, cs, vb, pl, sh, ai, 7z, gz, xz, sqlite, backup, config, csproj, vbproj, sqlite3, archive, journal, vcxproj, pbxproj, propertiesshell, settings, c, h, xcodeproj

[Table 3] File extensions targeted for encryption (140)

 

Even if the file extension does not exist, encryption is performed if the file size is more than 100 bytes. However, files whose file name starts with “~”, such as MS Office temporary files, are excluded from encryption.

 

A total of 50 workers are created and run in parallel to perform the actual file encryption, and each worker receives one file from the file queue to be encrypted and calls the encryption function for that file.

 

 

File Encryption

The file encryption step checks the size of the target file, and if the file size is more than 50GB, it does not encrypt the file. Then, it creates temporary files in Write-Only mode by appending “.tmp” to the full path of the file to be encrypted, calls crypto/rand.Read for each file to generate a 16-byte random number, and writes this value to the beginning of the file. This random number is the IV value of the AES-256 encryption algorithm currently used to encrypt the file, and different IV values are used for different files.

 

The ransomware then encrypts the file using the AES-256 encryption algorithm in CTR mode based on the 32-byte key generated at the beginning of the ransomware execution. File encryption is performed in 1MB increments, and after the encryption is complete, the final encrypted file is created by changing the file extension of the created tmp file to “.tgbg” and the existing original file is deleted.

 

[Figure 2] File encryption routine using AES-256 encryption algorithm (CTR mode)

 

The structure of the encrypted file is as follows. At the top of the file, the IV value used for AES-256 encryption of the current file is stored, followed by the encrypted file data sequentially.

 

[Figure 3] File structure after encryption

 

 

Anti-Forensics and Self-Deletion Features

Green Blood v2.0 ransomware employs a total of seven anti-forensics and self-deletion features to prevent users from recovering. First, it checks whether the current process is running with administrator privileges, and if administrator privileges exist, it executes seven predefined commands sequentially; if administrator privileges do not exist, it does not execute the commands and omits the corresponding procedures.

 

Index	Anti-forensics commands and their meanings
1	vssadmin delete shadows /all /quiet
	Delete all volume shadow copies
2	wbadmin delete catalog -quiet
	Delete the Windows Backup Catalog
3	bcdedit /set {default} recoveryenabled no
	Disable the Windows Recovery Environment
4	bcdedit /set {default} bootstatuspolicy ignoreallfailures
	Set boot failure status to ignore all failures
5	wmic shadowcopy delete
	Delete a WMI-based volume shadow copy
6	reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection” /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
	Disable Windows Defender real-time monitoring
7	netsh advfirewall set allprofiles state off
	Disable Windows Firewall all profiles

[Table 4] Anti-forensic commands used to impede recovery (7)

 

Next, it creates a batch file named “cleanup_greenblood.bat” in the temp path and runs it to perform the self-deletion function. The batch file waits for five seconds before deleting the ransomware executable, and is configured to retry repeatedly if it fails. In the final step, it also deletes the batch file that executed itself.

 

 

Possibility of Decryption

Green Blood v2.0 ransomware uses the symmetric-key based AES-256 encryption algorithm, although it uses different IV values for each file, and the encryption key is generated once at the beginning of the ransomware’s execution and is used the same during all file encryption. In addition, the key is used to generate a Recovery Token by performing an XOR operation with a 16-byte size Machine ID generated based on the current system information, so if it is reversed, the key required for file decryption can be restored with a high probability.

 

[Figure 4] Recovery ID and Machine ID specified in the ransom note

 

The decryption method is as follows. after excluding the “GREEN-BLOOD-” string from the Recovery ID value included in the ransom note, prepare the following 32 bytes of data to be used in the XOR operation, and perform the XOR operation with the 16 bytes of the Machine ID specified in the ransom note to restore the AES-256 key used for file encryption in the current environment. Then, if you apply the decryption algorithm of AES-256 CTR mode using the restored key and the IV value of 16 bytes stored at the top of each file, you can recover the file data normally with a high probability.

 

[Figure 5] AES-256 encryption key restoration and file decryption result using Recovery ID-based XOR operation

 

 

AhnLab Response

The detection name and engine date information of AhnLab product line are as follows.

[V3 Diagnosis]

• Ransomware/Win.GreenBlood.C584923 (2026.01.31.01)
• Ransomware/Win.GreenBlood.C584449 (2026.02.05.02)
• Ransom/MDP.Event.M1785 (2017.11.23.00)
• Ransom/MDP.Decoy.M1171 (2016.07.14.02)
• Ransom/MDP.Event.M1875 (2018.03.09.00)
• Ransom/MDP.Event.M4353 (2022.07.05.00)
• Ransom/MDP.Behavior.M2813 (2020.03.24.03)
• Ransom/MDP.Delete.M1105 (2016.05.18.02)
• Ransom/MDP.Event.M1946 (2018.06.06.00)
• Ransom/MDP.Event.M4807 (2024.02.08.02)

[EDR Diagnostics]

• Execution/EDR.Malware.M10459 (2022.08.12.03)
• Connection/EDR.Event.M11768 (2024.06.11.00)