MARCH 25, 2025

RaaS Evolved: LockBit 3.0 vs LockBit 4.0

Learn more about the LockBit ransomware group and explore the latest evolution of LockBit ransomware with its 4.0 version release.

LockBit is a sophisticated and notorious ransomware strain that has been targeting organizations across various industries since 2019. It operates by encrypting critical files and demanding hefty ransoms in exchange for decryption keys. The LockBit group operates on a Ransomware-as-a-Service (RaaS) model, providing its infamous LockBit malware to affiliates who carry out the attacks and return a percentage of ransom payments to the LockBit group.

The group is also known for its aggressive tactics, including double extortion, where they not only encrypt data but also threaten to release sensitive information if the ransom is not paid. With its rapid evolution and continuous development, LockBit remains one of the most dangerous and effective ransomware families in the cybercrime landscape.

The following blog details some of the key differences between LockBit 3.0, which has dominated the ransomware landscape over the last few years, and LockBit 4.0, the newest version of the ransomware. In addition to changes in operability, LockBit has eased deployment and added some evasion capabilities, while introducing a quiet mode that allows attackers to operate stealthily.

1_TimeLinepng.png
Figure 1: The evolution of LockBit ransomware

In September 2019 the ‘.abcd’ malware was first discovered. Just a few months later, the LockBit group took responsibility for the malware, eponymously dubbing it LockBit. In the years since, the LockBit group and its LockBit malware have continued to evolve, attracting new partners, gaining notoriety amongst hackers, and distributing new, more powerful versions of the malware.

In 2022, LockBit was responsible for more ransomware attacks than any other organization in the world. And by 2023, they were responsible for an estimated 44% of global ransomware attacks, coinciding with their LockBit 3.0 version.

On December 19, 2024, the LockBit group posted an announcement titled “Lockbit4.com” on their leak blog, revealing the upcoming release of a fourth version of the LockBit ransomware and marking the end of the LockBit 3.0 era. A timer counting down to February 3, 2025 was posted alongside an announcement promising rewards to the criminals who wanted to sign up and take part in the next era of ransomware proliferation.

IMG2_3.png
Figures 2 and 3: The pre-release and release notifications for LockBit 4.0

4_LockBit4_19_12_web.png
Figure 4: The LockBit 4.0 release date notification

The Release of Lockbit 4.0

Following the countdown, the LockBit group officially released LockBit 4.0 on February 3, 2025. The updated LockBit website featured five new Onion Domains with a new access key: ADTISZRLVUMXDJ34RCBZFNO6BNKLEYKYS5FZPNNXK4S2RSHOENUA. These domains were labeled “LockBit 4” and opening them took users to a login portal, with options to create a new account linked to either a BitCoin or Monero wallet.

After opening the link, users are presented with the following login portal:

5_Login_portal.png
Figure 5: LockBit system login/registration portal

After hackers execute an attack using the LockBit ransomware, LockBit 4.0 also provides a platform to securely negotiate with their victims. The platform features new Onion Domains which are attached to ransom notes and open chat support between the hackers and their targets. After opening the link, victims are asked to enter the ‘Decryption ID’ they received in their ransom note to verify their details.

6_login_chat_support.png
Figure 6: Login screen for chat support

Following detail and identity verification, victims are granted access to the chat.

In the chat, victims are sent three new URLs specifically for the File Upload Service for sample file decryption, supporting files larger than 10MB. This allows victims to confirm that the decryption works. Much of this attack and negotiation flow is similar to past versions of the LockBit ransomware. However, there are some key changes in how LockBit 4.0 operates compared to its most recent predecessor. 

7_Support_chat.png
Figure 7: Address to decrypt a sample set of files

The Packer

LockBit 3.0 featured a significant anti-analysis mechanism. The file was protected by a packer, and each version of LockBit 3.0 required a unique password to unpack it, making both static and dynamic analysis much more difficult. This feature was expected to continue.

Surprisingly, LockBit 4.0 takes a different approach, using a much simpler packer: a customized version of the UPX packer. And this time the packer isn’t password-protected. The advantage is that unpacking can now be done easily and manually, unlike in previous versions.

8_sample_in_VT.png
Figure 8: VirusTotal indicates a UPX packer was detected

We can easily locate the jump tail, jump to it, and retrieve the original code— essentially, we can locate the part of the program that directs us to the original code, skip over the packed sections, and restore it to its original form.

Image9_10.png
Figures 9 and 10: The code packed and unpacked

The Ransom Note

