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

In the first part of our LockBit 5.0 series, where we analyzed 19 samples of the latest version of this cross-platform ransomware, we provided a comprehensive technical analysis of its ESXi variant. This report, which is the second part of a three-part series, focuses on our analysis of the Linux x64 variant of LockBit 5.0.

Part 2: Linux x64 Variant Analysis

Running “file” command against the sample, we can see that the executable output is the same as the ESXi variant - x86-64 architecture, and the binary is dynamically linked. The file does not contain ELF section headers.

Similarly to the ESXi sample, libraries used in the Linux variant are dynamically linked.

A quick view via ldd shows that it uses such libraries as libc and libpthread.

Compared to the ESXi variant, the sample contains no ransomware-related plaintext strings in the sample. Running “strings” against the samples shows only a small amount of information, such as libraries and function calls.

When analyzing the sample more in-depth, it could be observed that it contains big chunks of unreadable data at the end of the file:

Given that the sample references small parts of the data chunks, we can assume it is some kind of obfuscated data. The chunks are sent to a function which, after performing various manipulations, deobfuscates the data chunks.

The following is a code snippet that allows deobfuscating strings without the need to debug the code:

After deobfuscation, the data chunks become readable. The deobfuscated strings mostly correspond to the ones seen in the ESXi version:

Figure 1. An example of deobfuscated strings.

Among the decoded chunks, we have observed the internal name of the malware:

The internal naming of the malware (LINUX Locker v1.06) is similar to the one observed during our analysis of the ESXi variant. While the ESXi version seems higher (v1.07), it certainly lacks string obfuscation observed in this variant.

Figure 2. “LINUX Locker v1.06” and “LOCKBIT5.0” deobfuscated strings.

The overall execution flow of the malware is similar to the ESXii variant:

1. Anti-debug check
2. Self-delete
3. Initialize by parsing arguments
4. Fork itself, daemonize
5. Encrypt
6. Cleanup

Sample Features

The sample uses the same techniques of anti-debugging mentioned in the analysis of the ESXi variant.

Figure 3. ptrace call for self-trace.

For example, at the very beginning of the execution process, it performs a call to the ptrace function to trace itself. It is performed to see if the process is being debugged by other software. In Linux, a process can only be traced by one debugger at a time, so if the self-trace fails, the malware will not be executed.

Similarly to the ESXi sample, the malware has an embedded list of processes to check against to, as well as a blacklist of system folders it should avoid encryption to maintain OS stability, such as /etc, /EFI, /boot, /mbr and other system directories mentioned in the hypervisor variant analysis.

When executed on a Linux machine, we get the following results:

Figure 4. Ransomware execution.

The ransomware starts by deleting itself, then it iterates through the folders inside the /home directory, encrypting files, and adding random extensions after the original one. It does encrypt files in hidden directories, such as .config/, .local/ , .cache/ and others. By default, it will drop a ransom note to every affected folder.

Figure 5. Encrypted files and a ransom note.

The ransomware allows users to specify whether to write the ransom note to all the folders, root only, or not create a ransom message at all.

It will also alter the new file creation dialog, adding an option to drop a ransom note to the folder:

The ransom note contains the following text:

As we see inthe ransom note footer, the stated version - v1.08 is higher than the one observed in string analysis (1.06). This version looks more logical, as this variant is more hardened against analysis compared to ESXi version (v1.07), by implementing anti-static analysis techniques such as string obfuscation.

Overall, the Linux variant is very similar to the ESXi version. They share the same libraries, anti-debugging techniques, and blacklists. The main differences are on what they target in particular. While the ESXi version targets hypervision processes and files, the Linux version is more generic, targeting the /home folder by default. It should also be noted that the ESXi version will not run on Linux, due to hardcoded checks of the OS.

Linux Family Samples Analysis Review

The identified files represent a diverse set of architecture samples, suggesting the ransomware supports execution across multiple platforms and hardware architectures. The operational flow of these samples closely aligns with previously analyzed Linux and ESXi samples, which were reviewed in detail earlier.

