BlackLock is a relatively new ransomware group that is believed to have been established around March 2024. Their existence was publicly revealed in June 2024 when the Dedicated Leak Site (DLS) was identified. At that time, information on multiple affected companies had already been posted, suggesting that the gang had been active in secret for several months. The group initially operated under the name El Dorado and rebranded to BlackLock around September 2024. This post provides a summary of AhnLab SEcurity intelligence Center (ASEC) report that analyzes the characteristics, encryption methods, and technologies used by the threat actors to decrypt files, providing insights to help readers prepare for similar threats in the future.

 

1. Overview

1.1. BlockLock

BlackLock ransomware is written in Go, a cross-platform programming language. This allows the malware to target Windows, Linux, and VMware ESXi environments, indicating a broad attack surface and the ability to simultaneously compromise diverse operating systems.

While most of its confirmed victims are based in the United States, including enterprises and local government agencies, attacks have also been reported in South Korea, Japan, and other countries. Affected sectors include public institutions, consulting, education and research, transportation, construction, manufacturing, and even golf resorts.

Linguistic patterns in the malicious code and communication behavior suggest that the BlackLock developers are Russian speakers. The group has also promoted its operations on RAMP, a Russian-speaking cybercrime forum. BlackLock operates under a Ransomware-as-a-Service (RaaS) model, actively recruiting skilled hackers to expand its affiliate ecosystem.

Figure 1. BlackLock DLS

 

2. Analysis

BlackLock ransomware is developed in Go, which supports cross-platform. By utilizing the Go standard library, it is easy to create a binary that can be executed on various operating systems with a single code. Go is also suitable for ransomware development because it allows encryption features to be easily implemented through built-in packages such as encoding and crypto.

For Windows environments, the ransomware uses open-source projects like go-smb2 to scan and access SMB shared folders, reducing development time and ensuring stable functionality.

 

2.1. Initial Routine

Upon execution, BlackLock ransomware supports various command-line arguments to enable or disable specific features. If launched without any options, it defaults to encrypting the entire local drive.

The supported options are as follows:

 

Execution Option	Description
-path	Specifies path to encrypt
-delay	Start delay time (min)
-time	Sets start time (Format: HH:MM)
-perc	Percentage of blocks (1 MiB each) to be encrypted
-threads	Number of threads to use for encryption
-keep	Does not delete itself after the task is finished
-skip-local	Skips encryption task for local drive
-n	Specifies the target network/host range to be scanned remotely
-u	Username to be used when accessing the SMB share folder
-p	Plain text password to be used when accessing SMB shared folders
-h	NTLM hash to be used when accessing SMB shared folder
-skip-net	Skips encryption task for SMB shared folders
-yes	Not implemented
-test	Test mode (Encryption disabled)
-hide	Hides console output for logs
-log	Specifies log file path
-esxi	Not implemented
-sort	Descending order of folders to be encrypted

Table 1. Description of execution arguments

 

Additionally, it is worth noting that a feature is available for targeting the VMware virtualization platform ESXi, called ‘-esxi’ option. However, in the analyzed sample, the option is only present and the actual feature is not implemented. Furthermore, the threat actor’s effort to enhance the efficiency of their attacks can be seen in their considerations, such as using the ‘-sort’ option to encrypt important folders first or the ‘-perc’ option to encrypt only parts of files.

 

2.2. Encrypting Files

BlackLock uses Go’s crypto package to perform file encryption. It creates a stream cipher using ChaCha20.NewUnauthenticatedCipher(), which requires a FileKey and Nonce—both randomly generated for each file.

 

Figure 2. Generating a random FileKey (32 bytes)

 

 

Figure 3. Random nonce generation (24 bytes)

 

The FileKey and nonce are used as arguments for NewUnauthenticatedCipher() to create the XChaCha20 stream cipher, which then encrypts the file via XORKeyStream().

 

 

2.3. Storing Key and Metadata

