Malware News Kaspersky brings part 2 of their research on the famous APT that masquerades the russian AV company.

[Khushal]

Content source

https://securelist.com/toddycat-apt-umbrij-tool-and-oauth/120251/

Introduction​

How the ToddyCat APT group gains access to Gmail accounts

An in-depth analysis of Umbrij, a new tool used by the ToddyCat APT group to compromise corporate email communications in Gmail. The attack targeted OAuth authorization tokens, allowing threat actors to gain access to Google services.

securelist.com

We continue to share details on the malicious techniques and toolsets used by the ToddyCat APT group. In the first part of this report, we examined the group’s attacks aimed at stealing data from browsers, as well as from local and cloud email services. The methods used in that campaign indicated that ToddyCat was attempting to access corporate correspondence while evading monitoring tools. However, all of the group’s methods we described previously are effectively detected by EPP and EDR solutions.

The attackers continued their search for ways to bypass security solutions and developed a new tool to gain access to a victim’s cloud account via the Google API. Armed with this tool, the group automated all stages of the attack and managed to remain undetected by monitoring systems.

In this part of the report, we break down the mechanics of this new attack and analyze the tool that was used to automate it. We’ll also discuss how to detect and defend against this threat.

Umbrij​

In this campaign, the attackers focused their attention on corporate email communications hosted on Gmail, targeting access compromise via APIs. Because the Google API relies on the OAuth 2.0 protocol for authorization, applications can use an OAuth token to access requested email resources. To acquire this token, the threat actors developed a tool called Umbrij and used it to connect to the browser’s management console in headless mode via a remote debugging port. Through a series of requests, they obtained an OAuth authorization code, which they subsequently exchanged for an access token to reach the target resources via the API. We have dubbed this technique Shadow Token via Remote Debug (STRD).

This attack is viable on Chromium-based browsers. If the user has not logged out of their Gmail account, the browser maintains an active session. The attackers exploit this: they launch the browser, connect via the remote debugging port to take control, and send a request to the Gmail service to grant access to the Google account resources within the context of the user’s saved session.

During our investigation of this attack, we discovered several versions of the Umbrij tool. These versions included a variety of helper functions designed for debugging, as well as for searching and selecting user accounts within the browser, among other tasks.

Kaspersky solutions detect this tool with the following verdicts: HEUR:Trojan-PSW.MSIL.Umbrij.gen, HEUR:Trojan.MSIL.Agent.gen, HEUR:Trojan-PSW.MSIL.Agent.gen.

 

[Bot]

The key takeaway from that Securelist excerpt is that Umbrij is not “breaking” OAuth itself; it is abusing an already-authenticated browser session by taking control of a Chromium-based browser through the Remote Debugging interface, then driving the OAuth consent/authorization flow in the user’s context to obtain an authorization code and exchange it for API tokens (“Shadow Token via Remote Debug / STRD”).

Why this can bypass some monitoring

• If the victim is still signed in to Gmail in the browser, the attacker doesn’t need the password at that moment; they “ride” the existing session.
• Remote Debugging gives powerful control over the browser (tabs, navigation, scripting). That can make the activity look more like normal browser-driven traffic than a standalone credential stealer.
• The end result (OAuth tokens used against Google APIs) can look like legitimate API access unless you have good token/app visibility in Google Workspace logs.

Practical defensive steps (high impact, low risk)

• Prevent/limit Chromium Remote Debugging: In many environments, the most actionable control is detecting and blocking suspicious browser launches that include flags like --remote-debugging-port and/or headless automation. This is commonly visible in EDR process command-line telemetry.
• Harden Google Workspace OAuth posture:
  • Restrict “third-party app access” and require admin approval for OAuth apps where possible.
  • Review and reduce who can grant consent to apps, and enforce least privilege/scopes.
  • Monitor for unusual OAuth grants and token activity (new client IDs, unusual user agents, unusual geolocation/IPs, atypical scopes).
• Session hygiene: Enforce re-authentication/step-up auth for sensitive actions where feasible, and reduce long-lived sessions on managed devices. This doesn’t “solve” the problem alone, but it reduces the window where a hijacked active session is valuable.
• Endpoint controls that often matter here:
  • Application control / allowlisting to reduce execution of unknown tooling (Umbrij is just one implementation).
  • Attack surface reduction rules (where applicable) and policies that reduce abuse of scripting/automation.
  • Keep browsers updated; while STRD is an abuse pattern rather than a single vulnerability, browser hardening and policy enforcement still help.

Detection ideas for defenders

• Endpoint telemetry:
  • Browser processes launched with suspicious automation/debug flags (notably remote debugging port usage).
  • Unexpected headless browser instances or unusual parent/child process trees (for example, a non-standard process spawning the browser).
• Google Workspace / Gmail audit signals (where available):
  • New or unusual OAuth grants and client IDs associated with user accounts.
  • API access patterns inconsistent with the user’s normal behavior (time, IP ranges, volume, endpoints).
• Network indicators (supporting, not standalone):
  • Connections consistent with local/automation control plus rapid OAuth flows; on their own these can be noisy, but they become useful when correlated with endpoint command-line evidence.

What not to conclude from the excerpt

• This doesn’t mean “OAuth is broken” or that “Chromium is inherently insecure.” The core issue is endpoint control of a logged-in browser session plus high-powered debugging interfaces being exposed/abused.
• You generally can’t label a specific environment as compromised from the technique description alone; confirmation requires endpoint/process telemetry and Workspace audit logs.

Sources

• How the ToddyCat APT group gains access to Gmail accounts