Author: S2W TALON (HuiSeong Yang)
First Published: Jan 19, 2026
This Figure was generated using Google Gemini Nano BananaExecutive Summary
- (Introduction) The LockBit ransomware group began independent operations under the name ABCD ransomware starting in September 2019, and updated to LockBit 5.0 in September 2025.
- (DDW History) After updating to LockBit 5.0, LockBit showed no activity on DLS (Data Leak Site) after May 2025. However, upon releasing LockBit 5.0 in September 2025, it significantly lowered the entry barrier by changing the affiliate sign-up fee to $500.
- After a reorganization period, it resumed activity in December 2025 and showed signs of restarting operations on XSS and RAMP forums. - (Analysis) LockBit 5.0 ransomware, also known as the ChoungDong version, is divided into a Loader and Ransomware component.
- Loader: Decrypts the ransomware payload using XOR and LZ compression and executes it in memory.
- Ransomware: Encryption method varies based on file size (up to 80MB), using the ChaCha20 + Curve25519 algorithm. - (Differences) The update from LockBit 4.0 to 5.0 significantly enhances analysis evasion and attack efficiency. It adds numerous new features like Mutex, Execution Delay, Status bar, Delete TEMP, and Wiper, while also overhauling the volume shadow copy deletion method and large file encryption logic.
- (Mitigation) To block malicious file execution and prevent internal penetration, continuously monitor process behavior and abnormal signs. Always apply antivirus software and the latest security patches to minimize intrusion through known vulnerabilities.
- Establish cyber attack response and security enhancement measures using the IoC, Detection Rules, and MITRE ATT&CK provided in the Appendix. Prepare to respond swiftly in the event of a security breach.
Introduction
The LockBit ransomware group was affiliated with the Maze ransomware cartel, but after Maze announced its retirement, it began operating independently under the name ABCD ransomware starting in September 2019. By the end of December 2019, it changed its name to LockBit while using the .lockbit extension. Starting in September 2020, it employed a double extortion strategy through its own leak site, and in June 2021, it updated its brand to LockBit 2.0. In June 2022, it released LockBit 3.0 through another update. Subsequently, LockBit demonstrated testing new weapons, including LockBit Green and ransomware targeting macOS. In December 2024, it updated to LockBit 4.0, adding some features to the existing LockBit Green ransomware based on the leaked Conti source code.
DDW History
DLS Activity
LockBit showed no activity on its Data Leak Site (DLS) after May 2025, but was updated to LockBit 5.0 in September 2025. This update significantly changed the affiliate recruitment method compared to the previous version, drastically lowering the entry barrier by allowing sign-up for a fee of only $500. This was judged a bold attempt to recover its diminished influence following Operation CRONOS and internal panel data leaks, and to restructure its attack ecosystem, suggesting it likely underwent an internal reorganization period.
Subsequently, starting in December 2025, it resumed activity by releasing new DLS domains for LockBit 5.0. According to an interview with HackManac, the core personnel of the Affiliate program remain intact, and the program was restructured around the remnants of the past to enhance operational efficiency. These circumstances are judged to be evidence supporting the conclusion that LockBit resumed operations with a new strategy after undergoing a period of organizational restructuring.
Figure 1. Activity on LockBit’s DLSForum Activity
LockBit hinted at a return in May 2025 through chats on the RAMP forum, and indeed resumed activity in December.
Figure 2. Activity on RAMP forumAdditionally, evidence emerged that LockBit attempted a return on the XSS forum. In February 2024, LockBit faced account suspension on the XSS forum due to a conflict with user @michon. Subsequently, in September 2025, LockBit conducted a vote to lift the suspension of the @LockBitSupp account, aiming to resume activity alongside updating to version 5.0. However, with 27 out of 49 total votes opposing the motion, the account’s suspended status remained unchanged.
Figure 3. Activity on XSS forumDetailed Analysis
This report details the functional changes observed at the binary level following LockBit’s version upgrade through in-depth analysis. The LockBit 5.0 binary is explicitly identified as the ChoungDong version in the ransom note, leading external parties to refer to this version as the ChoungDong version. ChoungDong is an overseas security analyst affiliated with Mandiant who previously published a detailed analysis of LockBit 4.0 on his personal blog. Given his confirmed history of analyzing major ransomware such as LockBit 2.0, 3.0, and Conti ransomware, it is presumed that the attackers named this version after citing the analyst’s name. The ransomware was divided into a Loader component and a Ransomware component.
Loader
Anti-Analysis
The binary contains anti-analysis techniques (Indirect JMP, Dummy Code) that hinder analysts’ analysis.
- Indirect JMP: All functions perform a JMP by calculating the address value each time they are called. Specifically, the calculation of the JMP address value is obfuscated using opaque predicates and MBA (Mixed Boolean Arithmetic).
Figure 4. Indirect JMP- Dummy Code: There exists dummy code that performs repetitive operations using a specific global variable.
Figure 5. Dummy CodeAPI Resolving
It dynamically fetches the APIs to use, calculates the name of each function to be used via a custom hash operation (seed: 0xA879), and loads it if it matches the given hash. Given that this operation was also used in LockBit Green, which was upgraded with the LockBit 4.0 update, this loader is also presumed to be one developed by LockBit.
Figure 6. API ResolvingHowever, in the LockBit 5.0 binary, unlike the LockBit Green sample that appeared in 4.0, an additional process has been added: allocating memory and inserting an opcode that jumps to an API within the allocated memory.
Figure 7. Opcode inserted into allocated memoryAnti-Debugging
Use the CheckRemoteDebuggerPresent and IsDebuggerPresent APIs to determine whether the currently running process is being debugged. If debugging is in progress, terminate the process.
Payload Decrypt
The payload is generated by XORing a random stream created by the PRNG (Xorshift128) with the compressed payload, and is then finally decrypted using the LZ compression algorithm.
- Xorshift128 Seed: 95 F7 D3 CD 2F A8 C6 79 55 44 76 0E 83 52 96 91
To check the state of the memory generated during this decryption process, magic numbers such as 0xCDCDBADD and 0xABABABA are used. If the value 0xCDCDBADD exists in memory, it indicates that the corresponding memory chunk is currently being decrypted. If the value 0xABABABA exists in memory, it indicates that the memory is in a usable state.
Process Hollowing
Execute the defrag.exe process located in the System32 directory and inject the decrypted payload into that process using the Process Hollowing technique.
Ransomware
Anti-Analysis
The ransomware contained obfuscated strings to hinder analysis. Similar to the loader, it underwent an API resolution process for API calls, followed by an indirect jump, and included dummy code.
API Resolving
It operates using the same custom hashing method as Loader, but we confirmed that its initial seed value is different, set to 0xB97A.
Check Country
Use APIs such as GetUserDefaultUILanguage and GetUserGeoID to determine whether the system is located in a Russian-speaking country. If the system is identified as Russian-speaking via either API, output the following message:
- Message: Found in GetUserDefaultUILanguage / Found in GetUserGeoID
Figure 8. Country identification codeParse CommandLine
Parses the command line executed via GetCommandLineW and CommandLineToArgvW. If it exceeds 500 characters, it outputs the following error message:
- Error Message: Error Command line is too long (max 500 characters).
Table 1. Actions by ParameterA help function exists that outputs all available parameters and their functions when the -h parameter is entered. The parameters confirmed through this are as follows, with the -b, -v, -d, -n, -w, and -t parameters added from those used in the previous LockBit 4.0 version.
Specifically, the -v and -d parameters allow you to check the encryption process. Depending on the encryption method, an error message will be displayed when using each.
- -v Error Message: Error -v option is not supported in this encryption mode Use -d for debug output
- -d Error Message: Error -d option is not supported with ‘all’ encryption mode Use -v for status bar
Figure 9. -h parameter outputThe encryption modes all, local, and net are Conti-based features also used in LockBit 4.0, and we confirmed they were adopted in LockBit 5.0 as well. The flag values used in the binary for each encryption mode are as follows. The LockBit 5.0 binary distinguishes the encryption mode to be used based on these flag values.
Table 2. Flags by Encryption ModeMutex
The -nomutex parameter existed in LockBit 4.0, but the actual process of creating a mutex did not exist. In the LockBit 5.0 binary, functionality to create a mutex to prevent duplicate execution has been added. The mutex name is as follows:
- Mutex Name: 05b50cbc-5b50-bc05–50cb-05b50cbc05b
If duplicate execution occurs, a message box is displayed with the following content:
- Message: Another instance is already running. If you need to run a second instance, use the -nomutex command line argument.
Execution Delay
Delays execution for 2 seconds using the ZwDelayExecution API.
Status Bar
-v parameter is provided, it creates a thread and outputs a status bar showing the current encryption state to the console window. This feature was not present in LockBit 4.0 and has been added in this version. You can see that due to a developer error, “ChounDong Locke v1.01” is output to the console window without the letter ‘r’.
Figure 10. Checking Encryption Progress StatusPrivilege Escalation
Elevate privileges by granting the Debug permission to the running process via ZwAdjustPrivilegeToken.
ETW Patch
Use ZwProtectVirtualMemory and ZwWriteVirtualMemory to overwrite the first instruction of the EtwEventWrite API with 0xC3, thereby disabling event tracing. This functionality also existed in LockBit 4.0. However, a difference exists in that while LockBit 4.0 overwrites the C2 14 00 byte, LockBit 5.0 overwrites the C3 byte.
Figure 11. Patched EtwEventWriteRansomNote
The ransom note and file extension used for encryption are decrypted at runtime, and the ransom note is embedded within the binary in encrypted form. Decryption is performed using RC4, with the RC4 key as follows:
- RC4 Key: 35 E5 EA 50 21 30 9D D5 62 71 AB 84 3F 55 01 0D
It then generates the Personal ID to be written in the ransom note, using the existing 16 bytes embedded in the binary plus 16 random bytes generated via PRNG. The embedded 16 bytes are presumed to be an identifier determined when the ransomware is built.
- Personal ID: Embedded 16 bytes + [Random 16 bytes]
Delete TEMP
This function targets the %TEMP% path under the C:\Users directory for each user. It identifies all files and directories using the FindFirstFile and FindNextFile APIs, then removes them all. This is presumed to reflect the attacker’s intent to enhance encryption performance by preemptively deleting unnecessary temporary files from infected systems.
Self Delete
Using NtSetInformationFile, the name of the currently running binary is changed to a random 6-character string. Then, NtSetInformationFile is called again to set the FileDispositionInformation value to FILE_INFORMATION_CLASS, configuring the file to self-delete when the process terminates. If the -k parameter exists, this functionality does not operate.
Delete Shadow Copy
After verifying whether the VSS service is running via QueryServiceStatusEx, initialize the COM object. Then, create the IVssBackupComponents interface using the CreateVssBackupComponentsInternal VSS API. Finally, delete the volume shadow copy using the DeleteSnapshots method within that interface. Subsequently, memory is freed using VssFreeSnapshotPropertiesInternal, and the process of deleting the volume shadow copy is finalized using the Release method and CoUnintialize.
While LockBit 4.0 directly used the volume shadow copy deletion method employed by Conti, LockBit 5.0 switched to creating the IVssBackupComponents interface via CreateVssBackupComponentsInternal.
Stop Services
The list of currently running Windows services is checked using EnumServicesStatusExA. When performing the custom hashing used during API resolution, matching hashes are terminated via ChangeServiceConfigA. The list of matching hashes is as follows.
Table 3. Service Suspend ListEncryption
Encryption identifies target files to encrypt via ZwQueryDirectoryFile in the main function. When identifying encryption target files, the following lists are excluded from encryption:
Table 4. Files, Folders, and Extensions Excluded from EncryptionAfter changing the file extension to a random 16-character string, if opening the target file with NtOpenFile fails, the FILE_INFORMATION_CLASS value is set to FileProcessIdsUsingFileInformation and the NtQueryInformationFile API is called to identify the process ID (PID) of the process currently opening the target file. Then, ZwQuerySystemInformation is used to scan all running process information on the system. If a match is found with the previously obtained PID, the process is terminated.
File encryption varies depending on the file size, specifically 80MB. The encryption method based on file size is as follows.
Table 5. Encryption Method by File SizeThe key generated during the encryption process is created through the following steps.
Figure 12. File Encryption Key Generation Logic- Generate a random 32-byte Master Key1.
- Use the first 32 bytes of the SHA-512 hash of Master Key1 as the ChaCha20 Key for file encryption.
- Use the first 24 bytes of the SHA-512 hash of the ChaCha20 Key as the ChaCha20 Nonce for file encryption.
- Encrypt the file using the ChaCha20 Key and ChaCha20 Nonce values.
To protect the Master Key1 used for encryption, the attacker encrypts that key using the Curve25519 algorithm. The process is as follows.
- Generate a random 32-byte Master Key2
- Perform an AND operation between the first byte of Master Key2 and 0xF8 / Perform an AND operation between the last byte and 0x3F and an OR operation with 0x40
- Perform Curve25519 operations on the resulting Master Key2 with Basepoint 9 (Secret Key1) / Perform Curve25519 operations on Master Key2 as the Public Key (Secret Key2)
- Concatenate Secret Key1 and Secret Key2 and perform SHA-512 hashing (Hash1)
- The first 0x20 bytes of Hash1 are used as the ChaCha20 Key. SHA-512 hash the ChaCha20 Key (Hash2)
- The first 0x10 bytes of Hash2 are used as the ChaCha20 Nonce value. Using the ChaCha20 Key and ChaCha20 Nonce value, encrypt 0x40 bytes of 0x00 (Encrypted NULL bytes)
- Encrypt 0x20 bytes of Master Key1 using the ChaCha20 Key and ChaCha20 Nonce value (Encrypted Master Key1)
- Perform Poly1305 operations on the 16-byte value (Poly1305 uses the first 32 bytes of the key stream generated during ChaCha20 key setup) and the 16 bytes from the 16th to the 32nd byte of the Encrypted Null bytes, adding them in 4-byte increments → If the sum results in a carry (exceeding 4 bytes), add 1 to the next 4 bytes to be processed (Calculated Poly1305) of the key stream generated during ChaCha20 key setup) and the 16 bytes from the 16th to the 32nd byte of the Encrypted Null bytes, adding them in 4-byte increments → If the sum results in a carry (exceeding 4 bytes), add 1 to the next 4 bytes to be processed (Calculated Poly1305)
The first 32 bytes of the Encrypted Master Key1, Calculated Poly1305, and Secret Key1, generated through the logic encrypting the file’s encryption key, are written to the File Footer before encryption. The entire File Footer structure is as follows.
Figure 13. File Encryption Key Encryption LogicThe overall encryption process remains largely unchanged from LockBit 4.0, but logic for encrypting large files has been added, and the method for encrypting the file encryption key and the File Footer have been significantly modified.
Network Encryption
Network encryption operates identically to LockBit 4.0: it identifies IP addresses capable of connecting to the internal network, attempts to connect to the SMB port, and then uses NetShareEnum to retrieve and encrypt network shared files from the connected addresses. The internal network IPs targeted for encryption are as follows.
Table 7. List of Local IPDelete EventLog
After encryption is complete, to hinder system analysis, it does not delete event logs via standard commands. Instead, it opens a session to the victim system using EvtOpenSession and then executes EvtClearLog. Specifically, EvtOpenSession attempts to connect to the victim system (itself) by setting the EVT_RPC_LOGIN structure to NULL. It then uses EvtOpenChannelEnum and EvtNextChannelPath to identify the names of event channels within the connected session. The logs for these identified event channels are subsequently deleted via EvtClearLog.
This functionality also exists in LockBit 4.0, but in LockBit 5.0, the logic was modified to perform the deletion after encryption.
Wiper
When the -w parameter is provided, the Wiper function is executed. This function runs the defrag.exe or svchost.exe process and injects a payload containing the Wiper functionality using the Process Hollowing technique.
- Wiper MD5: d57a61761cc5a210207a42eaa223f40d
This payload creates files named 1.tmp and 2.tmp on the drive and repeatedly writes 4MB of data to them. This writing continues until the disk space is full and the WriteFile API call fails. Once writing is complete, the temporary files created are deleted.
This functionality is a new addition in LockBit 5.0 and is believed to have been added by the attacker to hinder forensic analysis of the system.
Differences From LockBit 4.0
With LockBit’s update to version 5.0, the LockBit binary has undergone a comprehensive structural overhaul. Anti-Analysis features designed to hinder analyst investigations have become more complex and robust than before. The process for deleting Volume Shadow Copy (VSS) copies has also been updated to utilize the VSS API while retaining the existing Conti-based module. Notably, significant changes have been observed in the encryption method.
File extensions have changed to random 16-character strings, differing from previous versions. Logic has been added to terminate processes using a file before encryption. Furthermore, logic applying different encryption methods based on file size has been introduced, significantly enhancing the sophistication and efficiency of the entire encryption process.
Additionally, new features not present in previous versions have been added. While LockBit 4.0 lacked mutex functionality and only included the -nomutex parameter, LockBit 5.0 now incorporates mutex capabilities. Convenience features have been revamped, allowing attackers executing the ransomware binary to debug the encryption process during execution using the -v and -d parameters. Furthermore, the ransomware maximized operational efficiency by deleting unnecessary files and directories within the TEMP folder. The addition of a Wiper function was also confirmed, intended to hinder analysts’ forensic investigations.
The following table compares LockBit 4.0 and 5.0. Items marked in red indicate updates to existing features, while those marked in yellow represent newly added features not present in the previous version.
Table 8. Comparison of LockBit 4.0 and LockBit 5.0Conclusion
- The LockBit group has resumed operations as LockBit 5.0 following organizational restructuring, significantly lowering entry barriers — such as reducing the affiliate recruitment fee to $500 — to recover its diminished influence after Operation CRONOS and rebuild its attack ecosystem.
- The LockBit 5.0 binary features enhanced anti-analysis capabilities and incorporates numerous new functions absent in LockBit 4.0, such as Mutex, Execution Delay, Status bar, Delete TEMP, and Wiper, improving attack efficiency and stealth.
- Significant changes were observed in core functionality compared to LockBit 4.0, including a Conti-based volume shadow copy deletion module now utilizing the VSS API, and improved encryption efficiency through differential encryption methods based on file size.
- To block malicious file execution and prevent internal penetration, continuously monitor process behavior and abnormal signs. Always apply antivirus software and the latest security patches to minimize intrusion through known vulnerabilities.
- Establish cyber attack response and security enhancement measures using the IoCs, Detection Rules, and MITRE ATT&CK provided in the Appendix. Prepare to respond swiftly in the event of a security breach.
Appendix A. IoC
IoC list can be found our github
Appendix B. Detection Rule
Detection Rules can be found our github
Appendix C. MITRE ATT&CK
Privilege Escalation
- (T1548.002) Bypass User Account Control
Defense Evasion
- (T1027.002) Software Packing
- (T1027.007) Dynamic API Resolution
- (T1055.012) Process Hollowing
- (T1070.004) File Deletion
- (T1070.006) Timestomp
- (T1070.001) Clear Windows Event Logs
- (T1622) Debugger Evasion
- (T1678) Delay Execution
Discovery
- (T1082) System Information Discovery
- (T1007) System Service Discovery
- (T1057) Process Discovery
- (T1083) File and Directory Discovery
Impact
- (T1486) Data Encrypted for Impact
- (T1490) Inhibit System Recovery
- (T1561.001) Disk Content Wipe
copyrightⓒ 2025 All rights reserved by S2W Inc.
Detailed Analysis of LockBit 5.0 was originally published in S2W BLOG on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://medium.com/s2wblog/detailed-analysis-of-lockbit-5-0-de92c03441f8?source=rss----30a8766b5c42---4