19 Shades of LockBit 5.0, Inside the Latest Cross-Platform Ransomware: Part 3

In the first two parts of ourLockBit 5.0 series, we provided a comprehensive analysis of this cross-platform ransomware’s ESXi and Linux variants. This final installment features our analysis of LockBit 5.0’s Windows variant.

Windows Variant Analysis

Introduction

Following our analysis of the LockBit 5.0 Linux/ESXi variants — blunt instruments designed to indiscriminately encrypt data at the hypervisor layer — we now turn to the Windows build, a scalpel engineered to sever enterprise security controls. The recently discovered samples introduce advanced evasion capabilities, including a custom loader with anti-debugging and geolocation checks, Event Tracing for Windows (ETW) patching to blind the agent’s telemetry, stealthy shadow copies deletion via COM, and a unique hashing algorithm to mask its artifacts: importing table, services, and process names.

Most critically, our analysis reveals a pre-encryption "kill list" that does not merely stop services, but systematically dismantles the specific infrastructure required for business continuity. By resolving those, we identified the attacker's intention regarding enterprise backup solutions, virtualization platforms, and critical business databases.

This post details malware’s core capabilities, highlighting some differences from their predecessors and how the Cybereason Defense Platform detects the underlying behavior.

Windows Version ChuongDong Locker

Figure 1. Lockbit 5.0’s process tree.

Loader's Functionality

Upon execution, the malware loader spawns defrag.exe, a legitimate Microsoft Windows command-line utility, in a suspended mode to execute ransomware. Its main goal is to hide payload execution under a legitimate process using the Process Hollowing technique (T1055.012) without dropping any additional artifacts on the disk. To do this, the loader allocates memory within the target process, copies the ransomware payload, updates the thread context to point to the new entry point, and resumes thread execution to mask malicious activity.

The malware employs dynamic API resolution, enabling it to resolve function addresses at runtime and execute calls indirectly, thereby bypassing the static Import Address Table (IAT) — a very common step for packers and custom loaders. This process is achieved by manually mapping and parsing the Export Tables of ntdll.dll and kernel32.dll directly from disk. The specific sequence of Windows API calls observed during this manual mapping phase is: GetModuleFileNameW, CreateFileW, GetFileSizeEx, CreateFileMappingW, MapViewOfFile, and CloseHandle.

Figure 2. Loader’s indirect API dispatch stub.

In Figure 2, we see a packer stub with position-independent code (shellcode) that starts with a NOP sled, arguments preparation (for 64-bit calling convention), and jumping to an address stored in register with the API address of the targeted function (i.e., MapViewOfFile).

Resolving APIs from DLLs loaded in memory could potentially expose the malware to inline user-mode hooks injected by security solutions (such as EDRs, AVs, and malware sandboxes). The loader's technique of mapping the file directly from disk is a bypass mechanism: It retrieves the original, unmodified code, thereby circumventing any security instrumentation or monitoring tools operating within RAM.

LockBit 5.0 variants employ two main evasion techniques: anti-debugging and self-deletion.

Anti-debugging:

The malware checks for the presence of a debugger using calls to CheckRemoteDebuggerPresent, which internally invokes NtQueryInformationProcess (with ProcessDebugPort value), and IsDebuggerPresent.

Self-delete:

This variant utilizes a non-standard self-deletion method. The loader first renames itself on the disk to a random name (e.g., :rzSEzls) using Alternative Data Streams (ADS). This action effectively removes the file from the visible directory listing while keeping its file handle open. Immediately afterward, the process sets the FileDispositionInfo flag to Delete via SetFileInformationByHandle. Because the file was moved to an alternate stream, the operating system permits the deletion flag even though the process is currently mapped and executing.

Earlier variants of LockBit (such as LockBit Black 3.0 samples: 68dd3226bbeac27834e003e24d859baf, dfae96c3571d7d8a76333f40cb2cc6d1) were also observed cleaning up temporary payloads dropped in user-writable locations (e.g., ProgramData), still they relied on less sophisticated artifact deletion commands, such as:

