Remus Stealer adds Gmail mailbox reading to its stolen-device panel, with an unverified post-reset persistence claim
Remus Stealer advertises, in its version 1.3.9 announcement, a Mail action that opens a compromised Gmail inbox directly from a stolen-device record in its panel. The developer claims access continues after the victim changes the password or revokes sessions, and a customer who publicly endorsed the feature told Hudson Rock that mail remained available after a session reset and browser closure. Hudson Rock did not validate the developer's Gmail "zero-day" description, and the correspondence offers only a tentative explanation for access after the malware exits. The feature is listed as Enterprise-only at $1,000 per month and includes shareable mailbox links for other operators. If continued retrieval of fresh mail is confirmed, the panel could collect recovery links and verification codes for accounts tied to the mailbox, so the risk is high even though the persistence claim remains unverified.
Detalhes técnicos
The developer described the mechanism only as interaction with browser memory and said the software executes and exits. Hudson Rock's inference is that Remus obtains or establishes reusable authorization while it has access to a signed-in browser, and that a remote component requests mail afterwards; the material identifies no specific cookie, token, API, injection method or account-setting change. Elsewhere, Remus is described as stealing cookies, authenticated session tokens and browser encryption keys, and theft of such session material can enable account access without a fresh password or MFA challenge (mallory.ai). Google's documentation states that password changes ordinarily revoke OAuth access and refresh tokens carrying Gmail scopes, with Apps Script as a documented exception and existing OAuth IMAP connections limited to the access token's validity, usually about an hour (support.google.com). The screenshots show a webmail-style viewer with search, senders, subjects, timestamps and individual messages, reached through a Mail action beside each device record.
Remediação
Isolate the infected endpoint, preserve relevant evidence and complete remediation before the device is used for trusted account access again. From a separate clean device, change compromised credentials, review signed-in devices, and revoke suspicious sessions and application access without waiting for an endpoint rebuild. Review forwarding, filters, delegation, remote mail access, recovery methods and recent security activity on the mailbox, and prioritize dependent services that use it for sign-in or recovery. No vendor fix exists for Remus, which is a criminal service, and the material assigns no CVE, so the controls are containment and account hygiene.
Relatos divergentes
The developer and the endorsing customer say access persists after a password change and session revocation (infostealers.com). Google's documentation says password changes ordinarily revoke Gmail-scoped OAuth tokens (support.google.com), so the more authoritative source on token behaviour contradicts the claim for the paths it covers. The developer's Gmail "zero-day" framing is also not validated by Hudson Rock.
Linha do tempo
-
Remus Stealer adds Gmail mailbox reading to its stolen-device panel, with an unverified post-reset persistence claim
ler a análise desta fonte ocultar
Remus Stealer advertises, in its version 1.3.9 announcement, a Mail action that opens a compromised Gmail inbox directly from a stolen-device record in its panel. The developer claims access continues after the victim changes the password or revokes sessions, and a customer who publicly endorsed the feature told Hudson Rock that mail remained available after a session reset and browser closure. Hudson Rock did not validate the developer's Gmail "zero-day" description, and the correspondence offers only a tentative explanation for access after the malware exits. The feature is listed as Enterprise-only at $1,000 per month and includes shareable mailbox links for other operators. If continued retrieval of fresh mail is confirmed, the panel could collect recovery links and verification codes for accounts tied to the mailbox, so the risk is high even though the persistence claim remains unverified.
Technical Details
The developer described the mechanism only as interaction with browser memory and said the software executes and exits. Hudson Rock's inference is that Remus obtains or establishes reusable authorization while it has access to a signed-in browser, and that a remote component requests mail afterwards; the material identifies no specific cookie, token, API, injection method or account-setting change. Elsewhere, Remus is described as stealing cookies, authenticated session tokens and browser encryption keys, and theft of such session material can enable account access without a fresh password or MFA challenge (mallory.ai). Google's documentation states that password changes ordinarily revoke OAuth access and refresh tokens carrying Gmail scopes, with Apps Script as a documented exception and existing OAuth IMAP connections limited to the access token's validity, usually about an hour (support.google.com). The screenshots show a webmail-style viewer with search, senders, subjects, timestamps and individual messages, reached through a Mail action beside each device record.
Remediation
Isolate the infected endpoint, preserve relevant evidence and complete remediation before the device is used for trusted account access again. From a separate clean device, change compromised credentials, review signed-in devices, and revoke suspicious sessions and application access without waiting for an endpoint rebuild. Review forwarding, filters, delegation, remote mail access, recovery methods and recent security activity on the mailbox, and prioritize dependent services that use it for sign-in or recovery. No vendor fix exists for Remus, which is a criminal service, and the material assigns no CVE, so the controls are containment and account hygiene.
Conflicting Reports
The developer and the endorsing customer say access persists after a password change and session revocation (infostealers.com). Google's documentation says password changes ordinarily revoke Gmail-scoped OAuth tokens (support.google.com), so the more authoritative source on token behaviour contradicts the claim for the paths it covers. The developer's Gmail "zero-day" framing is also not validated by Hudson Rock.