A recent reverse engineering analysis of a Lockbit ransomware variant targeting Linux-based ESXi servers has uncovered several sophisticated evasion techniques and operational details.
The malware, first documented in 2022, employs the ptrace system call to detect debugging environments by attempting to attach to its parent process.
If this fails typically due to an existing tracer like gdb or strace the program exits immediately, thwarting dynamic analysis.
Analysts can bypass this by patching conditional jumps in a debugger or modifying the binary for unconditional execution.
Following this check, the malware deobfuscates strings using a simple rolling XOR routine with a fixed base value of 0x39 (57 in decimal), applied byte-by-byte until a null terminator.
This process reveals critical elements such as a help menu, ransom notes, bash commands for VM management, and extensive log messages, simplifying further disassembly.
By debugging through these routines and dumping deobfuscated data, researchers can rename string references in tools like IDA Pro, effectively mapping the binary’s functionality without extensive scripting.
The malware’s control flow centers on an argv parsing function that processes command-line arguments via a switch-case structure, enabling configurations like file size thresholds for encryption, logging modes, and target extensions.
Notably, it includes a built-in help menu detailing options for daemonization, free space wiping, and VM suspension, which inadvertently aids reverse engineers in understanding the code’s branching logic.
ESXi-Specific Operations
Logging is robust, with options to disable it, write to /tmp/locklog, or output to both file and stdout, formatted with timestamps, thread IDs, and message arguments.
According to the report, this verbosity exposes much of the malware’s behavior, such as file encryption notifications.
For persistence, the daemon option detaches the process using libc’s daemon function, creating /tmp/locker.pid with an exclusive lock to prevent multiple instances, ensuring solitary operation until completion.
The wiping feature erases free disk space by parsing df -h output to identify mount points, then spawning threads to write zero-filled blocks to temporary files based on filesystem stats from fstatvfs, complicating forensic recovery.
Targeting ESXi, the malware verifies tools like vm-support, vmdumper, and vim-cmd before proceeding; absence triggers an exit with the help menu displayed.
It enables SSH via vim-cmd hostsvc/enable_ssh but lacks additional backdoor configurations like rogue keys.
For encryption, it suspends running VMs using vmdumper commands, retrying up to nine times per world ID, unless the nostop flag is set, skipping active machines.
Folders are enumerated with vm-support –listvms, filtered against exclusions, and encrypted via threaded calls to glob and custom routines.
File Encryption
File encryption leverages statically linked libsodium for key generation and sealing. A 128-bit random key is created per file using randombytes_buf, then sealed in a crypto_box via crypto_box_seal with a hardcoded public key, appending it to the encrypted file.
This asymmetric approach secures symmetric keys, limiting memory dump utility to single files.
The core cipher, identified through manual graph matching despite failed automated FLIRT signatures, is an optimized AES variant using Rijndael S-box and four 1024-byte T-tables for efficient lookups, sourced from open implementations.
Post-encryption, ransom notes named !!!-Restore-My-Files-!!! are dropped, boasting speed and offering incentives for insider attacks via Tox.
This analysis highlights the malware’s blend of simplicity in VM interactions relying on bash commands executed via popen or system and complexity in crypto, underscoring evolving Linux threats beyond IoT-focused bots.
Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates!
Source link
