ToddyCat's New Umbrij Malware Pulls Gmail Straight From Google's API

Key points

• Kaspersky this week attributed a new malware family called Umbrij to the ToddyCat threat actor, a group active since at least 2020.
• Umbrij reads corporate Gmail correspondence by calling the Google API directly rather than scraping a browser session.
• The campaign targets enterprise email hosted on Google Workspace; how operators acquire the initial credential remains unclear.
• ToddyCat has historically focused on government and defense targets across Asia and Europe.

ToddyCat has a new tool, and it doesn't bother with your inbox the way most infostealers do.

Kaspersky this week published analysis of a malware family they call Umbrij, tying it to the same China-aligned intrusion set that's been hitting government and telecom targets since 2020. Instead of hooking a browser or lifting session cookies from disk, Umbrij talks to Gmail through Google's own API to pull message content from victim mailboxes.

That's a meaningful shift in tradecraft. Browser-resident stealers and mailbox-sync clients both leave loud artifacts: new processes, IMAP/SMTP traffic, OAuth grants surfacing in consent screens. An API-first collector, if operators already hold a valid token or refresh material, looks far more like an authorized third-party integration than an intrusion. First reported by The Hacker News, the campaign targets "corporate email communications hosted on Gmail" with the objective of "access compromise via APIs," according to Kaspersky.

Kaspersky hasn't spelled out the exact initial access vector in the material released so far. That matters. API abuse is a post-authentication problem. Something hands Umbrij a valid credential first: a phished OAuth consent, a stolen refresh token from a box the operators already own, or an app-password artifact on a compromised workstation.

This pattern has a recent parallel. Our 15 June report on a China-nexus crew abusing Google Workspace mail-forwarding rules showed how quietly an attacker can work once they're inside a tenant's identity layer.

What should defenders patch first?

There's no CVE here. This isn't a Google vulnerability in the traditional sense, and there's no fixed-version string to chase. The exposure lives in your tenant configuration and your token hygiene.

Four concrete moves for Workspace admins:

1. Audit third-party app access under Admin console → Security → API controls. Restrict https://www.googleapis.com/auth/gmail.readonly and the broader gmail.modify and full mail.google.com scopes to an allowlist of vetted OAuth clients. Google documents the scope inventory in its OAuth 2.0 Scopes reference.
2. Turn on unverified-app blocking and require admin approval for any client requesting Gmail scopes.
3. Review token and login events in the Workspace audit log for OAuth grants issued to clients you don't recognize, then revoke aggressively. Refresh tokens survive password resets; they don't survive a client-level revocation.
4. For high-value mailboxes covering executives, finance, and legal, consider Context-Aware Access rules that bind API access to managed devices or known IP ranges.

Should you trust the attribution?

ToddyCat has a documented habit of building bespoke tooling rather than reusing commodity kits. Kaspersky has tracked the group since 2020 and previously documented it deploying the Samurai backdoor and Ninja Trojan against ASEAN government targets. Umbrij fits that profile.

One caveat worth stating plainly: attribution rests on Kaspersky's telemetry and code-similarity work, and no second vendor has corroborated the link publicly at time of writing. Treat the tooling as real and the naming as provisional.

The defensive lesson is older than this campaign. If your identity provider hands out long-lived tokens that survive endpoint compromise, an attacker who owns the endpoint owns the mailbox: indefinitely, quietly, over channels your email security stack was never built to inspect.