Underground Ransomware Targeting Korean Companies
The Underground ransomware gang is launching continuous ransomware attacks against companies in various countries and industries, including South Korea. This post describes the analysis and characteristics of the Underground ransomware.
1. Overview
1.1 Team Underground
The ransomware strain operated by the group known as Underground was first identified in early July 2023. Afterward, their activities remained unknown until May 2024, when a new DLS (Dedicated Leak Site) was announced, confirming that the group had continued their operations. Like other ransomware groups, they encrypt files on infected systems, steal sensitive data from affected organizations, and publicly disclose the information if the ransom is not paid.
Figure 1. Logo of Underground Team
The list of companies affected by the Underground ransomware gang includes multinational corporations in the United Arab Emirates, the United States, France, Spain, Australia, Germany, Slovakia, Taiwan, Singapore, Canada, and Korea. The affected companies are from various industries such as construction, interior design, manufacturing, and IT. The annual revenue of these companies ranges from $20 million to $650 million. The Underground ransomware gang does not seem to discriminate based on country, industry, or company size, as they target a wide range of companies. Their ransomware attacks are on the rise globally.
1.2 Underground Ransomware Malware
The Underground ransomware encrypts files using a combination of a random number generation (RNG) algorithm, AES symmetric key encryption, and RSA asymmetric key encryption techniques. Each encrypted file uses a different AES key, and the key-related information is additionally inserted at the end of the file. Notably, no network communication occurs after the file encryption process. This means that the threat actor designed the ransomware so that the remaining traces in the local environment alone would be insufficient for decryption. The RSA public key used to encrypt the AES-related information is hardcoded into the malware in advance. When the threat actor decrypts the encrypted file, they use the corresponding RSA private key to decrypt the AES key. This means that the threat actor can carry out the decryption process as long as they have the file, without requiring any additional C2 communications. The ransomware classifies files as small, regular, or large based on their size. Small files are encrypted in their entirety, but larger files have their contents encrypted using a striping method, where gaps of a certain size are left at the beginning, end, and middle of the file.
The ransom note not only advertised data encryption, but also additional services such as security vulnerability diagnosis, security enhancement advice, and data recovery support. The note provided the Tor site URL and login credentials, allowing for negotiation on the site. Additionally, the ransom note contained a message about the attack target’s IP and the stolen information, suggesting that the threat actor had inserted this message into the malware before encrypting the data. This means that the threat actor had already breached the system before executing the ransomware. Threat actors conduct thorough reconnaissance to select a specific PC as the attack target and distribute modified ransomware tailored to the target. As such, the ransomware strain was not distributed indiscriminately on a large scale. Instead, the threat actors followed an advanced attack process involving system infiltration, information collection, target selection, and the distribution of customized ransomware.
Analysis
Initial Routine
There is a logic that checks the number of parameters at the beginning. If the number of parameters exceeds 2, it is designed to perform no action and exit immediately.
Figure 2. Process of checking the number of initial argument values
Then, the threat actor declares a string (“8DC1F7B9D2F4EA58”) inserted in advance as a Mutex. After this initial routine, there are no anti-debugging or anti-sandbox techniques, and the characteristic behaviors of the ransomware malware immediately begin. To prevent the recovery of files encrypted by the ransomware, the threat actor first uses the vssadmin command to delete all shadowcopy data. They then use registry editing to restrict remote desktop connections and stop relevant services that could interfere with file encryption.
|
Malicious Behavior |
Command |
| Volume Shadow Deletion | vssadmin delete shadows /all /quiet |
|
Remote Desktop Connection Restriction |
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\ /v MaxDisconnectionTime /t REG_DWORD /d 1209600000 /f |
|
Removing interference for DB encryption |
net stop MSSQLSERVER /f /m |
| net stop SQLSERVERAGENT /f /m | |
| net stop MSSQLFDLauncher /f /m |
Table 1. Commands used for operating the system
2.2 Prepare Encryption
To prevent the system from being destroyed by encrypting key files, the following folders are excluded from encryption. The environment variables are stored as strings to be compatible with various Windows systems, and the strings are created at runtime through the GetEnvironmentVariableW() API.
|
Environment Variables |
Actual Path |
| %SystemRoot% | C:\Windows\ |
| %ProgramFiles% | C:\Program Files\ |
| %ProgramFiles(x86)% | C:\Program Files(x86)\ |
Table 2. Folders excluded from encryption
For the same reason, there are also file extensions that are not encrypted.
|
File Extensions Excluded from Encryption |
| sys, exe, dll, bat, bin, cmd, com, cpl, gad, et, inf, ins, inx, isu, job, jse, lnk, msc, msi, mst, paf, pif, ps1, reg, rgs, scr, sct, shb, shs, u3p, vb, vbe, vbs, vbscrip, ws, wsh, wsf, ini, cfg |
Table 3. File extensions excluded from encryption
When selecting files to encrypt, the malware uses a threshold value that is the current time obtained by GetSystemTime() minus 6 months. This allows the malware to select files that have been accessed, modified, or created within the last 6 months for encryption, reducing system load and maximizing efficiency by concentrating encryption resources on key files that are frequently used by users.
Figure 3. SystemTime 6 months ago being passed to the encryption-related function
2.3 Encrypting Files
As mentioned in the overview, the AES symmetric key is encrypted with the RSA public key and inserted into the encrypted file. Therefore, there are no clues left to decrypt this file in the local environment. The structure of the file after the encryption is as follows:
Figure 4. Structural change between the original file and the encrypted file
The Underground ransomware malware has been integrated with BCrypt APIs from the encryption preparation stage to the entire pre-encryption operation (random number generation, algorithm handle opening, mode setting, symmetric key generation, padding, encryption, etc.). All of these are included in bcrypt.dll. The following is a detailed description of the analysis on the encryption process.
In the first step of the encryption process, a 0x30-byte random number is generated using the RNG algorithm and the BCryptEncrypt() function. This random number is used in the subsequent AES encryption operation. The first 0x20 bytes of the generated random number are used to create the AES symmetric key, and the remaining 0x10 bytes are used as the initialization vector (IV) in AES encryption.
Figure 5. 0x30 bytes of random number generated by the RNG algorithm
The file to be encrypted is loaded into memory through the ReadFile() function into the memory allocated by the memory allocation method mentioned above. Then, the AES symmetric key is generated through the BCryptGenerateSymmetricKey() function, and the file content is encrypted through the BCryptEncrypt() function. Figure 13 below shows that a random value is used as the Secret value when generating the AES symmetric key.
Figure 6. Using a random value when generating a symmetric key for AES encryption
The threat actor encrypts the pbSecret value and the IV value used during encryption with an RSA public key and inserts it at the end of the file for decryption. The RSA encryption operation works in CBC mode. The encrypted pbSecret and IV data have a size of 0x200.
Figure 7. Encrypting the random value used in AES encryption with the RSA public key
Afterward, the encryption routine is designed to add the metadata used during encryption, such as the size of the original file, to the end (tail) of the file immediately after encrypting the original file. The GetFileSizeEx() function is used to obtain the size of the original file, and this file size is then used in a branching statement to create metadata and to treat the size and range of the encryption block differently. When encrypting large files, ransomware strains typically use this method to selectively encrypt areas that cause significant impact on users while reducing system load. The encryption targets are categorized as small, regular, and large files based on their file size, and the locations and frequency of encryption vary depending on the category.
For small-sized files, the entire area is encrypted. However, for normal and large files, a stripe method is applied where only the head and tail areas are encrypted first, and then the middle part is encrypted repeatedly at regular intervals (gap). During this process, the flag sets (Stripe, Head, Tail, Gap) used for each file size type have different fixed values, which determine the criteria for the encryption operation. These fixed values are used as the basis for the bitwise shift (shl) operation by 0x01, and the resulting value is calculated in a power of 2 form, representing the actual memory unit size.
As a result, the encryption unit and encryption gap are determined by the type of flag and its configuration value. This is a key method used by ransomware to control performance and speed. The table below shows the fixed values of Stripe, Head, Tail, and Gap according to the type of file.
The metadata information, including the File Size-based Flag set, is summarized in Table 4 below. The metadata has a total size of 0x18 bytes and is structured as shown in Figure 8.
| Offset | Size | Comment | ||||||||||
| 0x00 | 0x08 | Size of original file | ||||||||||
| 0x08 | 0x04 |
Flag set
|
||||||||||
| 0x0C | 0x04 | Trigger to branch by File Size | ||||||||||
| 0x10 | 0x04 | Presumed to be the Version value | ||||||||||
| 0x14 | 0x04 | Presumed to be the Magic value |
Table 4. Metadata information
Figure 8. Final metadata format
2.4 Removing Execution Traces
Upon completing all ransomware behaviors, it ultimately creates and executes the _eraser.bat file. This .bat script has the feature of deleting all event logs by utilizing wevtutil.exe, a Windows built-in utility.
Figure 9. Logic of creating eraser.bat
Users must back up important data to an offsite location separate from the service network to protect against ransomware, and implement access controls to the backup repository and conduct regular recovery training. Beyond simple data backup, it is essential to strategically ensure the security and recovery capability of the backup system.
3 AhnLab’s Response Status
The diagnosis name and engine date information of the AhnLab product are as follows.
3.1 V3 Diagnosis
Ransomware/Win.GROUNDE.C5771977 (2025.06.18.02)
Ransomware/Win.x64.C5768642 (2025.06.08.02)
Ransom/MDP.Behavior.M2813 (2020.03.24.03)
Ransom/MDP.Decoy.M1171 (2016.07.15.02)
Ransom/MDP.Event.M1946 (2018.06.06.00)
3.2 EDR Diagnosis
SystemManipulation/EDR.Event.M2486 (2022.07.09.00)
Ransom/MDP.Event.M1946 (2018.09.07.03)
Ransom/EDR.Decoy.M2470 (2022.09.30.00)
