The Evolution of Infostealers: Deep-Diving the Remus 64-bit Lumma Successor

In the rapidly shifting landscape of malware evolution, new variants often emerge from the ashes of decommissioned or compromised operations. We are currently witnessing this phenomenon with Remus, a sophisticated 64-bit infostealer that appears to be a direct architectural descendant of the notorious Lumma Stealer. While it maintains the core DNA of its predecessor, Remus introduces advanced evasion techniques, including EtherHiding-based Command and Control (C2) resolution and a highly refined bypass for Chromium’s Application-Bound Encryption (ABE).

The timeline of Remus suggests a strategic pivot. Initial activity was detected in early 2026, following a period of intense scrutiny where Lumma’s core operators were doxxed between August and October 2025. This suggests that Remus is either a deliberate rebrand or a splinter group of the original developers. This lineage is further confirmed by “Tenzor”—intermediate test builds compiled in September 2025—which serve as a technical bridge between legacy Lumma samples and the current Remus binaries.

Architectural Continuity: Inheriting the Lumma DNA

Remus does not reinvent the wheel; rather, it optimizes the existing Lumma toolkit. It retains the ability to exfiltrate high-value targets, including browser credentials, session cookies, cryptocurrency wallets, and clipboard contents. To hinder static analysis, the malware employs Mixed Boolean-Arithmetic (MBA) obfuscation, which can be found either inlined within the code or housed in standalone functions.

At a low level, the technical fingerprints are nearly identical. Both families utilize a specific string-obfuscation scheme where encrypted strings are reconstructed on the stack via mov sequences and subsequently decoded using per-string MBA loops, frequently padded with non-standard nop sequences. Furthermore, their anti-virtualization (Anti-VM) logic is synchronized, utilizing the cpuid leaf 0x40000000 to scan for hypervisor signatures (VMware, VirtualBox, KVM, and Xen) in a specific, repeatable order.

To minimize its footprint and evade EDR hooks, both families bypass standard Windows API calls. Instead, they perform hash-based enumeration of ntdll.dll exports to build custom runtime tables of syscall numbers, dispatching them through a centralized direct-syscall stub. Even the configuration management remains consistent: encrypted C2 blobs and nonces are embedded within the .rdata section and decrypted at runtime using the ChaCha20 stream cipher.

The Chromium Battleground: Bypassing Application-Bound Encryption

The most impressive technical overlap between Lumma and Remus is their method for defeating Chromium’s Application-Bound Encryption (ABE). This security feature is designed to prevent unauthorized processes from accessing sensitive browser data.

Remus navigates this by locating dpapi.dll and resolving CryptUnprotectMemory via export hashing. It then scans the target browser’s memory (e.g., chrome.dll) for a specific opcode pattern that identifies the os_crypt_async::Encryptor vtable. Once the vtable is located, the malware scans for specific object instances to extract the v20_master_key. By injecting a compact shellcode into the browser process, Remus can call CryptUnprotectMemory from within the browser’s own memory space, leveraging CRYPTPROTECTMEMORY_SAME_PROCESS semantics to successfully unwrap the key.

As a fail-safe, if direct injection fails, both families utilize a sophisticated fallback: they create a hidden desktop environment, spawn a browser instance within that isolated space, and attempt to escalate privileges via SYSTEM token impersonation to circumvent ABE restrictions.

Modernizing Evasion: EtherHiding and Advanced Sandbox Detection

While the core remains Lumma, Remus introduces a paradigm shift in infrastructure. Traditional “dead drop resolvers”—such as using Telegram or Steam profiles—are relatively easy for defenders to take down. Remus replaces this with EtherHiding.

In an EtherHiding workflow, the malware issues an eth_call JSON-RPC request to a hardcoded Ethereum smart contract via a public RPC endpoint. The C2 address is then extracted from the hex-encoded contract data. Because the blockchain is decentralized and immutable, this method provides a nearly indestructible communication channel that is extremely difficult for security researchers to “sinkhole.”

Furthermore, Remus has bolstered its local evasion capabilities:

• Module Scanning: It utilizes CRC32 checksums to scan loaded modules for analysis-related DLLs associated with tools like Avast Sandbox or Sandboxie.
• Honeypot Detection: It actively searches for specific “bait” files (e.g., dummy Outlook archives) commonly found in automated malware analysis sandboxes, terminating execution immediately if they are detected.

Defensive Summary

Remus represents a significant step forward in the infostealer arms race. For SOC analysts and incident responders, detecting this threat requires moving beyond simple file hashes. High-fidelity detection should focus on:

• Unusual JSON-RPC (eth_call) traffic directed toward public blockchain nodes.
• Anomalous direct syscall patterns that bypass the standard Windows API.
• The creation of hidden desktops or unexpected browser processes running under SYSTEM tokens.
• Abnormal DPAPI behavior within Chromium-based processes.