“This endpoint operates by accepting a vector of account IDs and auth-login tokens — data essential for managing simultaneous sessions or switching between user profiles seamlessly,” CloudSEK said in the blogpost. “While the MultiLogin feature plays a vital role in user authentication, it also presents an exploitable avenue if mishandled, as evidenced by recent malware developments.”
To confirm that a MultiLogin endpoint has been used to regenerate session cookies in the exploit, CloudSEK conversed with Prisma and reverse engineered the exploit executable provided by the threat actor. The study revealed the specific undocumented MultiLogin endpoint that was used in the exploit.
Password resets are not enough
The exploit is possible only after an initial hack into a user’s system to retrieve valid user session tokens. A malware initially infects a victim’s computer, often through methods like malicious spam or untrustworthy downloads. Once the system is compromised, the malware searches for web browser session cookies and other data that can be exploited to gain unauthorized access to accounts.
The pilfered session tokens are sent to the operators of the malware, allowing them to infiltrate and take control of the compromised accounts. Notably, even if users detect the breach and change their Google password, the stolen tokens can still be used for login. The malware extracts and decrypts account IDs and authentication tokens from active Google accounts by examining the token_service table in the WebData of Chrome, which it uses together with MultiLogin to continuously regenerate session information.
To mitigate this risk, users are advised to log out completely, thereby rendering the session tokens invalid and preventing further exploitation.
Lumma hid exploit with token encryption
In order to obfuscate its exploitation mechanism, Lumma encrypted the access token extracted from the token_service table: GAIA ID pair, a critical component in Google’s authentication process.
