VendorResearch

Remus Stealer: A New, Not-So-New Infostealer


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.

Remus Stealer panel (Source: Flashpoint Collections)

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:

Remus inline string deobfuscation (Source: Flashpoint)
Lumma inline string deobfuscation. (Source: Flashpoint)

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.”

Lumma ID (Source: Flashpoint)
Remus tag (Source: Flashpoint)

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.

Network traffic from Remus sample (Source: Flashpoint)

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.



Source link