Remus is a newly observed 64-bit infostealer that closely tracks the Lumma Stealer codebase while adding EtherHiding-based C2 resolution and a refined Application‑Bound Encryption (ABE) bypass for Chromium browsers.
The first Remus activity dates back to early 2026, shortly after Lumma’s core operators were doxxed between August and October 2025, suggesting either a rebrand or a split by original Lumma developers.
Analysts also uncovered intermediate test builds dubbed “Tenzor,” compiled in September 2025, which bridge earlier Lumma samples and current Remus binaries and confirm code continuity.
Gen Threat Labs attributes Remus to the Lumma Stealer family based on overlapping code patterns, shared obfuscation, and a distinctive ABE bypass that was previously unique to Lumma.
In the wild, Remus now runs alongside active Lumma campaigns, positioning itself as a 64‑bit evolution rather than a full replacement.
Remus inherits Lumma’s core infostealing capabilities, targeting stored browser passwords, cookies, crypto wallets, and clipboard data.
The transformation is often further obscured by MBA (Mixed Boolean-Arithmetic) obfuscation and is either inlined or placed in a standalone function.
Under the hood, both families share a nearly identical string‑obfuscation scheme: encrypted strings are built on the stack via mov sequences and decoded with per‑string mixed Boolean‑arithmetic loops, often padded with atypical nop sequences that show up in both codebases.
Reverse engineering also reveals matching Anti‑VM logic based on cpuid leaf 0x40000000, checking for hypervisor signatures such as VMware, VirtualBox, KVM, and Xen in the same order and with similarly obfuscated constants.
Both Lumma and Remus resolve Windows APIs via hash‑based enumeration of ntdll.dll exports, building runtime tables of syscall numbers and dispatching them through a central direct‑syscall/sysenter stub.
In addition to identical heap and clipboard helper functions, both families avoid the usual C runtime startup and jump straight from the PE entry point into malware logic, emphasizing minimal dependencies and size.
Even their configuration layout is consistent: encrypted C2 blobs, keys, and nonces are embedded in .rdata and decrypted at runtime with ChaCha20.
This density of low‑level similarity, across architecture, obfuscation, and control‑flow style, underpins the assessment that Remus is a native 64‑bit branch of the Lumma lineage.
The most distinctive link between Lumma and Remus is their shared approach to bypassing Chromium’s Application‑Bound Encryption.
Within that context, it finds dpapi.dll, resolves CryptUnprotectMemory via export hashing, and then searches the browser DLL (for example, chrome.dll) for a specific opcode pattern that leads to the os_crypt_async::Encryptor vtable holding the protected key.
Once the vtable is located, Remus scans memory for object instances, extracts the v20_master_key at known offsets, copies it into a pre‑allocated buffer, and calls CryptUnprotectMemory from the injected shellcode to decrypt it in place.
Lumma implements the same idea with a slightly longer shellcode (around 62 bytes) and a different wildcarding scheme, but both rely on CRYPTPROTECTMEMORY_SAME_PROCESS semantics to ensure only the browser process can unwrap the key.
If injection fails or no browser instance is present, both families create a hidden desktop, spawn a browser there to avoid visible windows, and fall back on SYSTEM token impersonation as an alternate ABE bypass route.
To date, this very specific, memory‑resident ABE bypass has only been observed in Lumma and now Remus, making it a powerful attribution signal.
Where Remus diverges most clearly from classic Lumma is in its infrastructure and evasion layer. Older Lumma builds used “dead drop resolvers” on Steam profiles and Telegram channels, often storing ROT‑15‑obfuscated C2 URLs on otherwise legitimate platforms.
Rather than using the app_bound_encrypted_key from the browser’s Local State file through IElevator::Decrypt, Remus injects a compact shellcode (about 51 bytes) into the browser process to locate and decrypt the in‑memory v20_master_key directly.
Remus replaces that with EtherHiding: the malware issues an eth_call JSON‑RPC request against a hardcoded Ethereum smart contract through a public RPC endpoint, then decodes the C2 address from the hex‑encoded contract data.
Because smart‑contract state is decentralized and immutable, this blockchain‑backed dead drop is far more resistant to takedowns than a traditional hosted profile.
On the evasion side, Remus adds a CRC32‑based scan of loaded modules to detect sandbox or analysis DLLs linked to tools such as Avast Sandbox, Sandboxie, and Comodo.
It also checks for a tell‑tale honeypot PST file (for example a “honey@pot.com” Outlook archive) to identify automated analysis environments and terminates early if found.
Combined with inherited Anti‑VM checks, direct syscalls, and obfuscated control flow, these additions make Remus significantly harder to analyze and detect at scale.
For defenders, monitoring for EtherHiding‑style smart‑contract queries, direct syscall patterns, hidden desktop browser launches, and unusual Chromium DPAPI behavior can provide high‑value detection points against this emerging Lumma successor.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
Attackers abused compromised ConnectWise Cloud Backup credentials to access Microsoft 365 customer environments, prompting ConnectWise…
Anthropic says an internal Claude research model reconstructed how the National Security Agency generated seeds…
Two WordPress Core vulnerabilities can be chained to execute remote code without authentication, according to…
A newly disclosed OpenBSD kernel exploitation chain combines a shared memory accounting flaw with a…
GhostAction attackers have expanded their GitHub credential theft campaign with a second stage that disguises…
Indian authorities have warned that SideCopy hackers are targeting Indian organizations, including academic institutions, with…