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 is designed to read corporate Gmail correspondence by calling the Google API directly rather than scraping a browser session.
• The campaign targets enterprise email hosted on Google Workspace, with initial access still the unresolved piece of the puzzle.
• ToddyCat has historically focused on government and defense targets across Asia and Europe.

ToddyCat has a new tool, and it does not bother with your inbox the way most infostealers do.

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

That is 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 end-user consent screens. An API-first collector, if the operators already hold the right token or refresh material, looks a lot more like an authorized third-party integration than an intrusion. First reported by The Hacker News, the campaign is described as focused on "corporate email communications hosted on Gmail" with the objective of "access compromise via APIs."

Kaspersky has not, at least in the material released so far, spelled out the exact initial access vector. That matters. API abuse is a post-authentication problem. Something has to hand Umbrij a valid credential first — a phished OAuth consent, a stolen refresh token from an endpoint the operators already own, or an app-password artifact lingering on a compromised workstation.

What should defenders patch first?

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

A few 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 the token and login events in the Workspace audit log for OAuth grants issued to clients you do not recognize, then revoke aggressively. Refresh tokens survive password resets; they do not survive a client-level revocation.
4. For high-value mailboxes (executives, finance, legal), consider Context-Aware Access rules that bind API access to managed devices or known IP ranges.

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

One caveat worth stating plainly: attribution to ToddyCat 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, and quietly, over channels your email security stack was never built to inspect.