Figure 6. List of spotted LockBit 5.0 samples.

The most meaningful differences between builds are not capability, but visibility. Some samples retain extensive plaintext operational strings (including usage-style messaging, log references, and path tokens), making capability enumeration straightforward during static triage. Especially x86_64, ARM64, PPC64LE, and s390x, which deliberately suppress this advantage by storing the most meaningful text as encoded records that are only reconstructed at runtime. This approach is not cryptographic protection but analyst friction. Combined with stripped binaries and the repeated absence of ELF section headers, it materially slows down malware analysis and reduces the effectiveness of bulk string-based hunting.

Figure 7. Anti-analysis related artifacts identified in one of the analyzed builds.

Once strings are recovered, the family’s anti-analysis posture becomes clearer and is notably consistent. Multiple builds reference /proc/self/status and the TracerPid field as an established anti-debugging technique alongside /proc/self/maps and scaffolding for process enumeration via /proc/<pid>/comm and /proc/<pid>/cmdline. This is the kind of pragmatic resistance often seen in commodity-to-industrial ransomware: sufficient to complicate interactive debugging and certain sandbox workflows, but lightweight enough to remain portable across environments.

The recovered filesystem vocabulary also points to a mature, stability-aware traversal model. Across architectures, the same categories of locations appear as “avoid” candidates or special-case handling: pseudo/volatile filesystems such as/proc, /sys, /run, /dev, runtime locations such as /var/run, and stability-critical directories such as /boot, /etc, and shared library paths (/lib, /lib32, /lib64), plus markers such as /selinux and package-manager footprints under apt/dpkg paths. Whether all tokens are implemented as hard exclusions or appear via configurable skip logic, the operational intent is consistent: avoid targets that could crash services, destabilize the OS, or prematurely interrupt encryption.

LockBit 5.0’s ecosystem is best observed as a single, portable ransomware codebase that has been wisely cross-compiled into a broad set of platform “skins” rather than a collection of unrelated forks. Across architectures (x86_64/i386, ARM variants, MIPS/MIPSEL, PPC64LE, s390x, and even a FreeBSD AMD64 build in this set), the same operational concepts repeatedly surface: a multi-threaded file-processing pipeline designed for high throughput, fast/percentage-based encryption modes that prioritize rapid impact, conservative traversal hygiene that avoids pseudo-filesystems and stability-critical areas, and a consistent reliance on /proc for anti-analysis and local introspection. The combination reflects practical ransomware engineering: maximize encryption velocity, reduce dwell time, and avoid self-inflicted host instability that would interrupt the run before impact is achieved.

Recommendations

• Keep ESXi and Linux Fully Patched and Supported:

  • Always run supported ESXi versions and apply security patches promptly.

• Enforce Multi-Factor Authentication (MFA):

  • Require MFA for all vCenter and ESXi administrative access

• Disable Unused Services:
  • Reduce the attack surface by disabling services that are not strictly required:
    • SSH (enable only temporarily when needed)
    • ESXi Shell
    • CIM services if unused
    • Unnecessary APIs or remote management interfaces

• Restrict Management Interface Exposure:

  • ESXi management interfaces should never be directly exposed to the internet.

• Apply Least-Privilege Access

• Maintain Offline and Immutable Backups

• Monitoring of commands:

vmware -v 2> /dev/null
ps | grep vmx | grep * | grep -v grep | awk * | sort -u

Remediations

Containment in such cases comes first. If you suspect an active ESXi/Linux locker event, treat it as an infrastructure incident, not a single-host infection. Immediately isolate affected systems from the network, revoke interactive access paths that could be used for lateral movement (VPN accounts, SSO sessions, SSH keys, API tokens), and preserve evidence before “cleanup.” On ESXi/vCenter, collect ESXi host support bundles and the vCenter/VCSA support bundle; export Tasks/Events and authentication logs, and preserve a forensic snapshot of VCSA, jump hosts, and any privileged admin workstations. On Linux, capture process trees, open files, network connections, and filesystem timelines (audit logs/syslog/journald), then lock down credentials since ransomware runs are often just the last visible stage of a larger compromise.

