Remus Stealer Markets Persistent Gmail Access: Hudson Rock Investigates
Hudson Rock questioned the Remus developer and a person who vouched for its new mailbox feature. Their accounts suggest access established through an infected device. The stronger claim, that newly arriving mail remains readable after account recovery, is still unverified.
Remus Stealer is advertising a way for criminals to open a compromised Gmail inbox directly from a stolen-device record. Its latest pitch goes further: the operator claims access continues even after the victim changes their password or revokes sessions.
Hudson Rock examined the version 1.3.9 announcement, contacted the developer, and spoke with a person who publicly endorsed the feature. The resulting correspondence offers a possible explanation for access after the malware exits, but it does not validate the developer’s description of a Gmail “zero-day.” The evidence supports investigating a mailbox-access workflow built into an infostealer service. Its mechanism and claimed resistance to recovery remain unresolved.
Supplied screenshots depict message lists, a verification email, and a Mail action attached to stolen-device records.
The developer describes a process that runs and exits. The customer reports access after browser closure and a password change.
No documented test shows fresh mail being retrieved after effective password, session, and application-access revocation.
Mailbox access inside the stolen-log panel
In the supplied version 1.3.9 announcement, Remus promotes email-code interception without collecting browser cookie files, claims that password changes and session revocation do not stop it, and advertises shareable mailbox links. The feature is listed as Enterprise-only; the main sales thread advertises that tier at $1,000 per month.
The sharing claim concerns giving other operators access to an already acquired mailbox through the service. The material does not show a victim being infected by opening one of those links.
The screenshots present more than an isolated code extractor. They show a webmail-style viewer with senders, subject lines, timestamps, search, and individual messages. Remus’s marketing emphasizes cryptocurrency services and YouTube accounts, but a mailbox may also receive recovery links and verification messages for workplace and other sensitive accounts.
What the developer and customer actually said
Asked how the feature operates, the Remus developer pointed to interaction with browser memory and said the software executes and exits. The developer also claimed customers had verified its effectiveness and that the service avoids Google’s anti-fraud checks, while withholding further technical detail.
Hudson Rock then questioned a person who had publicly vouched for the service and described using it. In the Russian-language exchange, the source answered yes when asked whether mail remained accessible after a session reset and browser closure. He also said verification messages from different services were available and described seeing messages from the time of what he called the “injection.”
Browser closure and session reset: The source says mail still appears in the panel under those conditions. The exchange does not specify exactly which sessions were reset.
Message coverage: He reports receiving codes from different services and seeing messages from the time of the initial “injection.” That term does not identify a verified technical mechanism.
Commercial endorsement: He says the feature is worthwhile for his own activity. This is an interested source’s account, not an independent test report.
In a follow-up, Hudson Rock asked whether Remus needed to run again at startup or whether one execution was sufficient for later access through the panel. The source leaned toward the second explanation. This was a tentative answer, not technical confirmation of a one-time execution model.
Asked separately whether access continued after a Google password change, the source answered that it continued. That short reply is the strongest support in the correspondence for the password-change claim. It supplies no account settings, timing, revocation record, or independently observed result.
View the customer’s panel screenshots in their original conversation context
The likely explanation is access obtained from an infected device
If the source accounts accurately describe the behavior, the leading broad explanation is that Remus acquires or establishes reusable authorization while it has access to a signed-in browser. A remote component could then request mail after the local executable exits, for as long as the service accepts that authorization.
This is an inference from the developer’s memory reference and the customer’s account. The material does not identify a particular cookie, token, API, browser-injection method, or account-setting change. The claim of avoiding cookie files also does not exclude using cookies in memory or other browser-held authorization.
Access after process exit and access after recovery are different claims. Reusing authorization obtained during an infection could explain why the original stealer need not keep running. It does not, on its own, explain continued access after that authorization has been effectively revoked.
| Reported condition | What it would establish |
|---|---|
| The stealer exits or the browser closes | Access may outlive the local process. That alone says nothing about whether the account has been secured or remote authorization invalidated. |
| The password changes | The exact recovery action, remaining access paths, and timing matter. A brief source assertion is insufficient to identify what survived. |
| Fresh mail appears after comprehensive recovery | A controlled result would support the stronger persistence claim under the recorded test conditions. Identifying a vulnerability would still require technical analysis. |
Why a stolen-token explanation is not enough
Google documents that password changes ordinarily revoke both access and refresh tokens carrying Gmail scopes. Its documented exceptions include Apps Script; existing OAuth-authenticated IMAP connections can continue only for the access token’s validity, usually about an hour. Those details do not establish that Remus uses any of these paths.
Google also documents exceptions to being signed out everywhere after a password change. These are reasons to examine the recovery steps precisely, not to assume that any stolen Gmail authorization will remain usable indefinitely.
Other explanations remain open: an additional account-access or mail-routing path, incomplete revocation, an unobserved component still operating on the endpoint, or a panel displaying messages collected earlier. None is demonstrated by the supplied material. The developer’s claim that its executable exits does not independently rule out another component or an account-level change.
What would establish the stronger claim?
A meaningful validation would use an authorized test mailbox and instrumented endpoint, document malware and browser activity, then perform recovery from a separate clean device. Investigators would need a message created and delivered after the recorded password change and revocation steps, followed by evidence of that same message appearing in Remus. The test must account for existing connections, revocation timing, and possible reacquisition of access.
The reporting material contains no such controlled sequence, malware analysis, or network telemetry identifying the method. On this evidence, Hudson Rock does not classify the feature as a demonstrated Gmail zero-day.
How the advertised feature fits Remus’s workflow
The supplied images place a Mail action beside individual compromised-device records. This integration is the concrete product story: Remus is presenting mailbox reading as another action available while operators assess stolen logs, rather than requiring a separate webmail workflow.
The wider dashboards below provide product context. They come from the original promotional material and should not be read as current infection totals or evidence validating the new mail feature. Remus’s broader credential and browser-data theft has also been the subject of earlier technical analysis; that work predates this announcement.
The risk is easier access to the accounts behind an inbox
Stolen authentication material enabling later account access is an established threat, as Google’s discussion of session theft explains. Remus’s run-and-exit claim therefore does not establish a novel technique. The feature is worth examining because it packages mailbox access and advertised sharing inside a commercial stealer panel, while making a much stronger claim about access after recovery.
If continuing retrieval of fresh mail is confirmed, an operator could collect new recovery links and verification messages after the initial infection. This could support additional account takeovers, depending on each service’s authentication and recovery controls. The screenshots do not demonstrate a universal MFA bypass, the ability to send mail, or complete control of every connected account.
Priorities for defenders
- Isolate the infected endpoint. Preserve relevant evidence and complete remediation before the device is used for trusted account access again.
- Act promptly from a separate clean device. Change compromised credentials, review signed-in devices, and revoke suspicious sessions and application access. Do not wait for an endpoint rebuild to begin protecting the account.
- Review the mailbox and recovery settings. Check forwarding, filters, delegation, remote mail access, recovery methods, and recent security activity for unauthorized changes.
- Investigate dependent accounts. Prioritize services that use the mailbox for sign-in or recovery. Strengthen authentication and recovery controls where supported; a stronger sign-in method does not remove the need to secure an already compromised endpoint.
Google’s compromised-account guidance provides the relevant account, device, and mailbox checks. Organizations should also use their identity and endpoint telemetry to establish the scope of exposure.
Hudson Rock’s assessment: Remus is marketing an integrated mailbox-reading capability, and a customer has endorsed its claimed persistence. The most plausible broad model is reuse of access obtained or established during endpoint compromise. The evidence does not identify the mechanism or show fresh mail remaining accessible after comprehensive recovery.
The immediate operational lesson is to investigate the endpoint, account authorization, and mailbox together. A password change is an essential recovery step, but it should not stand in for a review of how access was obtained and what remains exposed.
