REMUS Is the First Commercial Infostealer That Pulls 1Password, LastPass, and Bitwarden Extension Data Out of IndexedDB—and Resolves Its C2 Through an Ethereum Smart Contract Nobody Can Take Down

Key Takeaways

• REMUS is a 64 bit infostealer that emerged in commercial form in February 2026 and is sold as a malware as a service offering on underground forums.
• Flare analysts tracked 128 posts about REMUS between February 12 and May 8, 2026 and identified four distinct development phases—usability, telemetry, persistence, and stabilization.
• The April release added explicit IndexedDB collection for the 1Password, LastPass, and Bitwarden browser extensions, plus collection of Discord and Telegram session tokens.
• REMUS resolves its command and control address through an Ethereum smart contract using EtherHiding—a JSON RPC call to a hardcoded contract returns the current C2 address—which makes the dead drop effectively impossible to take down through traditional abuse reporting.
• The Application Bound Encryption bypass is performed by injecting a shellcode stub into the browser process and calling CryptUnprotectMemory from inside the browser's address space—a technique previously only seen in Lumma.

What Is REMUS?

REMUS is a Windows credential stealer written as a 64 bit native binary. It originated as a fork of the Lumma family but has since diverged in feature set and tradecraft. Flare's research analysed 128 posts on Russian and English language underground forums between February 12 and May 8, 2026, tracking how the operator presented the product to potential customers and how the customer base reacted as the product matured.

The operator runs REMUS on a malware as a service model. Customers pay for access to a builder that produces a custom binary keyed to their campaign, an operator dashboard for reviewing exfiltrated data, and integration with a Telegram bot for live notifications when a victim machine checks in. Customer support is offered around the clock. The volume of usability complaints in the forum posts mirrors the operational maturity of a small SaaS company.

The Four Phase Evolution

Flare's research split the February to May window into four distinct development phases. The arc is recognisable from any product roadmap.

February—usability. Marketing emphasised setup speed, builder ergonomics, and round the clock support. The operator was trying to convince customers that REMUS worked out of the box and would not require them to read code.

March—telemetry. The operator added worker tracking, success statistics, and a dashboard for affiliates to see which campaigns were producing. The shift from "does this work" to "how well does this work" tracks the maturation of customers from curious to operational.

April—persistence. Session tokens, refresh tokens, IndexedDB scraping, and SOCKS5 based session restoration were all added in the April release. The product shifted from a one shot credential dump to a session continuity tool. This is the phase where 1Password, LastPass, and Bitwarden browser extensions became targets.

May—stabilisation. Bug fixes, telemetry refinements, and reliability improvements. The product is now in maintenance mode, with the operator confident enough to compete on quality rather than feature breadth.

How Does REMUS Read Password Managers?

Browser based password manager extensions—1Password, LastPass, and Bitwarden—store their working state inside the browser's IndexedDB database. The vault itself remains encrypted, but the extension's runtime state, cached metadata, session tokens, and recently used entries can sit in IndexedDB in forms that range from cleartext to lightly obfuscated.

REMUS walks the IndexedDB files associated with each extension's origin and collects everything it finds. The exact contents depend on the extension and on how the user has configured it. For a user who has unlocked their vault during the current browser session, the cached data is usually enough to identify which credentials are stored, which sites they belong to, and—in some configurations—the credentials themselves. For a user who has not unlocked the vault, REMUS still walks away with the list of stored entries, which is itself a road map for follow on phishing.

The same IndexedDB collection runs against Discord and Telegram, harvesting authentication tokens that keep those services logged in. Discord tokens are a high value item on credential markets because they unlock entire community accounts; Telegram tokens give similar reach over private messaging channels.

How Does REMUS Talk to Its Command and Control?

The C2 resolution layer is the most distinctive part of the design. Instead of phoning home to a hardcoded domain or IP, REMUS makes a JSON RPC eth_call to a public Ethereum node, querying a smart contract whose address is baked into the binary. The contract returns a hex encoded string. REMUS decodes that string into the current C2 address and connects to it for instructions and data exfiltration.

