Persistent Malware in Google Accounts: Why a Password Reset May Not Be Enough
Security researchers have identified an infostealer technique that can preserve access to Google services by stealing browser authentication material and regenerating session cookies.
A group of information-stealing malware programs has used a technique that can keep an attacker connected to a Google account even after the legitimate user changes the account password. The technique does not recover the password. It abuses already issued browser authentication material, including account tokens and session cookies, to recreate a trusted session.1Ā 2
Ā
The activity was publicly reported in late 2023 by CloudSEK and BleepingComputer. It was associated with several infostealers, including Lumma, Rhadamanthys, Stealc, Medusa, RisePro and WhiteSnake.2Ā The technical capability was sold or incorporated across malware services, so the most accurate description is a persistent account-hijacking technique used by multiple stealers, rather than one single malware strain.2Ā 3
Ā
The immediate lesson is important for users and administrators: changing a password is necessary, but an incident response must also revoke existing sessions, remove the malware from the device and review account activity.
Ā
How the attack works
An infostealerĀ is malware designed to collect valuable information from an infected device. Depending on its design, it may target saved passwords, browser cookies, cryptocurrency wallets, autofill data, email accounts and application tokens.
Ā
When a user signs in to Google through Chrome, the browser stores authentication information that allows Google services to recognise an approved session. A stolen session cookie can let an attacker act as the user without entering the password again. In some cases, this can also bypass a new multi-factor authentication prompt because the attacker is reusing a session that was already authenticated.1
Ā
CloudSEK reported that the malware examined Chrome profile data, including account identifiers and encrypted authentication tokens. The researchers linked the technique to an internal Google OAuth mechanism called MultiLogin. That mechanism is designed to keep browser account state and Google service cookies aligned across services. The problem arose when attackers supplied stolen account identifiers and token material to regenerate service cookies.2Ā 3
Ā
The attack chain can be summarised as follows, without reproducing operational exploit code:
Ā
Stage | What happens | Security significance |
Infection | The user runs a malicious file, fake application or compromised installer | The attacker gains access to the local device |
Collection | The infostealer reads browser data and account tokens | A password is no longer the only secret at risk |
Exfiltration | The stolen material is sent to the operator | The attacker can work from another device or location |
Session regeneration | The operator uses the stolen values to request new Google service cookies | Access may survive an ordinary password change |
Account abuse | The attacker reads mail, changes settings or accesses connected services | Gmail, Drive, YouTube, Ads and other services may be affected |
This description is deliberately high-level. Publishing the exact request format or code would make abuse easier and would not help a legitimate user secure an account.
Ā
Why the password reset can fail as a standalone measure
A password reset changes the password credential. It does not necessarily erase every active browser session, token or malicious process on a previously infected computer. If an attacker has already copied authentication material, the stolen data may remain useful until those sessions are explicitly revoked or the service detects and blocks the activity.
Ā
Malwarebytes reported that some stealers could extend the useful life of stolen cookies through the MultiLogin-related technique. BleepingComputer reported that CloudSEK researchers regenerated Google authentication cookies after a password reset in testing.1Ā 2
Ā
There is an important qualification. Google disputed the idea that stolen sessions are impossible for users to revoke. In a statement reported by BleepingComputer, Google said that affected sessions can be invalidated by signing out of the affected browser or remotely revoking them through the accountās devices page. Google also said it had taken action to secure compromised accounts it detected.2
Ā
The practical conclusion is not that password resets are useless. The conclusion is that password rotation and session revocation address different layers of the incident.
Ā
What users should do after suspected compromise
A response should begin from a device that is known to be clean. If the computer may still contain an infostealer, changing the password on that computer can expose the new password immediately.
Ā
Googleās account-recovery guidance recommends reviewing account activity and signed-in devices, removing unfamiliar devices, changing the password and any reused passwords, enabling 2-Step Verification and removing harmful software.4Ā The following sequence combines that guidance with the specific session-theft risk described by researchers:
Ā
Use a trusted device to open the Google Account security page and review recent activity and all signed-in devices.
Sign out of unfamiliar sessions and revoke sessions that were active on the suspected device. Google provides device-management controls for this purpose.2Ā 4
Change the Google Account password from the trusted device. Do not reuse it on other services.
Change passwords for services that used the same credential or that can be reset through the affected Gmail account.
Run a reputable security scan, remove the infostealer and update the operating system, browser and security software. If the device cannot be trusted, reinstalling the operating system may be safer than attempting a partial cleanup.
Check recovery email addresses, phone numbers, passkeys, two-step methods, forwarding rules, filters, delegated access and third-party applications. Remove changes that the attacker made.
Turn on 2-Step Verification. A hardware security key or passkey can provide stronger protection against phishing than a password alone, although no second factor can compensate for a compromised active session on an infected device.
Review Gmail, Drive, Photos, YouTube, Ads and other Google services for unauthorised activity. Preserve relevant evidence if the account is used for business or financial operations.
Ā
Workspace administrators have an additional control. Malwarebytes describes an Admin console option for resetting a managed userās sign-in cookies, which can help invalidate active sessions at the organisation level.1Ā Administrators should also investigate the endpoint, reset affected credentials and review audit logs.
Ā
The role and limits of multi-factor authentication
Multi-factor authentication remains one of the strongest available protections against password theft. It makes it harder for an attacker to sign in with only a username and password. The cookie-theft technique targets a different point: a session that has already passed authentication.
Ā
That distinction does not make multi-factor authentication irrelevant. It means that account security must include both login protectionĀ and session protection. Users should still enable 2-Step Verification, use phishing-resistant methods when available and avoid approving unexpected sign-in prompts. They should also treat browser cookies and local token stores as sensitive credentials.
Ā
Ā
How infection usually begins
Infostealers commonly reach victims through cracked software, fake updates, malicious advertising, phishing attachments, counterfeit browser extensions or installers that imitate legitimate applications. The user may see a normal-looking installation screen while the malware runs in the background.
Ā
Security controls should therefore address the initial download as well as the account. Google recommends Enhanced Safe Browsing in Chrome as one layer against phishing and malware downloads.2Ā Organisations should combine browser protections with application control, endpoint detection, patch management, least-privilege access and user training.
Ā
A user should be especially cautious when a download asks to disable security software, execute an unfamiliar command, install a browser extension from an unofficial source or provide a password outside the expected sign-in page. A password manager can reduce password reuse, but it cannot by itself stop a malware process that steals active sessions from a browser profile.
Ā
The broader security implication
The incident shows why modern account defence cannot focus on passwords alone. A Google Account is a gateway to email, documents, calendars, advertising systems, media channels and identity-recovery workflows. A stolen session can therefore have consequences far beyond one login screen.
Ā
The technique also illustrates the value of layered response. Googleās service-side controls can detect and revoke suspicious sessions. The userās devices page can remove unauthorised access. Endpoint security can remove the infostealer. Password changes can block reuse of the original credential. Two-step verification can reduce the risk of a fresh sign-in. Each measure closes a different part of the attack path.
Ā
The most defensible response to a suspected compromise is therefore comprehensive: clean the device, revoke sessions, rotate credentials, secure recovery methods and monitor the account. Treating a password reset as the entire remediation plan leaves the browser and its existing authentication state outside the response.
Ā
References
[1]Ā Malwarebytes, āInfo-stealers can steal cookies for permanent access to your Google accountā
Comments