Malware News Remus malware claims Gmail access even after you change your password

[Brownie2019]

Content source

https://www.malwarebytes.com/blog/news/2026/11/remus-malware-claims-gmail-access-even-after-you-change-your-password

Changing your password should be part of recovering a compromised account. The developers of Remus Stealer are advertising a Gmail-reading feature they claim can survive that step and even session revocation.
That is a serious claim. It is not, however, a demonstrated capability in the published investigation. Threat intelligence company Hudson Rock examined Remus’s promotional material and questioned both its developer and a self-described customer. Its conclusion is more cautious than the sales pitch: The material depicts a mailbox-reading interface, but it does not establish that Remus can retrieve new messages after an account has been comprehensively secured. Nor does it establish a Gmail zero-day vulnerability.

What Remus is advertising​

According to Hudson Rock, Remus’s version 1.3.9 announcement promotes a feature that lets operators open a compromised Gmail mailbox directly from the service’s dashboard. The supplied screenshots show message lists, individual emails, and a “Mail” option attached to records of compromised devices.

The announcement makes several additional claims:

• Operators can intercept email verification codes without collecting browser cookie files.
• Password changes and session revocation do not stop access.
• Mailbox access can be shared with other operators through links.

Asked how it works, the developer described interaction with browser memory and said the malware executes and exits. The developer also claimed the service avoids Google’s anti-fraud checks, but withheld the technical details needed to assess that assertion.
Remember, those are marketing statements from the seller of a criminal service, not independently verified findings.

What the evidence shows​

Hudson Rock spoke with a person who had publicly endorsed the feature and described using it. That source said mailbox access continued after browser closure, a session reset, and a Google password change.

But the correspondence does not document exactly which sessions were reset, the account settings involved, or the timing of the password change and subsequent access. The source’s independence was not established, and the statements were not accompanied by a controlled test.
Hudson Rock explicitly states that its report includes neither reverse engineering of the new feature nor controlled post-recovery validation.

Can Gmail access survive a password change?​

Yes. Under some conditions, continued access after a password change is possible.

Google documents that password changes ordinarily invalidate access tokens and refresh tokens used by applications with Gmail permissions. These tokens allow an application to access an account without asking for the password on every request. Token theft alone therefore does not establish that Remus can maintain access after a password change.

What Gmail users should do​

The uncertainty around Remus’s claims is not a reason to abandon password changes. It is a reminder that recovering from an infostealer infection involves more than changing a password.
If you suspect an infection or unauthorized Gmail access:

• Use a separate, trusted device to begin securing the account promptly. Disconnect the suspected infected device from the internet and remove the malware before signing in to accounts on it again.
• Change your Google password, review recent security events and signed-in devices, and remove unfamiliar access. Check applications with access to the account as well as device sessions.
• Inspect Gmail settings for unauthorized forwarding, filters, delegated mailbox access, and changes to remote mail access. Check your recovery email, recovery phone number, and verification methods too.
• Run trusted security software on the affected device. Google notes that resetting the computer and reinstalling its operating system is another option when dealing with harmful software.
• Review other important accounts that rely on the mailbox for sign-in or recovery, especially if you see unfamiliar verification or password-reset messages.

A mailbox can be a stepping stone to other accounts because it receives recovery links and verification messages. But the Remus screenshots do not demonstrate a universal multifactor-authentication bypass, the ability to send mail, or complete control over every account associated with that address.
Remus’s claimed persistence remains unverified. If you suspect an infection, secure your account and clean the affected device. Real-time anti-malware protection can help prevent infostealer infections.

 

[Bot]

Hi Brownie2019, the central distinction here is exactly right: Remus’s mailbox feature appears real enough to treat seriously, but its advertised persistence after full account recovery is not established.

“Session revocation” is especially slippery because Google has several separate access mechanisms: browser/device sessions, OAuth grants, IMAP connections, app passwords, delegation and forwarding. Saying a session was reset does not show which of those paths—if any—was removed. Closing the browser or terminating the stealer process proves even less; remote reuse of authorization obtained from browser memory could continue without the malware remaining active.

The Hudson Rock/InfoStealers investigation correctly notes that avoiding cookie files does not rule out copying in-memory cookies or other browser-held authorization. It also lacked reverse engineering, network telemetry and a controlled recovery test. A seller’s screenshot plus a customer’s “yes, it still worked” is evidence worth investigating, not a Gmail zero-day announcement.

One useful qualification to the password-change section is that Google’s revocation behaviour has documented exceptions. Google says password changes invalidate access and refresh tokens carrying Gmail scopes, but excludes Apps Script; an existing OAuth-authenticated IMAP session can remain usable for the access token’s lifetime, usually about an hour; and an Android account-sync token on the device initiating the password change is not revoked by that action. See Google’s OAuth revocation documentation. These exceptions do not explain Remus, but they show why “I changed the password and access briefly continued” would not, by itself, prove a bypass.

A convincing test would require fresh mail sent after a recorded password change, removal of relevant sessions and third-party access, inspection of forwarding/delegation and isolation of the infected endpoint—followed by proof that the Remus panel retrieved that fresh message. Until that exists, the sensible verdict is:

• Mailbox access through a compromised signed-in device: credible.
• Access surviving browser closure or malware exit: plausible.
• Access surviving comprehensive recovery indefinitely: unverified.
• Gmail zero-day or universal MFA bypass: unsupported.

For an actual infostealer incident, changing the password from a trusted device remains essential, but it is only one recovery step. Google also recommends reviewing security events and account devices and checking Gmail forwarding, filters, delegation and POP/IMAP settings. If the stealer was executed, a negative scan should not be treated as proof that the machine is clean; the affected user should open an individualized cleanup case through Get help.

Sources

• Automatic OAuth 2.0 token revocation upon password change | Apps & integrations | Google Workspace Help
• Secure a hacked or compromised Google Account - Google Account Help
• Gmail security tips - Computer - Gmail Help
• Remus Stealer Markets Persistent Gmail Access: Hudson Rock Investigates | InfoStealers