Threat actors with financial motives always have procedures in place to recover encrypted files. If the files cannot be decrypted, it damages the threat actor’s reputation, and victims are less likely to pay the ransom. To ensure files can be decrypted after ransom payment, BlackLock appends encryption key and metadata to the end of each file. When the victim pays the ransom, BlackLock can use the additional information at the end of the file to decrypt it. The process is shown in Figure 5 below.

 

Figure 4. Data added for decryption

 

However, if the metadata is added in plaintext, the FileKey is exposed, allowing victims to decrypt their files themselves. To prevent this, the ransomware encrypts the metadata with a shared key.

The shared key is obtained using the Elliptic Curve Diffie-Hellman (ECDH) key exchange. This involves combining their own private key with the other party’s public key to generate the same shared key. In the case of a ransomware infection, the shared key is generated as follows:

– Attacker’s shared key: ECDH (attacker’s private key, victim’s public key)

– Victim’s shared key: ECDH (victim’s private key, attacker’s public key)

Despite using different input keys, both parties derive the same shared key due to ECDH’s properties. BlackLock embeds the victim’s public key and attacker’s public key within the ransomware to facilitate this process.

 

Figure 5. Shared key generated using ECDH (32 bytes)

 

The metadata is then encrypted using secretbox.Seal() with the shared key and Nonce, and appended to the file. A final Length field is added to indicate the combined size of the Nonce and encrypted metadata, completing the encryption routine.

 

2.4. Ransom Note

The following figure shows the screen after the BlackLock ransomware infected the system. The desktop background remains the same, but the files are encrypted and renamed with random extensions.

 

Figure 6. After encryption

 

A ransom note titled HOW_RETURN_YOUR_DATA.TXT is dropped in every directory where encryption has occurred.

Figure 7. Ransom note (HOW_RETURN_YOUR_DATA.TXT)

The ransom note informs the victim that their data has been encrypted and includes threatening language. If the ransom is not paid, the attackers warn they will disrupt the victim’s business website or leak sensitive data to customers and the public.

 

2.5. Deleting Backup Data

Once BlackLock completes its encryption routine, it proceeds to delete data stored in Volume Shadow Copy Service (VSS) and the Recycle Bin, effectively removing potential recovery options. Unlike typical ransomware strains that execute WMI queries directly via command-line instructions, BlackLock takes a more covert approach. It constructs a COM object instance capable of executing WMI queries, which it uses to enumerate and delete shadow copies. This process is carried out by shellcode, which the ransomware loads and executes directly in memory, eventually making detection more difficult.

 

Figure 8. Shellcode execution (Volume Shadow Data deletion feature)

3. Conclusion

BlackLock is currently one of the most active ransomware groups, with attacks observed across a wide range of industries rather than being limited to a specific sector. As detailed in the original report, the ransomware generates a unique encryption key for each file and further encrypts those keys using a shared key, making recovery extremely difficult without the attacker’s cooperation. In Windows environments, BlackLock targets not only local drives but also SMB shared folders, significantly increasing the potential impact. Moreover, the ransomware is capable of being built for Linux and VMware ESXi systems, further broadening its reach and making it a formidable cross-platform threat.

To protect critical assets and ensure operational stability, organizations are strongly advised to follow the response guidelines outlined in the original report.

 

 

4. AhnLab’s Response

 

The following are the detection names and engine information of AhnLab products.

 

4.1. V3

Ransom/MDP.Behavior.M2649 (2022.09.06.00)

Ransom/MDP.Decoy.M1171 (2024.09.06.02)

Ransom/MDP.Event.M1946 (2024.07.30.00)

Ransom/MDP.Event.M1785 (2024.08.20.03)

Ransom/MDP.Event.M4353 (2022.07.14.02)

Ransom/MDP.Event.M4428 (2022.09.05.02)

Trojan/Win.Generic.C5775331 (2025.07.02.02)
 

4.2. EDR

Behavior/DETECT.Event.M2662 (2024.06.04.00)
 

MD5

f392807da3ee1f3e9702ce5fa91d418d