In-Depth Analysis Report on LockBit 5.0: Operation and Countermeasures

In-Depth Analysis Report on LockBit 5.0: Operation and Countermeasures

Since its first appearance in September 2019, LockBit has been known as one of the most notorious and active Ransomware-as-a-Service (RaaS) groups worldwide. LockBit operates on the RaaS model and is characterized by sophisticated encryption technology and automated propagation capabilities. Initial access is typically gained through vulnerability exploits, brute force attacks, phishing, or leaked login credentials, and the attack follows a three-stage process: initial access, lateral movement and privilege escalation, and ransomware deployment. The group also uses the Stealbit tool to exfiltrate data. From August 2021 to August 2022, LockBit accounted for 30.25% of known ransomware attacks, and in 2023, it made up around 21% of the attacks. The group’s extortion demands and recovery costs have resulted in billions of dollars in losses. Despite the efforts of law enforcement agencies, LockBit continues to pose a serious threat to cybersecurity worldwide.

 

The LockBit 5.0 ransomware group operates the DLS website, which lists the companies that have been successfully breached by the group. While no South Korean companies are included on the list, many foreign companies have been identified as victims. The group has launched ransomware attacks against companies in a wide range of industries, including IT, electronics, law firms, and churches.

 

Analysis Details

LockBit 5.0 can receive various parameters upon execution, but it can operate normally without any parameters. To prevent recovery, it terminates VSS-related services and applies packing and obfuscation to make static analysis difficult. The group also utilizes the ChaCha20-Poly1305 and X25519+BLAKE2b-based key exchange algorithms. The encrypted files cannot be decrypted using only local system information, and the encryption ratio varies depending on the file size.

 


Figure 1. LockBit 5.0 displaying help information

 

Encrypting

Deleting files in the Temp directory is intended to improve encryption speed by removing unnecessary files in the Temp directory, which primarily consists of cache or temporary data, since the encryption targets are mainly the user’s valuable files.

 

Path of the Temp folder that is being deleted

C:\Users\All Users\AppData\Local\Temp
C:\Users\Default\AppData\Local\Temp
C:\Users\Public\AppData\Local\Temp
C:\Users\{Username}\AppData\Local\Temp

Table 1. Temp folder paths that are deleted

 

To prevent collisions during the encryption process and to block the operation of backup and security solutions, the automatic execution of core system services is disabled and immediately stopped. The services to be stopped are hard-coded in hash value. The identified items are listed in Table 2, and the unidentified items are listed in Table 3.

 

Suspended service
BackupExecVSSProvider VSS vmms
WSearch EdgeUpdate AcrSch2Svc
VeeamTransportSvc MicrosoftEdgeElevationService BackupExecAgentAccelerator
AcronisAgent BackupExecJobEngine GxFWD
VeeamNFSSvc BackupExecRPCService edgeupdatem
BackupExecManagementService GxCVD  

Table 2. Discontinued services

Suspended service

0x826AC445, 0x83143F70, 0xFEF56F16, 0x10D06066, 0xBEC3470C, 0xC347B317, 0xCA6C4394, 0x5EF504FC, 0x9757464E, 0x9A768D62, 0xA1816235, 0x369D7114, 0xE11A285D, 0xE5C9CC93, 0x732AA0C0, 0x7ABD1404, 0x9439954E, 0x9655130F, 0x23FA53E5, 0x2C1F8E5F, 0xDBECA3C3, 0xDCF04E8C, 0x60B29D14, 0x62C32884, 0x6337AD82, 0xA8F16BAB, 0x41278147, 0x4292EDD8, 0xE7AA4057, 0xE7BF305D, 0x7DD43601

Table 3. Services that are subject to termination

 

To prevent the encryption of key system files and the destruction of system stability, certain files and folders are excluded from encryption. This includes Windows folders and executable files such as exe, dll, and sys that are essential for system operation.

 

Directories excluded from encryption

Windows, $Recycle.Bin, AllUsers, Boot, chocolatey, Microsoft Office, Microsoft Visual Studio, Windows Kits, WindowsApps, VisualStudio, System Volume Information, Microsoft\Windows

Table 4. Directories excluded from encryption

 

Files excluded from encryption

iconcache.db, thumbs.db

Table 5. Directories excluded from encryption

 

Extensions excluded from encryption

exe, lnk, dll, cpl, sys, extensions that change during encryption

Table 6. Directories excluded from encryption

 

During encryption, the file extension is not fixed. Instead, a custom hash function based on a random number generates 100 extensions, each 8 bytes long, which are then applied sequentially. This extension list is newly generated each time the LockBit 5.0 ransomware is executed.

 


Figure 2. List of created extensions

 

File Encryption

LockBit 5.0 ransomware uses the ChaCha20-Poly1305 algorithm for file encryption and applies X25519 + BLAKE2b for key exchange. It generates two 32-byte random values based on the system time and memory information and uses the first and last bytes of the second random value in an operation to derive the private key. It then uses this victim’s private key to create the victim’s public key through the elliptic curve encryption algorithm and combines the victim’s private key with the threat actor’s public key to derive the shared secret value.

 

If the file size is 0x5000000 or less, the first random value is processed by the BLAKE2b hash algorithm and a hash value is generated. The ChaCha20 key stream is then created based on this hash value. The generated key stream combines the top 16 bytes with the bottom 16 bytes to form a 32-byte key, which is used to create the file encryption key stream. This key is used to create a 64-byte ChaCha20 key stream, which is used to perform an XOR operation on the data to be encrypted, ultimately encrypting the file.

 


Figure 3. Random number, private key, public key, and shared secret creation

 

After encryption is complete, additional information is recorded at the end of the encrypted data. The added data includes the file size, the file size value converted to a custom hash, the value encrypted with ChaCha20, the Poly1305 value, and the victim’s public key.

 


Figure 4. Structure of a file with a size of 0x5000000 or less

 

If the file size exceeds 0x5000000, the data is encrypted in 0x800000 units and then the lower 0x80 bytes of each piece are processed by a custom hash function to create an 8-byte hash value, which is then added after the encrypted file data.

 


Figure 5. Structure of the file when the file size exceeds 0x5000000

 

Ransom Note

The ransom note claims that the threat actor exploited vulnerabilities in the corporate network to breach the system and encrypt all accessible data. It warns that if the victim attempts to recover the data on their own or uses an external recovery service, decryption will become impossible, resulting in permanent data loss. The threat actor also threatens to delete the decryption key and either leak the data on the dark web or sell it if the victim discloses the breach to external parties or law enforcement.

 


Figure 6. Ransom note (ReadMeForDecrypt.txt)

 

AhnLab’s Response

The detection name and engine date information of the AhnLab product are shown below.

 

V3

Ransomware/Win.LockBit.C5798524 (2025.09.17.00)
Ransomware/Win.LockBit.C5799278 (2025.09.19.00)

 

EDR

Ransom/EDR.Decoy.M2470 (2022.09.29.03)

 

MD5

95daa771a28eaed76eb01e1e8f403f7c
97e97e8cde5cc795b4d0a1fb7202b5ed
c15a79d4b3c17bdb01edb097bae53212
c462c6b02b35df2910689947c5090fae
cd6e182fe655724f3d8e711b451a2e93