Remus Infostealer Emerges as a 64-Bit Lumma Variant With New Browser Key Theft Tricks

Remus is a new 64-bit information stealer linked to the Lumma Stealer family, and it is designed to steal browser passwords, cookies, crypto wallets, and other sensitive data from infected Windows systems.

Gen Threat Labs says the malware appeared in early 2026 after major disruption around Lumma. Researchers found strong code, behavior, and technique overlaps between the two malware families, including a rare browser encryption bypass seen in Lumma before.

The most serious part of Remus is its approach to Chromium browser data. Instead of simply trying to read protected files from disk, it reaches into the browser process itself and extracts the master key needed to decrypt sensitive data.

Remus appears after Lumma’s disruption

Lumma Stealer had already become one of the most widely used infostealers in cybercrime. Microsoft and law enforcement partners disrupted its infrastructure in May 2025, taking action against thousands of domains tied to the malware operation.

Gen Threat Labs later found test builds labeled Tenzor, dated September 16, 2025. These builds looked like a bridge between the older Lumma codebase and what later became Remus.

The first Remus campaigns date back to February 2026. Researchers describe it as a 64-bit variant of Lumma rather than a simple copy, since it keeps Lumma’s core stealing behavior while adding new infrastructure and evasion methods.

Category	Remus behavior
Malware type	64-bit information stealer
Linked family	Lumma Stealer
First campaigns	February 2026
Early test builds	Tenzor builds dated September 16, 2025
Main targets	Browser passwords, cookies, crypto wallets, and stored credentials
Major new feature	EtherHiding-based command-and-control resolution

Why the Lumma connection matters

The link to Lumma makes Remus more important than a routine stealer variant. Gen Threat Labs found similar string obfuscation, anti-VM checks, direct syscall handling, indirect control flow tricks, and browser encryption bypass logic.

Lumma used a malware-as-a-service model and became popular because it could steal valuable data quickly. Stolen browser cookies and credentials can help attackers hijack accounts, bypass weak session controls, and sell access to other criminals.

Remus keeps that same focus. It does not need to invent a new playbook because Lumma’s model already worked. Instead, Remus modernizes the architecture and changes how it finds command servers and avoids analysis.

How Remus bypasses browser protections

Chrome introduced Application-Bound Encryption on Windows to make cookie theft harder. Google said the feature ties encrypted data to the application identity, so another program running as the same user should not simply decrypt protected browser data.

Remus works around this by injecting shellcode into a live Chromium browser process. From inside that process, it looks for the protected v20 master key in memory and uses the browser’s own context to decrypt it.

This matters because the technique avoids the simpler disk-based theft that browser makers tried to block. Remus can also launch a hidden browser instance if it cannot inject into an existing one, keeping the activity away from the user’s screen.

• It looks for Chromium browser processes.
• It searches browser memory for the protected master key.
• It injects compact shellcode into the browser process.
• It decrypts the key inside the browser’s own context.
• It uses the key to access sensitive browser data.

Remus adds a stealthier hidden browser method

Gen Threat Labs found that both Lumma and Remus can spawn a browser on a separate hidden desktop when needed. This prevents visible browser windows from appearing while the malware works in the background.

Lumma used fixed desktop names such as ChromiumDev or ChromeBuildTools. Remus changes this behavior by generating a random 16-character desktop name each time.

That small change makes detection harder. Security tools that hunt only for Lumma’s older desktop names may miss the newer Remus behavior unless they also detect the broader hidden desktop and browser injection pattern.

EtherHiding makes takedown harder

Remus also changes how it finds its command-and-control server. Lumma relied on dead drop resolvers hosted on platforms such as Steam and Telegram, where attackers could hide the current C2 address.

Remus replaces that with EtherHiding. It uses an Ethereum smart contract to retrieve the current C2 address at runtime, which makes the setup more resilient than a normal domain or platform-hosted profile.

Because blockchain data is decentralized, defenders cannot ask one platform operator to remove the dead drop. Attackers can use the smart contract as a durable pointer to their current infrastructure.

Feature	Lumma	Remus
Architecture	32-bit	64-bit
Dead drop method	Steam and Telegram	Ethereum smart contract
Browser key theft	Injection-based ABE bypass	Similar injection-based ABE bypass
Hidden desktop name	Hardcoded names	Random 16-character name
Anti-analysis	Anti-VM checks	Anti-VM checks plus added sandbox checks

Anti-analysis checks help it avoid sandboxes

Remus checks for signs that it runs inside a security lab, sandbox, or analysis environment. If it finds these signals, it can stop running before it reveals its full behavior.

One check looks for DLLs linked to analysis and sandbox tools. The malware walks the loaded module list, hashes module names, and compares the results against known blocked values.

It also uses anti-VM logic, including CPUID checks for hypervisor signs. These methods help the malware waste analysts’ time and reduce the chance that automated systems capture a complete execution trace.

Why this threat is dangerous

Remus targets data that criminals can use immediately. Stolen cookies may let attackers access accounts without needing the victim’s password again, while stolen browser passwords and wallet data can lead to financial theft.

For companies, the bigger risk comes from follow-on access. An employee’s stolen browser session can expose cloud apps, email, dashboards, source code systems, or admin portals if the organization lacks strong session and device controls.

The malware also shows how quickly infostealer developers adapt. Browser vendors raise the cost of cookie theft, then stealer authors shift to injection, hidden browser processes, blockchain-based infrastructure, and other techniques.

How users and companies can reduce risk

• Keep browsers updated, especially Chrome and Chromium-based browsers.
• Use endpoint protection that detects browser injection and suspicious PowerShell or process activity.
• Restrict local administrator rights on business devices.
• Turn on phishing-resistant multi-factor authentication where possible.
• Monitor for impossible travel, new device logins, and unusual session reuse.
• Rotate passwords and revoke sessions after any suspected infostealer infection.
• Block suspicious downloads and cracked software, which remain common stealer delivery paths.

FAQ