Remus Infostealer Debuts With Stealthy New Credential-Theft Tactics

Hackers are rolling out a new 64‑bit infostealer dubbed Remus. The code strongly suggests it is a direct successor to the notorious Lumma Stealer, arriving just months after law‑enforcement disruption and public doxxing of Lumma’s core operators in 2025.

Remus is a 64‑bit information stealer that mirrors Lumma’s core playbook: harvesting browser passwords, cookies, autofill data, cryptocurrency wallets, and other credentials for resale or follow‑on attacks.

Unlike Lumma’s original 32‑bit builds, Remus ships as a native x64 payload, improving compatibility with modern Windows environments but making some legacy analysis workflows less effective.

Gen Threat Labs first observed Remus campaigns in early February 2026, shortly after prototype “Tenzor” test builds appeared in September 2025 with embedded “testbuild” markers and internal “# TENZOR LOG” / “# REMUS LOG” strings.

Strong code overlap with Lumma

Reverse engineering shows Remus and Lumma share highly specific implementation details that are unlikely to be coincidental.

Both families use the same stack‑based string encryption and MBA‑style obfuscation, including unusual multi‑byte nop padding before decryption loops that do not match typical compiler output.

Analysts also found more than a hundred identical or semantically equivalent decrypted strings across Lumma, the Tenzor test builds, and Remus, with Tenzor acting as a bridge that preserves legacy Lumma strings while introducing Remus‑specific artifacts.

One of the most compelling links is an identical Steam “dead drop” profile URL, recovered as an encrypted string in Tenzor samples and matched to multiple historical Lumma binaries.

Remus also inherits Lumma’s approach to direct syscalls: at runtime, it walks ntdll exports, builds a hash‑to‑syscall‑number table, and routes all sensitive operations through a central syscall dispatcher instead of the Windows API layer.

Shared heap wrappers, clipboard‑stealing routines, section layout, and ChaCha20‑encrypted C2 blobs in .rdata further reinforce a common codebase.

The clearest fingerprint tying Remus to Lumma is a rare Application‑Bound Encryption (ABE) bypass used to extract Chromium’s v20 master key.

Rather than calling the documented decryption interface, both families inject a compact shellcode stub into the browser process, locate the in‑memory ABE‑protected key, and call CryptUnprotectMemory with the CRYPTPROTECTMEMORY_SAME_PROCESS flag from inside the browser context.

To find the right structure, Remus walks the browser’s module list, resolves CryptUnprotectMemory inside dpapi.dll via hashed exports, and scans the browser DLL (for example, chrome.dll) for a specific LEA‑based opcode pattern that leads to the os_crypt_async::Encryptor vtable where the protected key resides.

Once the vtable address is derived, Remus enumerates readable memory regions with NtQueryVirtualMemory and NtReadVirtualMemory until it finds object instances, then copies the protected key into an allocated buffer and decrypts it via the injected shellcode.

Both stealers fall back to SYSTEM token impersonation as an alternative ABE bypass, but this injection‑based technique remains unique to Lumma and now Remus in public reporting.

New evasion and EtherHiding C2

Where Remus innovates is infrastructure and evasion. Earlier Lumma variants resolved C2 infrastructure through Steam profiles and Telegram channels acting as “dead drop” resolvers, with C2 URLs obfuscated via simple schemes such as ROT‑15.

Lumma implements the same idea with near‑identical logic but uses a different wildcarding scheme (a characteristic “B9%????4rnO/@NQe?Nx*” pattern) and a slightly larger shellcode; that same wildcard string also appears in Tenzor builds.

Remus also tightens anti‑analysis logic. Early in execution, it walks the PEB’s module list and computes a custom CRC32 hash for each DLL name, immediately exiting if any hash matches a small, curated set of sandbox and security‑tool modules (for example Sandboxie and Comodo virtualization DLLs).

Remus replaces these with EtherHiding: it sends eth_call JSON‑RPC requests to a hardcoded Ethereum smart contract via a public RPC endpoint, then parses a hex‑encoded C2 address from the contract response at runtime.

Because smart‑contract data is decentralized and immutable, defenders cannot simply file abuse reports to take down the dead drop, significantly increasing C2 resilience.

It then checks for a specific “[email protected]” Outlook archive inside the user’s Documents\Outlook Files directory as an additional sandbox indicator.

These checks complement existing Lumma‑style CPUID‑based hypervisor detection, where both families query the 0x40000000 leaf and compare ECX against obfuscated strings for KVM, QEMU/TCG, VMware, VirtualBox, and Xen.

For defenders, Remus looks less like a brand‑new stealer and more like Lumma’s 64‑bit evolution, rebuilt with smarter C2 resolution and broader anti‑analysis coverage.

Practical hunting opportunities include detecting unusual eth_call traffic to public Ethereum RPC endpoints, hidden‑desktop browser processes spawned with suspicious startup parameters, and repeated CryptUnprotectMemory usage from non‑browser processes.

Given Lumma’s historic impact and the clear lineage, organizations should treat Remus as a high‑priority infostealer threat and update detections, sandboxes, and EDR rulesets to account for its EtherHiding‑driven infrastructure and ABE bypass behavior.