{"id":36412,"date":"2026-07-18T03:19:14","date_gmt":"2026-07-17T16:19:14","guid":{"rendered":"https:\/\/www.kaspersky.com.au\/blog\/google-oauth-email-hijacking-shadow-token-remote-debug\/36412\/"},"modified":"2026-07-18T03:19:14","modified_gmt":"2026-07-17T16:19:14","slug":"google-oauth-email-hijacking-shadow-token-remote-debug","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.au\/blog\/google-oauth-email-hijacking-shadow-token-remote-debug\/36412\/","title":{"rendered":"Email hijacking via OAuth"},"content":{"rendered":"

When targeting an organization to steal information, maintaining a low profile is critical for attackers. They typically aim for long-term persistence, which requires avoiding security alerts while preserving access in case they\u2019re detected and the organization initiates incident response or routine password resets. Malware such as infostealers<\/a> or ostensibly legitimate remote monitoring and management (RMM) tools fail the first requirement: their use triggers EDR and generates suspicious events in SIEM consoles. Relying on stolen credentials conflicts with the second requirement: the moment the security team suspects a compromise, passwords can be changed immediately \u2014 terminating access. If attackers attempt to steal browser cookies<\/a> instead of passwords, they face a different challenge: many online services now correlate device characteristics with the expected session cookie and block access if the cookie is used on an unrecognized device. Furthermore, cookie theft protection mechanisms<\/a> implemented in Chromium-based browsers (such as Chrome, Edge, and Opera) this year have made this approach significantly more difficult.<\/p>\n

To address this persistence challenge, the ToddyCat APT<\/a>\u00a0\u2014 whose main game is spying\u00a0\u2014 developed a novel technique. Kaspersky experts discovered this method during an incident investigation and named it Shadow Token via Remote Debug<\/a> (STRD). This technique allows the attackers to establish reliable, persistent access to a victim\u2019s mailbox and other resources in Google Workspace. With minor adjustments, the same approach could potentially be adapted to target other services that grant third-party application access via OAuth 2.0 authentication.<\/p>\n

How an STRD attack works<\/h2>\n

First, the attackers must compromise the victim\u2019s system with malware. In past campaigns, ToddyCat gained initial access to organizations by exploiting known vulnerabilities in server software and distributing malicious loaders via messaging apps. The specific employee targeted by the attackers might not notice the intrusion at all. This can occur, for example, if the adversary first obtains privileged administrative credentials and uses them to deploy the malware onto targeted machines remotely. Crucially, the deployment and execution of this malware mustn\u2019t trigger immediate security alerts.<\/p>\n

Once active, the malware executes an STRD attack, connecting the attackers\u2019 remote service to the victim\u2019s mailbox using the OAuth 2.0 protocol. This process requires no user interaction and shows no visible activity on the screen. To the cloud environment (Google Workspace, in the case at hand), the activity appears as if the user has legitimately authorized a third-party app for email access or data backup.<\/p>\n

After that, the malware can terminate its operations and even delete itself from the system. The adversary retains direct access to the mailbox using the acquired OAuth token\u00a0\u2014 and they need no connection to the victim\u2019s endpoint or to the corporate network for that. Depending on the organization\u2019s Google Workspace configuration, this access can persist for an extended period and survive subsequent password resets.<\/p>\n

The core concept of Shadow Token via Remote Debug<\/h2>\n

At the heart of this attack is a connection to Google Workspace services via OAuth 2.0. This is a legitimate workflow used whenever a third-party application requests access to calendar data, emails, or Google Drive files. For example, to display calendar meetings in Zoom and automatically generate conference links, a user must authorize Zoom to access Google services. Similarly, configuring a third-party email client or calendar app requires granting permission. During this authorization process, the service requesting access opens a new browser window. In this window, Google Workspace first prompts the user to select the appropriate account. Once the account is chosen, the subsequent screen displays the specific permissions requested by the third-party app, allowing the user to either approve or deny access. For this scenario to proceed seamlessly, the user must already be authenticated to Google services in their browser\u00a0\u2014 which is typically the case in organizations using Google Workspace. If the user isn\u2019t authenticated, additional steps for entering credentials and completing multi-factor authentication are introduced into the sequence.<\/p>\n

The ToddyCat hackers developed a malicious tool called Umbrij<\/a> to facilitate a two-step covert authorization process when the user is already authenticated in Google. First, the malware identifies the browsers installed on the system, and locates the specific folder storing the user\u2019s active profile for each. The attackers target Chrome and Edge, as these are the browsers most likely serving as the primary ones within the organization.<\/p>\n

Next, Umbrij copies the entire user profile folder to a different directory on the machine. It then launches an instance of the browser, specifying the path to the duplicated profile via the command line. Because this duplicate profile contains the user\u2019s session cookies, websites with saved credentials won\u2019t prompt for re-authentication. Furthermore, since this occurs on the exact same computer where the primary browser is running, online services detect no anomalies. The browsing history for this newly launched instance is isolated within the new folder, keeping it hidden from the user\u2019s main account activity.<\/p>\n

Crucially, the browser is launched in a dedicated debugging mode typically reserved for web development. The browser window and user interface don\u2019t appear on the screen at all (headless mode). Instead, the browser can be controlled through a debugging port using the DevTools protocol, allowing the malware to issue commands and read the state of the screen. To orchestrate these actions, Umbrij leverages Puppeteer, a legitimate automation library.<\/p>\n

After verifying that the debugging browser instance has launched successfully, Umbrij opens a legitimate Google Workspace OAuth screen within it. The request sent to Google is engineered to bypass additional security checks while requesting maximum access privileges. For the application ID\u00a0\u2014 the identity supposedly requesting these extensive permissions\u00a0\u2014 the malware impersonates one of two legitimate tools: Google Workspace Migration for Microsoft Outlook (GWMMO), or Google Workspace Sync for Microsoft Outlook (GWSMO).<\/p>\n

When Google opens the window within the headless browser, Umbrij uses debugging tools to programmatically click on the corporate account name and the confirmation buttons. As a result, Google generates an authorization code for the app. Umbrij extracts and saves this code, subsequently forwarding it to the attackers\u2019 command-and-control server. Finally, operating entirely within their own infrastructure rather than on the victim\u2019s computer, the attackers exchange this authorization code for an OAuth access token. This single token is all they need to maintain long-term unrestricted access to the mailbox.<\/p>\n

How to protect against OAuth token theft<\/h2>\n

If a Google Workspace account is compromised, incident response measures must include the following steps after collecting the necessary logs and other forensic data for investigation:<\/p>\n