cmd.exe /C DEL /F /Q [path to the temp file] >> NUL.

API Hashing

As previously mentioned, this malware heavily relies on dynamic API resolution to circumvent manual analysis. The following algorithm is used to calculate custom hashes for API resolution:

Below is a Python implementation with a parameterized seed (highlighted value), which differ for different samples:

The malware performs a runtime hash lookup over exported API names to resolve requisite function addresses. Below is the list of resolved names used by the loader:

Names restoration was achieved by computing the hash values for all exported functions within standard system DLLs (ntdll.dll, kernel32.dll, advapi32.dll, etc.) and matching them against the hashes found in the binary. This process allowed for the full resolution of the malware’s API interactions and behaviors (including dormant ones).

Figure 3. Disabling Event Tracing (32-bit system) referencing API hash value

Apart from geofence API checking (GetUserDefaultUILanguage, GetUserGeoID), the following resolved APIs are notable:

• Volume and File Enumeration: Employing FindFirstVolumeW, FindFirstFileA, FindNextFileA, and SetVolumeMountPoint to discover all available storage, including mounting hidden or unassigned partitions to ensure total encryption coverage.

• Privilege Escalation and Token Manipulation: Utilizing AdjustTokenPrivileges, DuplicateTokenEx, OpenProcessToken, LogonUserExExW, and CreateProcessAsUserW to manipulate access tokens, allowing the malware to elevate privileges or impersonate users (e.g., SYSTEM) for unhindered execution.

• Service Suppression Module: Leveraging OpenServiceW, ControlService, EnumServicesStatusExA, and CloseServiceHandle to enumerate and stop specific running services — typically security-, backup-, or database engines — to release file locks before encryption.

It’s worth noting that the same hashing algorithm is used to resolve the service names the malware tries to stop before proceeding with encryption. The following hashed process names and their potential usage were found in the payload:

Main Ransomware Payload

Static analysis of the main payload identified numerous characteristic strings in plain text.

A notable finding is the inclusion of a status/progress bar format string within the ransomware payload, designed to offer visual feedback during the encryption process — a feature previously absent in earlier versions and indicative of the ESXi variant. The payload also includes references to user instructions, such as prompts to press specific buttons to either abort or continue the process in the background.

Figure 5. LockBit 5.0 encryption progress bar logging.

We also found other file operation-specific output strings found in the injected payload:

Figure 6. File operation logging.

The payload contained numerous readily identifiable, characteristic strings in plain text (both ASCII and Unicode). These included elements such as the command-line used to terminate processes by PID and the ransom note’s filename, which are easily recognizable and can be quickly utilized to create static detection rules (i.e., YARA) based on memory artifacts.

Figure 7. LockBit 5.0 characteristic strings.

Ransom Note

Unlike the aforementioned characteristic strings, the encrypted ransomware note is hidden within the executable and only decoded during execution. The malware uses the RC4 algorithm with a hardcoded key to recover the plaintext at runtime. The decryption key is as follows:

31 4c DD 51 34 F3 A1 CB BC DB 6B 06 B0 54 E8 63

Figure 8. RC4 algorithm for ransom note decryption.

Unlike LockBit 3.0 (Black), which aggressively announced its presence by modifying the Control Panel\Desktop\Wallpaper registry key to force a custom background, LockBit 5.0 deliberately omits this step. This departure marks a strategic shift: rather than prioritizing "shock value," the malware prioritizes stealth, avoiding registry modifications that could alert security sensors.

Personal Identifier

The personal identifier referenced in the ransom note is 32 bytes long: The first 16 bytes are embedded within the binary, while the remaining 16 bytes are generated dynamically at runtime.

Figure 9. Ransom note.

Command-Line Options

Upon execution, using the “--help” command-line argument, the malware displays usage information (as shown in Figure 9). If the usage information exceeds500 characters, a message appears with the words “Command line is too long (the maximum limit is 500 characters)”.

