Umbrij: ToddyCat grants itself Gmail OAuth by hijacking a live browser

Kaspersky’s Securelist team published a look this week at Umbrij, a new tool tied to the long-running ToddyCat APT that steals Gmail correspondence by way of Google’s own OAuth authorization endpoint. The Hacker News summarized the writeup on July 2. This is not a Google bug. There is no CVE. Nothing in Workspace needs to be patched. The interesting part is that none of that helps you if your tenant is exposed to the technique, and the fix is entirely on the defender side of the line.

If your reaction is “we run Workspace with MFA and hardware keys, we’re fine,” stop.

What Umbrij actually does

Umbrij runs post-compromise — the attacker already has code execution on the victim’s Windows box. The tool’s job is to convert that foothold into durable, off-box access to the user’s Gmail, Drive, Contacts, Calendar, and Tasks. Kaspersky calls the technique Shadow Token via Remote Debug. The mechanics, at a level defenders need but no further:

Umbrij makes a copy of the user’s Chromium profile, spins up a headless Chromium instance against that copy with the remote debugging port exposed, and drives the session with Puppeteer. Because the copied profile carries the user’s authenticated Google session, the browser is already signed in when it starts. Puppeteer then navigates to Google’s OAuth authorization endpoint with a client_id that impersonates Google Workspace Migration for Microsoft Outlook — a legitimate Google-published enterprise migration app — and clicks Accept on the consent page requesting Gmail, Drive, Contacts, Calendar, and Tasks scopes. The authorization code drops. Umbrij exchanges it for an access token. The attacker now has a long-lived, off-box OAuth grant against the user’s Google identity.

Everything Google’s identity stack sees is clean. Real user, real browser, real session, real MFA already satisfied at sign-in, real consent click. Kaspersky, Andrey Gunkin’s writeup on Securelist, makes the point plainly: from the IdP’s perspective, this is an authenticated user granting an application the access they were asked to grant.

That is why the token survives password rotation, endpoint reimage, and MFA re-registration. Rotating credentials does not touch OAuth grants. The grant is a separate long-lived asset, sitting in the identity, waiting to be revoked. Nobody who thinks in “reset the password and move on” terms is going to catch it.

Umbrij, in the ToddyCat kit

Kaspersky attributes the tool to ToddyCat, an APT tracking against European and Asian organizations since at least 2020. This is the same crew whose TCSectorCopy tool Kaspersky documented in November 2025. Umbrij is written in .NET, obfuscated with ConfuserEx, and delivered via DLL sideloading against three legitimate signed binaries:

• BDSubWiz.exe (Bitdefender ConnectAgent Submission Wizard)
• VSTestVideoRecorder.exe (Microsoft Visual Studio test tooling)
• GoogleDesktop.exe (discontinued Google Desktop Search)

Persistence uses a scheduled task named KasperskyEndpointSecurityEDRAvp — a deliberate impersonation of the EDR product from the vendor writing the report. That naming choice tells you what the operators expect a defender to skim past on the way to something more interesting.

What to do — in priority order

1. Revoke the two impersonated Google apps across the tenant, tonight.

For every identity in your Workspace tenant, audit third-party OAuth app grants for either of:

• Google Workspace Migration for Microsoft Outlook
• Google Workspace Sync for Microsoft Outlook

Users can see and revoke individually at myaccount.google.com/connections. Workspace admins can audit centrally in the Admin console under Security → API controls → Manage third-party app access. Unless your org is actively running a Microsoft-Outlook-to-Google migration this week, neither app should have a grant sitting in a user account. If it does, revoke it. Don’t just alert on it — revoke.

2. Restrict OAuth app access at the Workspace level.

Google Workspace supports app-access controls that require admin approval before a third-party app can be granted any Gmail, Drive, Calendar, or Contacts scope. Configure the sensitive-scope list to “restricted,” add your legitimate business apps to the allowlist, and every unlisted third-party grant will be blocked at the consent step. This shuts down the mechanic before a compromised browser can complete the OAuth click-through. Yes, it generates helpdesk tickets. That is the point.

3. Hunt the DLL-sideloading indicators on Windows fleets.

The three legitimate binaries above (BDSubWiz.exe, VSTestVideoRecorder.exe, GoogleDesktop.exe) are the DLL-sideloading vehicles. Query your EDR for those process names running from unexpected paths — user profile directories, temp folders, anywhere they don’t belong. The Bitdefender and Google Desktop binaries in particular have no business running on a modern managed Windows endpoint. VSTestVideoRecorder.exe is legitimate for dev workstations but suspicious on a finance or HR box.

Also look for scheduled tasks named KasperskyEndpointSecurityEDRAvp — a defender-facing impersonation, and a distinctive one.

4. Alert on Chromium instances launched with --remote-debugging-port in production.

The remote debug port is how Puppeteer talks to the Chromium instance Umbrij spawned. Legitimate uses of that flag on user endpoints are extremely narrow — some dev workflows, some automated testing rigs. Every other invocation is worth a look. This is a boring EDR query against process command lines and it will fire rarely.

5. Rotate OAuth tokens and re-enroll consent on any user whose endpoint you suspect touched Umbrij.

Password rotation alone will not clear an attacker’s grant. For a suspected-compromised identity: revoke all third-party app grants for the user, revoke all active sessions in Workspace, then require reauth. Do not treat “we reset her password” as incident closure.

Priority call

If you run Google Workspace, do #1 tonight — audit the two impersonated app names across the tenant and revoke every grant that isn’t tied to a documented, in-progress migration project. It takes an hour if your tenant is small and it takes an evening if it isn’t. The alternative is discovering, weeks from now, that a token you never issued has been reading a user’s inbox from an IP you don’t own.

Item #2 — flipping app-access to restricted — is the durable fix. Do that this week. It shuts the door on the next tool that copies this technique from Umbrij, which will absolutely happen; STRD as a pattern is too clean and too portable to stay ToddyCat-exclusive for long.

Everything downstream on this list is worth doing. Nothing downstream helps the identity whose Gmail is already being read.

Sources

• Kaspersky Securelist, ToddyCat APT: Umbrij tool and OAuth abuse (July 2026)
• The Hacker News, ToddyCat-Linked Umbrij Malware Abuses OAuth to Access Gmail via Google API (July 2, 2026)