This pattern is called EtherHiding. Its operational advantage is the immutability of the Ethereum blockchain. There is no domain registrar to file an abuse complaint with. There is no host to seize. The smart contract is a piece of code that lives on every Ethereum node in the world, and the only way to change what it returns is for the attacker to update it—which they can do at will by sending a transaction—or for the entire Ethereum network to censor the contract, which would be a constitutional crisis for the chain itself.

The defensive trade off is similar to the one TANstack's attackers exploited with stolen OIDC tokens. The blockchain is a public ledger, so security researchers can monitor the contract's updates and predict where the next C2 will surface. But blocking the lookups at the network layer is hard because Ethereum RPC traffic looks like ordinary traffic to a public web service.

The Shift from Credentials to Sessions

The strategic message inside the REMUS timeline is the shift from harvesting passwords to harvesting authenticated sessions. The advantage to the attacker is straightforward. A stolen password still has to clear MFA, device verification, and risk based authentication when it is used. A stolen session—a cookie, a refresh token, an active OAuth bearer token—has already cleared all of those checks. Replay it from a similar geolocation and a similar user agent and the targeted service treats the attacker as the user.

The Storm infostealer demonstrated the same shift earlier this month by performing the decryption of stolen browser cookies on the operator's server instead of on the victim's machine. REMUS goes a step further by collecting the SOCKS5 proxy that lets the attacker replay the session from approximately the same geographic location, which dodges the IP based fraud checks that some risk engines apply.

The relevant Gmail observation is that a stolen Gmail session token gives the attacker access to every recovery flow for every other account the victim owns. Once REMUS has the session cookie, two factor authentication on the victim's other services protects against nothing—the codes will be delivered to a Gmail inbox the attacker now owns.

What Defenders Can Do

First, prefer offline password managers or hardware backed ones for the most sensitive vaults. The 1Password and Bitwarden desktop applications can be configured to keep the vault closed when the browser extension is not actively in use; pushing as much state as possible out of IndexedDB and back into the locked desktop app reduces what REMUS gets to read. KeePass, with no browser integration at all, is unreachable to this particular technique because there is no extension state to scrape.

Second, treat session tokens as if they were credentials. Force re authentication on sensitive operations, shorten refresh token lifetimes for administrative accounts, and configure your identity provider to bind sessions to a device fingerprint where possible. Phishing resistant authentication factors—FIDO2 hardware keys—do not stop session theft after the fact, but they do prevent the initial phishing that gets the infostealer onto the machine to begin with.

Third, instrument the host. REMUS's distinctive Ethereum lookup happens early in the infection chain. Outbound traffic from desktop processes to public Ethereum RPC endpoints—Infura, Alchemy, the various community nodes—is unusual enough that an EDR with network telemetry can flag it. Watch for child processes injected into Chrome, Edge, and Brave that make those lookups.

Fourth, decouple your email inbox from your identity recovery flow. If your Gmail is the recovery email for your bank, your password manager, and your work account, then the consequences of any session stealer reaching that inbox cascade across everything else. Tracking pixels in marketing email already report your reading behaviour to vendors; the same vector tells an attacker which inbox is worth the effort of phishing.

The Bigger Picture

REMUS is not the first session stealer. It is the first one with a product strategy that explicitly markets session theft as its differentiator. The fact that 1Password, LastPass, and Bitwarden are now named features in a malware service brochure—rather than incidental harvests—is the development to track. Password managers were the security industry's recommendation for the credential rotation problem. The current generation of stealers has read the same recommendation and built collection for it as a first class feature.

The implication is not that password managers have failed. It is that the threat model under which they were recommended has shifted. The original case for a password manager was that one strong master password protects everything, on the assumption that the underlying machine is trustworthy. With REMUS and its peers in the wild, the trustworthy machine assumption is now load bearing in a way it did not used to be. Defence has to move down the stack—to the integrity of the host the password manager runs on, and to the recovery flows that an inbox stealer can pivot through once it has the session.