When executed with the “-v” argument, the malware displays verbose output, including the number of files encrypted out of the total target files, the cumulative size of data to be encrypted, and the estimated time remaining (ETA). Once the file enumeration phase is complete, the malware immediately begins encryption. A progress bar is displayed to indicate the remaining encryption time (as shown in Figure 11).

The “-d” argument enables debug mode, displaying encryption progress, file counts, and encrypted file names.

Using the “-nomutex” flag causes the malware to execute without creating a mutex, allowing multiple instances to run simultaneously.

Figure 10. LockBit 5.0 command-line options “help” menu.

Figure 11. Verbus output using “-v” argument.

Language-Based and Geolocation Encryption Avoidance

Before execution, the ransomware checks whether the user is Russian or located in the Philippines. If either condition is met, it displays a message box (as shown in Figure 12) and terminates. To perform these checks, the malware uses the functions GetUserDefaultLanguage and GetUserGeoID:

• GetUserDefaultUILanguage – the return value is compared against 0x419 (1049 decimal), which corresponds to Russia (as shown in Figure 13).
• GetUserGeoID – the return value is compared against 0xC9, indicating that the current user’s geographical location, as defined in the “Regional and Language Options” settings, is the Philippines (as shown in Figure 14).

Figure 12. A message box will appear if a Russian keyboard layout is detected or if the user is located in the Philippines.

Figure 13. Checking if the keyboard layout is Russian(0x419) using GetUserDefaultUILanguage

Figure 14. Checking if the user’s location is the Philippines(0xC9).

In previous variants (i.e., LockBit Black 3.0), the HKCU\Control Panel\International\Geo\Nation registry key was used to check country codes. Additionally, in LockBit 4.0, the GetKeyboardLayoutList function was used to check if the keyboard language is in Russian.

API Hook Detection and Removal

The ransomware evades antivirus and endpoint detection and response (EDR) monitoring by detecting API hooks at the beginning of Windows API functions.

It inspects the initial instructions for common jump opcodes such as 0xE9 and 0xFF && 0x25, which are typically used by security solutions to redirect execution to monitoring routines.

When a hook is identified, the malware modifies memory protections and restores the original instructions from a trusted mapped copy, allowing API calls to execute normally and bypass telemetry and detection mechanisms.

Figure 15. Runtime detection and removal of security API hooks.

Disabling ETW Telemetry

Another technique the ransomware uses to evade detection is disabling ETW telemetry.

Event Tracing for Windows (ETW) is a Windows logging framework leveraged by antivirus and EDR solutions to collect system and security telemetry for monitoring and detection.

To suppress this mechanism, the ransomware uses NtProtectVirtualMemory and NtWriteVirtualMemory (shown in Figure 16) to overwrite the first instruction of EtwEventWrite with a ret instruction (0xC3), ensuring that any subsequent calls to the function immediately return without generating events.

Figure 16. NtWriteVirtualMemory is used to overwrite the first byte of EtwEventWrite with a 0xC3 (ret) instruction.

Figure 17. Before overwriting the first byte of EtwEventWrite with a ret instruction

Figure 18. After overwriting the first byte of EtwEventWrite with a ret instruction.

Single-Instance Execution Control

The ransomware creates a mutex to ensure that only a single instance of itself runs on the system. It does so by invoking the Windows API function CreateMutexW with the mutex name “05b50cbc-5b50-bc05-50cb-05b50cbc05b5”. In case of duplicate execution, a pop‑up message warns about multiple instances and suggests running the ransomware with the “-nomutex” flag (Figure 20).

When executed with the “-nomutex” argument, the ransomware runs without creating a mutex.

Figure 19. Creating mutex with the name “05b50cbc-5b50-bc05-50cb-05b50cbc05b5”

Figure 20. A pop-up message warns about multiple instances of the ransomware running.

Deleting User Temp Folder

