Article Details

Google password resets not enough to stop these info-stealing malware strains. Now every miscreant is jumping on Big G's OAuth account security hole. Security researchers say info-stealing malware can still access victims' compromised Google accounts even after passwords have been changed. A zero-day exploit of Google account security was first teased by a cybercriminal known as "PRISMA" in October 2023, boasting that the technique could be used to log back into a victim's account even after the password is changed. It can also be used to generate new session tokens to regain access to victims' emails, cloud storage, and more as necessary. Since then, developers of infostealer malware – mainly targeting Windows, it seems – have steadily implemented the exploit. The total number of known malware families that abuse the vulnerability stands at six, including Lumma and Rhadamanthys, while Eternity Stealer is also working on an update to release in the near future. Eggheads at CloudSEK say they found the root of the exploit to be in the undocumented Google OAuth endpoint "MultiLogin." The exploit revolves around stealing victims' session tokens. That is to say, malware first infects a person's PC – typically via a malicious spam or a dodgy download, etc – and then scours the machine for, among other things, web browser session tokens that can be used to log into accounts. Session cookies ideally expire frequently, something that can limit their usefulness in account takeover attacks. However, recent cases such as Okta's in October, which involved the theft of HAR files that often contain session cookies, have demonstrated that session hijackings are entirely practical and can lead to major security incidents. Those tokens are then exfiltrated to the malware's operators to hijack those accounts. It turns out that these tokens can still be used to login even if the user realizes they've been compromised and change their Google password. It appears users should log out, and thus invalidate their session tokens, to prevent exploitation. MultiLogin is responsible for synchronizing Google accounts across different services. It accepts a vector of account IDs and auth-login tokens to manage simultaneous sessions or switch between user profiles. Reverse engineering the infostealer malware revealed that the account IDs and auth-login tokens from logged-in Google accounts are taken from the token_service table of WebData in Chrome.  This table contains two columns crucial to the exploit's functionality: service (contains a GAIA ID) and encrypted_token. The latter is decrypted using a key stored in Chrome's Local State file, which resides in the UserData directory. The stolen token:GAIA ID pairs can then be used together with MultiLogin to continually regenerate Google service cookies even after passwords have been reset, and those can be used to log in. Pavan Karthick M, threat intelligence researcher at CloudSEK, reckons the discovery provides evidence of cybercriminals' high degree of sophistication. In Lumma's case, each token:GAIA ID pair is encrypted by the malware, masking the finer details of the mechanism. In a more recent update, however, Lumma introduced SOCKS proxies to bypass Google's IP-based restrictions on token regeneration. In doing so, the malware's developers now expose some details of the requests and responses, potentially undoing some of their earlier efforts to conceal the functionality's inner workings. The encryption of the traffic between the malware's C2 and MultiLogin also lessens the chances of standard security measures detecting the malicious activity, Karthick said, since encrypted traffic is more likely to be overlooked. "The tactical decision to encrypt the exploit's key component showcases a deliberate move towards more advanced, stealth-oriented cyber threats," he added. "It signifies a shift in the landscape of malware development, where the emphasis is increasingly on the concealment and protection of exploit methodologies, as much as on the effectiveness of the exploits themselves." The Register approached Google for information about its plans to address the threat and had not received a response at the time of publication. As we said, changing your password and logging out, and back in again looks like it will prevent tokens from being revived.