From a prevention standpoint, the biggest control is to harden and segment the management plane. ESXi management interfaces should be reachable only from dedicated admin networks (or a hardened jump host), with explicit allowlists at firewalls and host rules. Disable or strictly limit ESXi Shell/SSH, enforce least privilege via RBAC, and require MFA for admin access. Keep ESXi fully patched and maintain a disciplined vulnerability management cadence for the hypervisor stack and any remote management components. Segment clusters and storage networks so that a single compromised admin foothold cannot immediately reach every host and datastore.

On Linux servers, prioritize controls that prevent initial access and reduce blast radius: enforce SSH key-only auth (disable passwords), require MFA for privileged access where feasible, restrict sudoers to named admin groups, and remove unnecessary services exposed to the internet. Use host firewalls to deny inbound management ports by default, and constrain outbound connectivity for servers that do not need it. Make persistence harder: protect cron/systemd service creation, monitor new binaries executed from writable locations, and enforce application allowlisting where practical. Even when the ransomware payload is portable across architectures, the intrusion path is usually not closing weak access paths (stolen credentials, exposed admin panels, misconfigured VPN/RMM), which is often the highest ROI remediation.

Backups must be ransomware-resilient, not just present. For ESXi estates, assume that an attacker with host-level access can delete snapshots, tamper with backup agents, and target backup repositories. Use immutable storage (object lock / WORM / hardened Linux repositories), separate backup credentials from domain admin, and isolate backup management networks. Maintain at least one offline or logically air-gapped copy, and regularly test restores of full VMs and critical application stacks. Treat “snapshot” as a convenience, not a recovery strategy, andrecovery plans should be built around verified restores, not assumptions.

Tighten detection and validation around the behaviors that matter in Linux/ESXi attacks: monitor for unusual/proc inspection and process enumeration on Linux preceding bursty write/rename activity; watch ESXi for anomalous admin logins, role changes, host configuration edits, datastore-wide file modifications, and mass VM operations that deviate from baseline. The goal isn’t to catch a specific string or hash, but it’s to detect infrastructure-impacting behavior early, before encryption reaches shared storage and VM-backed production services.

Conclusion

The ESXi and Linux samples in this set reinforce that LockBit 5.0 is designed as a broad-coverage impact tool for corporate environments, not a niche Linux payload. The architecture spread and platform targeting indicate deliberate coverage of the systems that keep organizations running: virtualization hosts, server workloads, shared storage, application backends, and file-heavy infrastructure. In practical terms, these builds are positioned to disrupt core business operations by encrypting data and services that underpin the availability of VM-backed production systems on ESXi, shared files and configuration stores on Linux servers, and the surrounding ecosystem that supports authentication, monitoring, and operations. The result is maximum leverage: impact radiates quickly from infrastructure layers to dependent business processes.

At the same time, the samples show a mature engineering balance between speed and resilience. Encryption is clearly built for throughput multi-threaded execution, fast or partial encryption modes, and controlled execution paths, while the “anti-analysis” layer is comparably lightweight and operationally pragmatic. Rather than sacrificing performance for stealth, these builds use string protection and analyst-friction choices primarily to complicate first-pass triage and to avoid brittle behavior across diverse environments. The net result is a LockBit 5.0 ESXi/Linux locker with operator-controlled execution modes, VM-aware logic, fast-pass encryption, logging, and optional self-deletion, and lightweight anti-analysis checks engineered to run reliably across a wide range of architectures while making first-pass analysis and rapid attribution harder.

In the third and final part of this series, we’ll provide a technical deep dive of LockBit 5.0’s Windows variant.

MITRE ATT&CK Mapping

IOCs