After files are encrypted, a ransom note appears in every folder, just like in the previous version. However, there are some subtle changes to the ransom note itself.

11_ransomnote.png
Figure 11: The ransom note

Unlike LockBit 3.0, LockBit 4.0 doesn't change the icon of the encrypted files to a custom LockBit icon. LockBit 4.0 also leaves the screensaver as is, leaves file names intact, and appends a random 12-character hash to the file extension, while LockBit 3.0 renames files and changes their extension to “.HLJkNskOq.”

New Parameters and Help Screen

LockBit 4.0 introduces slightly different parameters compared to LockBit 3.0. Notably, it adds the --help and -q parameters. The --help parameter allows users to view the available parameters and their functions:

12_arguments.png
Figure 12: The help screen describing the new parameters

The -q parameter specifies a quiet mode. This mode allows hackers to carry out attacks while keeping file extensions and modification dates intact after encryption. Additionally, no ransom note is dropped on the affected systems, making it more difficult to detect and investigate the attack.

Figure 13: The effect on files without using the -q parameter

14_with_q_parameter.png
Figure 14: The effect on files when using the -q parameter

The Encryption Method

LockBit 3.0 employed a partial encryption technique, encrypting portions of a file rather than the entire thing. This method sped up the encryption process and made it more efficient, minimized the chances of detection, and made the file unusable without the decryption key.

In some versions of LockBit 3.0, between 10-30% of the file is encrypted, focusing on critical sections like headers or initial data blocks. Other versions, however, only encrypt the first 4 KB of the file.

Similarly, LockBit 4.0 also employs partial encryption. In each cycle, it allocates memory for 9% of the file’s size. The data is read from the original file, encrypted, and written back to the file. Before the encryption process begins, the file size is checked; if it’s smaller than 1 KB, the entire file is encrypted instead.

Encrypted_method_new.png
Figure 15: The encryption function
Encryption Time

LockBit 3.0 encrypts files faster than LockBit 4.0. While LockBit 4.0 takes around 25 seconds to encrypt 1,000 files, LockBit 3.0 completes the same task in about five (5) seconds. These times can vary depending on factors like system performance, hardware, and load during each run.

16_LockBit4_time.png
Figure 16: The time it took LockBit 4.0 to encrypt 1000 files

17_LockBit3_time.png
Figure 17: The time it took LockBit 3.0 to encrypt 1000 files

Dynamic API Resolution

LockBit 3.0 imports most of its API functions during execution through a shellcode hashing mechanism. This process involves hashing the API names of a DLL, comparing them to a list of required APIs, and then retrieving the genuine API address using a circular shift and XOR operation.

In LockBit 4.0, the same dynamic method is used to discover functions, with slight modifications. The overall result is the same—the malware still obtains its functions dynamically. However, the key difference lies in how the DLLs are loaded. LockBit 4.0 employs proxy DLL loading, which bypasses the Event Tracing for Windows Telemetry Infrastructure (ETWTI) used by many security products. ETWTI relies on analyzing the stack trace, but with proxy DLL loading, the DLL is loaded through the RtlQueueWorkItem function. This causes the loading to occur in a separate thread, managed by a worker thread pool, resulting in a clean stack trace that avoids triggering ETWTI detection.

18_proxy_dll_API_resolution.png
Figure 18: Implementation of the proxy DLL loading method

DLLs Unhooking

DLL Unhooking is a variation of the DLL Hollowing technique designed to remap a DLL into memory. This process helps bypass security product hooks, making it harder for the malware to be detected within the system.

Lockbit 4.0 implements this technique by scanning through all the DLLs in the KnownDlls directory and creating a handle for each one using NtOpenSection. It then maps the DLL into memory with NtMapViewOfSection.

In the image below, you'll notice the ObjectName field is part of the OBJECT_ATTRIBUTES structure. This structure is passed to the NtOpenSection function, specifying the object that the function will operate on.

19_knowndll.png
Figure 19: The name of the DLL passed to the NtOpenSection function

Once the DLL is mapped into memory, the malware utilizes WriteProcessMemory to copy the contents of the new DLL into the memory space of the original DLL that was loaded by the operating system.

20_WriteProcessMemory_ida.png
Figure 20: The process of copying the new DLL

Vectored Exception Handler

Malware may remove its own Vectored Exception Handlers (VEHs) for several strategic reasons. One of the key motivations is to avoid detection by security tools that specifically monitor VEH registrations. By removing these handlers, the malware can bypass detection systems that scan for them as part of their monitoring processes. Additionally, removing VEHs helps prevent debugging or analysis during or after execution, making it harder for security researchers to reverse-engineer or analyze the malware's behavior. This tactic also aids in evading automated removal attempts by anti-malware software, which may be designed to identify and counter VEH manipulations.

