Malware abuses Google OAuth endpoint to 'revive' cookies, hijack accounts
Malware authors are reportedly exploiting an undocumented Google OAuth feature to “revive” expired authentication cookies, enabling persistent account hijacking even after a user changes their password. Commenters argue this exposes a deeper problem with how Google manages long‑lived sessions and token revocation, creating a gap between users’ expectations (“change password to lock attackers out”) and actual security behavior. The thread also highlights broader unease about over‑reliance on Google accounts—for Gmail, Workspace, and cloud services—given difficult recovery processes, account lockouts, and limited user control over session lifetimes.
Core issue: “Zombie” Google sessions via OAuth
- Malware can allegedly use an undocumented Google OAuth2 endpoint / Chrome extension behavior to “revive” expired Google auth cookies and hijack accounts.
- Key concern: session cookies remain valid even after password changes, undermining the usual “change your password” advice after compromise.
- Some note that the attacker still needs to steal local cookies (e.g., via malware on Chrome/Windows; potentially Mac/Android too).
Password change, session invalidation, and “security theater”
- Several commenters argue it’s a fundamental security failure if password rotation does not invalidate sessions, likening it to unrevoked TLS cert/private-key reuse.
- Others respond that in complex SSO/OAuth systems, terminating all sessions is hard; revoking bearer tokens across many services is an “eventually consistent” / open-loop problem.
- Suggested best practice: at minimum, ask users during password change whether to log out all other devices.
Non-expiring sessions: convenience vs risk
- Some users prefer long-lived or non-expiring sessions and see browser cookie stores as sufficiently protected; they argue that if cookies are stolen, lifetime matters little.
- Others counter that:
- Server-side sessions should not outlive client cookies.
- Password changes, logouts, and account deactivation should reliably kill old sessions.
- Long-lived sessions are especially dangerous for high-value targets (banks, cloud consoles, ex-employees).
Google account lockouts, recovery, and trust
- Multiple anecdotes describe difficulty regaining access despite knowing passwords, having recovery email/phone, codes, or active sessions; processes are described as opaque and changing.
- Some say backup codes and Advanced Protection / paid Workspace accounts work more reliably; others report even paid accounts can hit “can’t verify it’s you” walls.
- Users describe strategies: keeping old logged-in devices, printing backup codes, using their own domains, diversifying providers, or moving off Google entirely.
Controls and options
- There is disagreement on current behavior: some claim changing a Google password signs out all logins; others say old sessions persist unless manually revoked via the security portal.
- Workspace admins can enforce session-length policies; regular Gmail users reportedly have no such configurable control.
Skepticism and missing details
- Some doubt the exploit’s severity due to sparse technical detail in initial reporting, while others link more detailed write-ups and prior bug reports about non-expiring Google sessions.
- One commenter suggests Google might intentionally keep sessions for tracking; others dismiss this as unnecessary and request evidence.