The ransomware locates and enumerates each user’s temporary directory under C:\Users, then systematically deletes its contents. The APIs FindFirstFile and FindNextFile are used to iterate through files and subdirectories, while DeleteFileA and RemoveDirectoryA remove files and empty folders. This behavior eliminates temporary data that could assist recovery or removes forensic artifacts.

Volume Shadow Copy Deletion

Initially, the ransomware verifies whether the Volume Shadow Copy Service (VSS) is enabled by opening a handle to the service and querying its current state using the Windows API functions OpenServiceW and QueryServiceStatusEx.

Figure 21. VSS Coordinator COM access followed by VSS enumeration.

Analysis of the execution trace shows the malware instantiated the VSS Coordinator COM object (CLSID E579AB5F-1CC4-44B4-BED9-DE0991FF0623) and leveraged the IVssEnumObject interface (AE1C7110-2F60-11D3-8A39-00C04F72D8E3) to enumerate and delete Volume Shadow Copies, effectively removing system snapshots to hinder recovery.

This technique provides a stealthy way to remove shadow copies by avoiding spawning external utilities, such as vssadmin, which are noisy and commonly monitored by security tools.

Instead, the malware interacts directly with VSS through COM. This approach leverages legitimate system components and bypasses reliance on conventional API calls, making detection more difficult. Since many security solutions focus on monitoring process creation, standard Windows APIs, or syscalls, COM-based activity - identified only by CLSIDs and interface UUIDs that are not easily human-readable - can significantly reduce defender visibility.

Disable Services

Using a hardcoded list of hashes, the ransomware enumerates services on the system and computes a hash for each one using a custom hashing algorithm described above.

When a service’s hash matches an entry in the list, the ransomware queries the service status via QueryServiceStatusEx and, if the service is enabled, disables it by calling ChangeServiceConfigA with the SERVICE_DISABLED start type.

The following unified list of hashed service names were restored from the malware, and configurable via builder so the names may vary depending on the attacker’s intention:

The resolved names show a deliberate focus on backup infrastructure (Veeam, Commvault, Arcserve, YooBackup), Hyper‑V virtualization, and system recovery mechanisms — consistent with pre‑encryption sabotage observed in modern enterprise ransomware. Furthermore, it targets critical business database services (SQL), accounting software (QuickBooks) and security agents (Sophos, RTVscan), ensuring that the encryption process proceeds unhindered and maximizes the irreversibility of the damage.

It’s worth noting that not all hash values were successfully resolved. Due to the destructive nature of the hashing algorithm (specifically, the bitwise operations and modulo limits), mathematical reversal is impossible, so we used a brute-forcing approach via a lookup table built from known services targeted by modern ransomware families.

Conclusion

LockBit 5.0 demonstrates a dangerous maturation in ransomware tradecraft. By combining a custom loader, anti-debugging techniques, geo-checking, ETW patching, noiseless shadow copies deletion, and ADS concealment, the malware achieves a high level of stealth. Our analysis — which involved reconstructing the malware's custom hashing algorithm to map its capabilities — confirms a deliberate focus on crippling enterprise resilience, specifically targeting backup and virtualisation infrastructure and security agents.

While LockBit 5.0’s protection techniques defeat static and dynamic analysis, it cannot hide its behavior. The Cybereason Defense Platform detects the underlying malicious activity with high fidelity, regardless of how it is loaded or hidden, ensuring that defenders stay one step ahead of even the most evasive threats.

Yara Rule

How We Protect

The LevelBlue Platform detects LockBit 5.0 ransomware loader’s behavior with high confidence, enabling the attack to be stopped effectively in its early stages — process injection with floating (unbacked) executable.

Figure 22. Loader’s process tree — Cybereason detecting process injection.

Ransomware payload is successfully suspended by Cybereason platform upon files encryption:

Notable detection events include activity of stopping services (T1489) on the infected host:

MITRE ATT&CK Techniques

IOCs