Google, researchers in dispute over account hijacking attacks

Threat actors are stealing Google user authentication cookies and hijacking accounts, but Google and threat researchers seem to disagree on certain details surrounding the attacks.

The exploit, first reported publicly on Telegram in mid-October, appears to enable a threat actor to steal Google user authentication cookies and bypass MFA. According to a Dec. 29 blog post from security vendor CloudSEK, the earliest identified reporting of the technique came from a threat actor on Telegram known as "Prisma" on Oct. 20. Over the following months, a number of information stealers such as Lumma, Rhadamanthys and Meduza integrated the exploit.

In November, several security researchers observed Lumma authors boasting on a cybercrime marketplace that the latest version of the malware could restore expired session cookies for Google accounts. At the time, it was unclear how the malware could achieve this, as session cookies are intended to be valid for a limited amount of time while an application is in use.

CloudSEK threat researcher Pavan Karthick referred to the tactic as a "0-day solution" in the deep dive. He said threat actors "target Chrome's token_service table of WebData to extract tokens and account IDs of chrome profiles logged in."

"This table contains two crucial columns: service (GAIA ID) and encrypted_token," Karthick wrote. "The encrypted tokens are decrypted using an encryption key stored in Chrome's Local State within the UserData directory, similar to the encryption used for storing passwords."

According to CloudSEK's research, the root of the issue is an undocumented Google OAuth API endpoint called MultiLogin, which is designed to synchronize Google accounts across different services.

Karthick explained that Lumma malware uses "nuanced manipulation" of the token:GAIA ID pair during authentication to regenerate expired session cookies through abuse of the MultiLogin endpoint. He added that the tactic enables a threat actor to generate valid cookies "in the event of a session disruption" and maintain session persistence. "The session remains valid even when the account password is changed, providing a unique advantage in bypassing typical security measures," he wrote.

However, Google disagreed with a number of the assertions made in CloudSEK's research. A spokesperson for the tech giant told TechTarget Editorial in an email that the API referenced in the deep dive does not function as CloudSEK described:

To clarify some previously published inaccuracies, we use a number of cookies, tokens and APIs to provide signed-in functionality for Google services. The researchers in the report you're referring to are describing an OAuth-based API used to manage signed-in sessions in Chrome. It does not allow revoked or signed-out sessions to be revived or extended (or otherwise used to gain access). While OAuth token theft is less common, it does not offer materially different access than that obtained by stealing ordinary browser cookies, a longtime and ongoing goal of malware.

We also want to clarify that it is not a bug that these stolen tokens are not immediately invalidated by changing your password. This is part of the mechanism we use to keep users signed in after a password change. It is important to remember that if the user signs out, that also signs out the attacker. A user concerned that they may have malware on other devices can sign out those other sessions from g.co/mydevices. As always, we encourage our users to take advantage of tools like Chrome Enhanced Safe Browsing to avoid the threat of malware.

Karthick said Google's statement was correct in that signed-out session tokens could not be used to generate cookies, as "there were a lot of misconceptions in articles which were based on the original blog."

"Victims, often unaware of an infection, are manipulated into disabling their antimalware defenses through social engineering, leaving them vulnerable until the threat actors make noticeable moves such as multiple login attempts," he said. "Those who recognize their infection typically change their passwords, believing this secures their accounts. Yet many are unaware that active sessions can still be exploited after a password reset."

However, Karthick argued that Google's claim that OAuth token theft is uncommon "has become outdated."

"The evolution of malware, as demonstrated by Lumma and about 10-plus other malware families, now includes the technique of using OAuth tokens to regenerate cookies," he said. "This change is significant given the daily count of approximately 10,000 victims of info-stealer malware, underscoring a general lack of awareness about malware capabilities. Often, victims only discover the breach when threat actors have already used stolen information for stealthy session hijacking."

The threat researcher said that while Google might implement security measures to counter such abuses, "threat actors will still find ways to bypass these measures," and real defense lies in user awareness.

One widely discussed point surrounding the technique regards whether threat actors are exploiting a vulnerability or a legitimate feature is being abused. After a thorough discussion with other security experts, Karthick said, he concluded that it was "indeed a legitimate feature that is being exploited."

Malwarebytes senior intelligence reporter Pieter Arntz, who wrote a blog post about the session hijacking, agreed. He told TechTarget Editorial that Google "has been made aware of the issue and seems unwilling to fix it."

"Google claims their MultiLogin API, which is the one used in the info stealers, works as intended. However, this claim is hard to verify since the API is an undocumented one. This could be intentional, but as we have seen on many other occasions, security through obscurity does not work," Arntz said. "Both red teamers and threat actors will find the issue eventually."

Arntz said the apparent unwillingness to fix any underlying issue is "hard to understand."

"From my perspective, the only explanation that makes sense is tied to workload," he said. "This issue would take a lot of resources to fix, while Google seems focused on ongoing efforts to get rid of [third-party] cookies altogether. They may also follow the reasoning that it's the user's responsibility to keep their systems free of malware, such as the info stealers that have the functionality to steal and revive cookies."

Alexander Culafi is an information security news writer, journalist and podcaster based in Boston.