The return_VEH function returns LdrpVectorHandlerList, which contains the list of vectored exception handlers. The malware then iterates through this list, removing each VEH using the RtlRemoveVectoredExceptionHandler function.

21_find_VEH.png
Figure 21: Removing vectored exception handler

Disabling DLL Loading Notifications

Another evasive technique implemented by Lockbit 4.0 is Disabling DLL Load Notification. This technique prevents endpoint detection products from receiving alerts about newly loaded DLLs within the current process context. This is achieved by blocking callbacks that are typically registered with LdrRegisterDllNotification. To properly unregister a DLL load notification callback, the LdrUnregisterDllNotification function is used.

22_LdrUnregisterDllNotification.png
Figure 22: Disabling DLL load notifications using LdrUnregisterDllNotification

Self-Deletion

Both LockBit 4.0 and LockBit 3.0 delete themselves from the disk, a behavior observable through ProcMon. However, the methods differ: LockBit 3.0 deletes itself by downloading a .tmp file and removes the contents of the Recycle Bin during the process. In contrast, while LockBit 4.0 also deletes itself, it doesn’t touch the Recycle Bin contents, nor encrypt them.

23_Lockbit4_self_deletion.png
Figure 23: LockBit 4.0 self-deletion

24_Lockbit3_self_deletion.png
Figure 24: LockBit 3.0 self-deletion

Conclusion

LockBit 4.0 introduces many new features focused on evading security products, but it also takes a few steps back from LockBit 3.0, including switching to a simpler packer, not removing Microsoft Defender, and encrypting more slowly. Despite these changes, much remains the same: partial encryption is still in play, and certain services continue to be disabled. The technique for evading Event Tracing for Windows (ETW) hasn’t changed either. Although LockBit 4.0 has enhanced its evasion techniques, its overall approach and behavior closely resemble those of the previous version. While it didn't innovate on certain tactics, organizations should remain vigilant as the threat remains just as dangerous

IOC's

Hashes:

3552dda80bd6875c1ed1273ca7562c9ace3de2f757266dae70f60bf204089a4a
33376f74c2f071ff30bab1c2d19d9361d16ebaa3dee73d3b595f6d789c15f620
21e51ee7ba87cd60f692628292e221c17286df1c39e36410e7a0ae77df0f6b4b

Onion domains:

lockbit3753ekiocyo5epmpy6klmejchjtzddoekjlnt6mu3qh4de2id.onion
lockbit3g3ohd3katajf6zaehxz4h4cnhmz5t735zpltywhwpc6oy3id.onion
lockbit3olp7oetlc4tl5zydnoluphh7fvdt5oa6arcp2757r7xkutid.onion
lockbit435xk3ki62yun7z5nhwz6jyjdp2c64j5vge536if2eny3gtid.onion
lockbit4lahhluquhoka3t4spqym2m3dhe66d6lr337glmnlgg2nndad.onion
lockbit6knrauo3qafoksvl742vieqbujxw7rd6ofzdtapjb4rrawqad.onion
lockbit7ouvrsdgtojeoj5hvu6bljqtghitekwpdy3b6y62ixtsu5jqd.onion


lockbitsprnigidq6imswpysqjg3sewkeagtfbamlybwm7fnonglhlyd.onion
lockbitspqldd3mm223vmzcvwntd7honhhan3ke72vpnrxexlrsu5ryd.onion
lockbitsppsg2kfcafzzdettjbgc4tx2cl6tfm4v4py6xtndbhnnhsid.onion
lockbitsppra2sj6gkfrgtavqds7rcnvhaxdio7jvu2xrozdr2ld3ead.onion
lockbitspomtxfihje6wepecgif7vuqci6zyl7qgenne5b6lxngf4yqd.onion

 

lockbitapyx2kr5b7ma7qn6ziwqgbrij2czhcbojuxmgnwpkgv2yx2yd.onion
lockbitapyum2wks2lbcnrovcgxj7ne3ua7hhcmshh3s3ajtpookohqd.onion
lockbitapp24bvbi43n3qmtfcasf2veaeagjxatgbwtxnsh5w32mljad.onion
lockbitapo3wkqddx2ka7t45hejurybzzjpos4cpeliudgv35kkizrid.onion
lockbitapiahy43zttdhslabjvx4q6k24xx7r33qtcvwqehmnnqxy3yd.onion

References