Remus Stealer claims persistent Gmail access, Hudson Rock reports
Hudson Rock reports the Remus Stealer developer claims Gmail access survives password changes, unverified; secure accounts and clean devices.
- Published
- Ecosystem
- Desktops, browsers and mobile
- Exploitation
- No confirmed exploitation; the persistence claim rests on the developer’s and one customer’s statements and is unverified
What happened
According to InfoStealers (Hudson Rock), the Remus Stealer service advertises a way to open a compromised Gmail inbox directly from a stolen-device record. Hudson Rock says the operator claims this access continues even after the victim changes their password or revokes sessions. Hudson Rock says the claim is unverified and that it does not classify the feature as a demonstrated Gmail zero-day.
Hudson Rock reports the following, based on a version 1.3.9 announcement and its own correspondence:
- The announcement, per Hudson Rock, promotes email-code interception without collecting browser cookie files and shareable mailbox links. The feature is listed as Enterprise-only, and the main sales thread advertises that tier at $1,000 per month. Hudson Rock describes this as a vendor claim.
- Hudson Rock says the developer pointed to interaction with browser memory and said the software executes and exits. The developer also claimed customers had verified the feature and that it avoids Google’s anti-fraud checks, while withholding technical detail.
- A person who publicly vouched for the feature told Hudson Rock that mail remained visible after a session reset and browser closure, and later said access continued after a Google password change. Hudson Rock notes this is an interested source, and that the reply supplies no account settings, timing, revocation record or independent observation.
- Hudson Rock’s leading inference is that the malware obtains reusable authorization from a signed-in browser on the infected device, which a remote component could use after the local process exits. It stresses this is an inference. It says the material does not identify a specific cookie, token, API or injection method.
What is not confirmed, according to Hudson Rock:
- Access after full recovery (password, session and application-access revocation) is not established. It says no documented test shows fresh mail retrieved after those steps.
- The mechanism is not identified. Hudson Rock lists other open explanations: an additional account-access or mail-routing path, incomplete revocation, another component still running on the endpoint, or a panel showing messages collected earlier.
- The supplied screenshots are not a controlled demonstration of live access, and Hudson Rock says they do not demonstrate a universal MFA bypass.
Hudson Rock also notes that Google documents password changes as ordinarily revoking access and refresh tokens with Gmail scopes, with documented exceptions (Apps Script, and existing OAuth-authenticated IMAP connections for the access token’s validity, usually about an hour). It says these details do not establish that Remus uses any of those paths.
Am I affected?
Not confirmed. Hudson Rock describes the displayed record counts and statistics in the Remus material as vendor-supplied, not verified victim totals.
Hudson Rock describes access that starts from an infected device. Whether a given account is at risk would depend on whether a device where you were signed in to Gmail was infected with this stealer, and the source text does not give a way to determine that. Hudson Rock treats this as a stealer-service capability claim, not a demonstrated Gmail vulnerability.
What to do now
- Treat the persistence claim as unverified. Hudson Rock says the stronger claim, access after full recovery, is not established.
- If you have reason to believe a device was infected, consider doing account recovery from a separate clean device. This mirrors the validation design Hudson Rock describes, which performs recovery from a separate clean device.
- Check the recovery steps carefully. Hudson Rock says the exact recovery action, remaining access paths and timing matter, and that password change, session revocation and application-access revocation are distinct steps. Also check for unexpected account-level changes, which the source lists as an open possibility but does not demonstrate.
- Check accounts whose recovery links and verification messages arrive in the affected inbox. Hudson Rock says that if continuing retrieval of fresh mail were confirmed, an operator could collect new recovery links and verification messages, depending on each service’s authentication and recovery controls. It does not say any such takeover has occurred.
- Follow updates from Hudson Rock. This advisory will be revised if a controlled test or technical analysis confirms or refutes the claim.