{
	"id": "f65446b9-7424-4c4c-88a7-e9f51fe082cf",
	"created_at": "2026-04-06T00:22:13.051307Z",
	"updated_at": "2026-04-10T03:26:36.600682Z",
	"deleted_at": null,
	"sha1_hash": "58d53ad830b4cb9a68c285ced8dc8cb62e4ad599",
	"title": "19 Shades of LockBit5.0, Inside the Latest Cross-Platform Ransomware’s Newest Leaked Samples: Part 1",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1454683,
	"plain_text": "19 Shades of LockBit5.0, Inside the Latest Cross-Platform\r\nRansomware’s Newest Leaked Samples: Part 1\r\nBy Mark Tsipershtein, Evgeny Ananin, Nikita Kazymirskyi\r\nPublished: 2026-01-30 · Archived: 2026-04-05 21:33:56 UTC\r\nJanuary 30, 2026 8 Minute Read by Mark Tsipershtein, Evgeny Ananin, Nikita Kazymirskyi\r\nThis three-part blog series presents an analysis of 19 samples of a cross-platform LockBit 5.0 ransomware payload\r\naffecting Windows, Linux (LINUX Locker v1.06/v1.08), and ESXi (LINUX ESXi Locker v1.07) environments,\r\nhighlighting how the ransomware operates, encrypts data, and interacts with targeted systems.\r\nPlease check out Part 2 and Part 3 in the series.\r\nBy reverse engineering multiple samples, we identified shared components across platforms as well as operating\r\nsystem–specific behaviors that allow the malware to function efficiently in different environments. \r\nAt the core of the threat is the use of a fast encryption method (ChaCha20) to encrypt files and data, replacing the\r\nAES-based encryption used in previous versions. The malware is designed for performance and scalability,\r\nenabling it to process large volumes of data quickly while avoiding reliance on standard cryptographic libraries,\r\nwhich can make detection more difficult.\r\nThis report examines how the malware accesses files, manages system processes, and executes tasks in parallel,\r\ngiving defenders insight into its operational workflow. While the underlying encryption approach is consistent, the\r\ntechniques used to interact with Windows and Linux systems differ, reflecting deliberate adaptation to each\r\nplatform.\r\nAt the time of writing, the sample had a detection score of 1/65 on VirusTotal.\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 1 of 12\n\nFigure 1. VirusTotal detection results for the LockBit 5.0 sample we analyzed as of writing\r\nThreat Landscape\r\nLockBit is one of the clearest examples of ransomware evolving into an industrial business model. It operates as\r\nransomware-as-a-service (RaaS): a core team maintains the malware, negotiation/payment infrastructure, and leak\r\nsite, while affiliates carry out intrusions and deployments for a revenue share. That division of labor is what lets\r\nthe operation scale, and why LockBit has repeatedly been described in public reporting as a high-volume, high-impact ecosystem.\r\nFigure 2. Discussion of development plans and a shared fund on a dark web forum\r\nMore recently, LockBit’s posture points to a potentially more serious market shift: consolidation. Reporting in\r\nOctober 2025 described LockBit aligning with other ransomware brands (including DragonForce and Qilin) in a\r\ncartel-style approach that emphasizes shared resources and invites additional crews to join. If that umbrella model\r\ngains traction, defenders may face not just a single prolific RaaS brand, but an aggregation layer that pools\r\naffiliates, infrastructure, and playbooks, raising both the baseline capability and the potential scale of ransomware\r\noperations.\r\nIn this report, we analyze the latest observed samples of the LockBit 5.0 ransomware family, comparing builds\r\nacross platforms and architectures to understand what stays consistent, what changes, and what it reveals about the\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 2 of 12\n\ngroup’s current development direction and operational tradecraft.\r\nPart1: ESXi Variant Technical Analysis\r\nOverview\r\nVMware ESXi is a widely adopted bare-metal hypervisor used to host and manage large numbers of virtual\r\nmachines in enterprise environments. By consolidating critical workloads, such as databases, application servers,\r\nand domain controllers, into a single physical host, ESXi enables efficiency and scalability, but it also creates a\r\nhigh-value target. A successful compromise of an ESXi host can result in the simultaneous disruption of dozens or\r\neven hundreds of systems.\r\nIn recent years, ransomware operators have increasingly shifted their focus from individual endpoints to\r\nhypervisors like ESXi. Rather than encrypting files within a single operating system, ESXi-targeting ransomware\r\nattacks the underlying virtual disk files and configuration data that power entire virtual infrastructures. This\r\napproach maximizes operational impact while reducing the attacker’s effort.\r\nFigure 3. LockBit Builder Linux version view\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 3 of 12\n\nFigure 4. LockBit Builder ESXi version view\r\nLockBit 5.0 ESXi Version\r\nFigure 4 illustrates the execution flow of the LockBit 5.0 ESXi ransomware based on static analysis. The malware\r\nfirst validates that it is running in a VMware ESXi environment, then enumerates and forcibly shuts down active\r\nvirtual machines to release file locks. It proceeds with a multi-threaded encryption routine using a fast pass\r\nfollowed by a full pass on targeted VM files. Instead of dropping a traditional ransom note, victim notification is\r\nhandled via console output or log files, reflecting the headless nature of ESXi systems.\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 4 of 12\n\nFigure 5. LockBit ESXi execution flow\r\nThis is a 64-bit Linux ELF executable compiled for the x86-64 architecture. The binary is dynamically linked. The\r\nfile lacks ELF section headers, a common anti-analysis technique used by malware.\r\nfile lockbit_AMD64\r\nlockbit_AMD64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter\r\n/lib64/ld-linux-x86-64.so.2, no section header\r\nThis ldd command output shows the shared libraries required by the LockBit ESXi binary at runtime.\r\nlibpthread.so.0 indicates the use of threads, supporting multi-threaded execution consistent with parallel\r\nencryption activity.\r\nldd lockbit_AMD64\r\nlinux-vdso.so.1 (0x00007f341514f000)\r\nlibpthread.so.0 =\u003e /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f341512b000)\r\nlibc.so.6 =\u003e /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3414f35000)\r\n/lib64/ld-linux-x86-64.so.2 (0x00007f3415151000)\r\nA Binwalk scan of the LockBit ESXi sample highlights embedded file paths within the binary.\r\nbinwalk lockbit_AMD64\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 5 of 12\n\nDECIMAL HEXADECIMAL DESCRIPTION\r\n--------------------------------------------------------------------\r\n0 0x0 ELF, 64-bit LSB executable, AMD x86-64, version 1 (SYSV)\r\n362953 0x589C9 Unix path: /var/log/encrypt.log\r\n367904 0x59D20 Unix path: /var/tmp/.guestfs-0/appliance.d/root\r\nThe path /var/log/encrypt.log suggests the malware may record encryption activity or status messages to a log file\r\nduring execution.\r\nThe second path, /var/tmp/.guestfs-0/appliance.d/root, appears to reference a temporary directory structure\r\nassociated with virtual appliance. Its presence indicates the malware may interact with temporary VM-related files\r\nAnalysis of embedded strings within the sample provides valuable insight into the ransomware’s functionality,\r\nexecution flow, and intended interaction with the ESXi environment.\r\nEmbedded versioning within the binary:\r\nLINUX Locker v1.07\r\nLOCKBIT5.0\r\nThe extracted strings clearly show that this ransomware is specifically designed to target VMware ESXi\r\nenvironments. References to /vmfs and /vmfs/volumes/ indicate an intent to access VMFS datastores where virtual\r\nmachine disk files reside, while embedded vim-cmd commands such as vmsvc/getallvms, vmsvc/power.off, and\r\nvmsvc/power.getstate demonstrate built-in functionality to enumerate, check the status of, and forcibly shut down\r\nvirtual machines before encryption. Additional environment-validation strings like ESXi 4, ESXi x64, and\r\nvmware -v suggest the malware verifies it is executing on a legitimate ESXi host, helping avoid accidental\r\ndeployment on non-target systems or analysis environments.\r\nStatus messages such as “[OK] VM %s (ID: %d) powered off.” indicate that the ransomware tracks and confirms\r\nsuccessful shutdown of individual virtual machines.\r\n# ESXi Specific indicators:\r\n/vmfs\r\n/vmfs/volumes/\r\n/bin/vim-cmd vmsvc/getallvms - enumeration\r\n/bin/vim-cmd vmsvc/power.off %d - poweroff\r\n/bin/vim-cmd vmsvc/power.getstate %d\r\nESXi 4\r\nESXi x64\r\nvmware -v\r\nMeanwhile, “[INFO] VM %s (ID: %d) in bypass list, skipping” suggests the presence of an internal exclusion list\r\nthat prevents certain VMs from being targeted. The command fragment ps | grep vmx | grep \"%s\" further supports\r\nthis workflow, showing that the malware searches running processes for VMware VMX instances associated with\r\nspecific virtual machines.\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 6 of 12\n\nVM Logic:\r\n[OK] VM %s (ID: %d) powered off.\r\n[INFO] VM %s (ID: %d) in bypass list, skipping\r\nps | grep vmx | grep \"%s\"\r\nOptions such as -f (fast mode), -d (target specific directories), -l (enable logging), and -b (background execution)\r\nprovide operational flexibility, while -m (note storage mode) and -k (disable self-destruction) indicate adjustable\r\npost-encryption behaviors.\r\nAdditional flags directly influence the encryption process: -r controls the percentage of each file to encrypt, -w\r\nenables wiping of free disk space, -t sets a delayed start, -o disables automatic VM termination, and -n allows\r\nspecific virtual machines to be excluded by ID. Supporting status messages such as “Fast mode enabled (1%\r\nencryption)” and “Fast pass completed. Starting full encryption pass”, along with the marker .vmdk.fastpass,\r\nconfirm a two-stage encryption strategy in which a rapid partial pass is followed by more thorough encryption.\r\nParameters:\r\n-f Fast mode (1% encryption)\r\n-d Specific directories to encrypt\r\n-l Enable logging\r\n-b Background mode\r\n-m Note storage mode (0,1,2)\r\n-k Do not self-destruct\r\nEncryption:\r\n-r Encryption percentage (10–90)\r\n-w Wipe free disk space\r\n-t Timeout before starting\r\n-o Don't try to automatically kill VMs\r\n-n Skip VMs by ID\r\nFast mode enabled (1% encryption)\r\nFast pass completed. Starting full encryption pass\r\n.vmdk.fastpass\r\nThe list of targeted file extensions clearly shows that the ransomware is engineered to disrupt virtual machine\r\ninfrastructure at the hypervisor level. Files such as .vmdk (virtual disk files) and .vmx (VM configuration files)\r\nare essential for virtual machine operation, while supporting files like vswp (swap files), vmem (memory\r\nsnapshots), and vmsn (snapshot state files) are also included to ensure full impact. Additional metadata and state\r\nfiles: vmsd, vmtx, vmss, vmxf, and nvram, further indicate an intent to corrupt both runtime and configuration\r\ndata.\r\n# Targeted Files:\r\n.vmdk\r\n.vmx\r\nvswp\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 7 of 12\n\nvmem\r\nvmsn\r\nvmsd\r\nvmtx\r\nvmss\r\nvmxf\r\nnvram\r\nThe reference to /var/log/encrypt.log along with the message “[INFO] Logging enabled” suggests the malware can\r\nrecord its activity to a local log file, likely to provide operators with execution feedback in ESXi’s command-line\r\ndriven environment. Additionally, messages such as “[INFO] Binary removed successfully.” and “[ERROR]\r\nFailed to remove binary.” reveal a built-in self-deletion routine intended to remove the executable after\r\ndeployment.\r\nLogging:\r\n/var/log/encrypt.log\r\n[INFO] Logging enabled\r\nSelf delete:\r\n[INFO] Binary removed successfully.\r\n[ERROR] Failed to remove binary.\r\nReferences to /proc/self/maps and /proc/self/status, along with the field TracerPid:, indicate that the malware\r\ninspects its own process status to determine whether it is being debugged or traced. Mentions of tools such as\r\nvalgrind, frida, strace, and ltrace show that it actively looks for common dynamic analysis and instrumentation\r\nframeworks. Additionally, the presence of asan, tsan, msan, and ubsan, components of compilers used in\r\ndebugging and research environments, suggests further checks designed to avoid execution under memory\r\nanalysis.\r\nAnti Analysis and Anti Sandbox:\r\n/proc/self/maps\r\nTracerPid:\r\n/proc/self/status\r\nvalgrind\r\nfrida\r\nstrace\r\nltrace\r\nasan\r\ntsan\r\nmsan\r\nubsan\r\nDirectories such as /proc, /dev, and /sys contain virtual- and device-related files essential for kernel and hardware\r\ninteraction, while /bootbank and /altbootbank store ESXi boot images and recovery partitions. Core system\r\nlocations like /etc, /lib, and /bin are also excluded, preventing corruption of configuration files and essential\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 8 of 12\n\nbinaries. By excluding these paths, the malware ensures the host remains bootable and reachable, allowing victims\r\nto access the system and potentially pay the ransom.\r\nExclutions (avoid breaking the hypervisor):\r\n/proc\r\n/dev\r\n/sys\r\n/bootbank\r\n/altbootbank\r\n/etc\r\n/lib\r\n/bin\r\nString analysis revealed extensive ESXi-specific functionality within the sample, including native interaction with\r\nVMware management utilities (vim-cmd), VM enumeration and shutdown logic, and targeted encryption of VM\r\ndisk and configuration artifacts. The binary exposes a comprehensive command-line interface allowing operators\r\nto control encryption scope, percentage, execution mode, logging behavior, and VM exclusions, consistent with\r\nLockBit’s affiliate-driven ransomware-as-a-service model. Additional features include fast-pass partial encryption,\r\noptional free-space wiping, self-deletion, and multiple anti-analysis checks targeting debugging and\r\ninstrumentation frameworks.\r\nControl Flow And Core Routines\r\nTo make sure the ransomware is running on the ESXi host, it first performs an OS check via execution the\r\nfollowing command:\r\nThe command vmware -v 2\u003e /dev/null is used to quietly check whether the system is running VMware by\r\nquerying the version information while suppressing any error messages, allowing the malware to detect an ESXi\r\nenvironment without producing visible output.\r\nThe command ps | grep vmx | grep \"%s\" | grep -v grep | awk '{print $2}' | sort -u is used to locate running\r\nVMware virtual machine processes that match a specific identifier, extract their process IDs, and produce a unique\r\nlist, likely so the malware can terminate active VMs before encryption.\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 9 of 12\n\nVirtual machine shutdown routine, where the malware checks a VM’s power state and, if still running, repeatedly\r\nissues a vim-cmd vmsvc/power.off command while verifying the result, confirming an automated loop designed\r\nto ensure VMs are fully powered off before encryption begins.\r\nCommand-line options such as fast encryption mode, background execution, quiet mode, note storage behavior,\r\nself-destruction control, free space wiping, and custom encryption percentage, indicating a highly configurable\r\nexecution flow.\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 10 of 12\n\nThe ransomware maintains real-time operational metrics, likely to provide operators with progress visibility and to\r\nverify that the encryption process completed successfully across the targeted environment.\r\nEncryption\r\nChaCha20 stream cipher implementation:\r\nHex Values Decode to ASCII\r\nReordered in memory (little-endian), this value spells “expand 32-byte k”, which is the ChaCha20 constant string\r\nthat is used to initialize the state.\r\nESXi I386 Variant Analysis\r\nThe analyzed sample is a 32-bit Linux ELF (i386) associated with VMware ESXi targeting and has been observed\r\nlabeled as “LINUX Locker v1.06”, that may indicate an unchanged build from a prior release or a version counter\r\noversight by the operator. While it can execute on a generic Linux host that provides the required 32-bit runtime or\r\nloader, its orchestration is clearly optimized for ESXi: the operational flow is equivalent to that observed in\r\nprevious x64 ESXi sample. It assumes datastore discovery and traversal under /vmfs/volumes/… and integrates\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 11 of 12\n\nVMware management tooling (e.g., vim-cmd) for VM enumeration and power-state handling, meaning ESXi-dependent stages may fail or be bypassed on non-ESXi Linux unless paths are supplied manually.\r\nThe sample of decompiled code illustrating Poly1305 operations\r\nFrom an analysis perspective, the binary is stripped and notably omits the section header table, reducing the\r\neffectiveness of common automated triage and section-driven reversing workflows. The implementation also\r\nindicates concurrent processing via threading and TLS state, and it encodes auxiliary strings and operational\r\nparameters behind a runtime string obfuscation layer where high-value text (paths, command templates, and\r\nmessages) is decoded on demand using a rotate-based transform. Functionally, the codebase includes a modern\r\ncryptographic stack ChaCha-family present.\r\nIn the next parts of this series, we will cover the Linux and Windows variants.\r\nSource: https://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nhttps://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.levelblue.com/blogs/spiderlabs-blog/19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1"
	],
	"report_names": [
		"19-shades-of-lockbit5.0-inside-the-latest-cross-platform-ransomware-part-1"
	],
	"threat_actors": [
		{
			"id": "6608b798-f92b-42af-a93f-d72800eeb3a3",
			"created_at": "2023-11-30T02:00:07.292Z",
			"updated_at": "2026-04-10T02:00:03.482199Z",
			"deleted_at": null,
			"main_name": "DragonForce",
			"aliases": [],
			"source_name": "MISPGALAXY:DragonForce",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "843f4240-33a7-4de4-8dcf-4ff9f9a8c758",
			"created_at": "2025-07-24T02:05:00.538379Z",
			"updated_at": "2026-04-10T02:00:03.657424Z",
			"deleted_at": null,
			"main_name": "GOLD FLAME",
			"aliases": [
				"DragonForce"
			],
			"source_name": "Secureworks:GOLD FLAME",
			"tools": [
				"ADFind",
				"AnyDesk",
				"Cobalt Strike",
				"FileSeek",
				"Mimikatz",
				"SoftPerfect Network Scanner",
				"SystemBC",
				"socks.exe"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434933,
	"ts_updated_at": 1775791596,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/58d53ad830b4cb9a68c285ced8dc8cb62e4ad599.pdf",
		"text": "https://archive.orkl.eu/58d53ad830b4cb9a68c285ced8dc8cb62e4ad599.txt",
		"img": "https://archive.orkl.eu/58d53ad830b4cb9a68c285ced8dc8cb62e4ad599.jpg"
	}
}