Skip to content
Chimera readability score 70 out of 100, Academic reading level.

The underground marketplace rarely stays quiet for long. A new information-stealing malware dubbed Remus Stealer has surfaced in the cybercrime underground, exhibiting significant similarities to the notorious Lumma malware family across its administration panel, stolen log files, and core code structure.
Despite parallels in its code and functionality, threat actors are eagerly buying into the platform. In addition to its familiar features, it provides attackers with a distinct, modern command and control (C2) and networking infrastructure designed to slip past current security perimeters.
What We Know About Remus
Flashpoint first observed Remus appearing for sale within illicit communities in March 2026. The malware listing offers similar functionality to other popular Malware-as-a-Service (MaaS) offerings, including Google OAuth cookie restoration and Telegram channel integration for logs.
Much like the Lumma malware family, the Remus subscription service operates on a three-tiered access model:
- Basic: US$250
- Pro: US$500
- Enterprise: US$1,000
At this time, Remus has no additional channels or automated bots associated with its sale or distribution. Despite undeniable similarities to Lumma, its developer claims to not be a rebrand of the Lumma project.
Since March 2026, Remus has continued its operations mostly unhindered by negative associations associated with Lumma—particularly the doxxing of its panel in August 2025.
Similarities to Lumma
Similarities can be observed in the Remus and Lumma panels in both aesthetics and functionality. Both panels use similar assets for tab icons and have embedded advertisements for other illicit services such as packers and log clouds. Harvested logs also share extremely similar directory structures in log files, including unique identifiers.
Code-Level Overlaps
Remus is a 64-bit compiled binary, and Lumma was a 32-bit binary. However, major similarities between the code bases of both malware can be observed.
Upon execution of an unpacked sample, both Remus and Lumma will send warning messages to the user that the build is unpacked. This was a unique phenomenon first established by Lumma several years ago. In both Remus and Lumma samples, the pack check and window message are performed before the main functionality of the malware.
In both Remus and Lumma, a function is used first to check if the sample is packed, and a second function is used to send the window error message.
Remus uses similar string obfuscation methods to Lumma, in which each string has been uniquely encoded and then decoded during runtime. Deobfuscation occurs by looping byte by byte through encoded blobs. Each encoded string is obfuscated by a unique pattern. This can be seen in the code samples below:
Of note, both samples have at least one NOP instruction between the encoded blob being moved onto the stack and the deobfuscation loop.
Another unique feature of Lumma is the presence of a plaintext identifier string used to link customers to specific build generations. In Lumma, this string was referred to as the LID (Lumma ID), and this ID method appears in Remus as well as a “tag.”
Like the Lumma LID string, the Remus tag could be leveraged to attribute variant builds and campaigns to single threat actors or groups.
Additionally, both Remus and Lumma exhibit similar control flow obfuscation by replacing direct jumps with indirect jumps read from offsets that have been moved onto the stack, jumps computed from a jump table, and jumps resolved by a pointer.
Differentiators of Remus
Although Remus bears remarkable similarities to Lumma, its main differences lie in its C2 beaconing.
Before performing main stealer functionality, Remus will beacon out to its C2 infrastructure. It will attempt to resolve several domain:port combinations via POST requests, and attempt a final connection to find the C2 server using EtherHiding. If it is unable to connect, the malware will terminate.
After a connection is established, the stealer sends a POST request to the C2 in order to receive an access token. Once received and decoded, this access token is used to receive encrypted config data used by Remus to target assets on the victim system. Data collected for logs is then exfiltrated as encrypted POST data.
Protect Against Infostealers Using Flashpoint
Remus stealer represents a sophisticated continuation of the MaaS infostealer model left behind by Lumma’s collapse. While the developer asserts independence, the overwhelming code overlaps, matching obfuscation techniques, and administrative panels indicate that Remus is either heavily inspired by, or derived from the Lumma codebase. These traits have allowed it to thrive, providing threat actors with a familiar, robust alternative that sidesteps the reputational baggage and law enforcement scrutiny of its predecessors.
Flashpoint continuously tracks the latest developments in illicit communities, hard-to-reach adversary spaces, and malware repositories to identify emerging threats. Request a demo to learn how Flashpoint’s primary source collections and analyst insights empowers your security teams.

Sentinel — Human

Confidence

This article reads like expert threat intelligence reporting, relying on dense, specific details and comparative analysis typical of human security analysts, though some elements suggest potential LLM assistance in structuring the argument.

Signals Detected
low severity: Variable sentence length and specific technical phrasing mixed with smoother narrative transitions.
low severity: Maintains a consistent, investigative tone; the structure flows logically from observation to comparison to conclusion.
low severity: Specific technical details (LID, NOP instructions, C2 beaconing steps) are woven into the comparative narrative rather than being presented in separate data points, suggesting a unified human-driven hypothesis.
medium severity: The attribution of specific code-level overlaps and functional similarities to established malware families requires specialized, deep knowledge often found in expert reporting.
Human Indicators
The text incorporates highly specific, technically dense details (e.g., 64-bit vs 32-bit binaries, NOP instruction usage, specific C2 methods) that suggest direct engagement with source material or deep technical expertise.
The concluding paragraph shifts from forensic analysis directly into a promotional call to action for 'Flashpoint,' a common pattern in human-written journalistic reports.