Kaspersky Details Umbrij, a New ToddyCat Tool Targeting Corporate Gmail via OAuth Tokens

A research-disclosure read: Kaspersky's Securelist documented Umbrij, a ToddyCat tool that reportedly reaches corporate Gmail through OAuth authorization tokens — and defenders should treat it as a token-hygiene prompt.

MOSCOW — Kaspersky's Securelist has published the second part of its analysis of ToddyCat, documenting a new tool the researchers refer to as "Umbrij" that reportedly targets corporate email hosted on Gmail by abusing OAuth authorization tokens. The write-up, dated around June 30, 2026, attributes the activity to the ToddyCat advanced persistent threat group and frames Umbrij as an addition to the actor's toolset rather than a standalone campaign disclosure. For defenders, the salient detail is the target of the abuse: not passwords, but the authorization tokens that grant applications access to Gmail on a user's behalf.

The account reads as a research disclosure rather than an incident bulletin, and Kaspersky preserves the usual hedges — this is the vendor's own analysis of tooling, not a confirmed tally of breached organizations. That framing matters for how security teams should respond. Rather than reconstruct how the tool works, the actionable reading is a posture review: for organizations that depend on corporate Gmail, this is a week to look hard at OAuth-token hygiene, third-party application authorizations, and the detection coverage tied to them. The full write-up appears on Kaspersky's Securelist, and it lands amid a run of nation-state tooling disclosures that have kept identity and mail access at the center of enterprise threat modeling.

What Kaspersky Disclosed

In the second part of its ToddyCat analysis, published on Securelist around June 30, 2026, Kaspersky documented a tool its researchers refer to as Umbrij and attributed it to the ToddyCat advanced persistent threat group. The core finding, as described by Kaspersky, is that the tool reportedly targets Gmail-based corporate email through OAuth authorization tokens — the credentials that let an application act on a user's behalf against a mail service without holding that user's password.

That distinction is the reason the disclosure is worth a defender's attention. OAuth authorization tokens are, by design, a substitute for repeatedly presenting a password; they are issued once a user or administrator grants an application access and can persist across sessions. Reporting that an APT tool orients itself around those tokens rather than around passwords points the defensive conversation toward the lifecycle of the tokens themselves — how they are granted, how long they live, how they are monitored, and how quickly they can be revoked — rather than toward password strength or reset cadence.

Consistent with The CyberSignal's editorial policy, this article does not reconstruct how Umbrij operates at a technical level. Kaspersky's own write-up is the authoritative source for readers who need the tooling specifics; the purpose here is to translate the disclosure into a defender posture for organizations that rely on corporate Gmail. Kaspersky preserves its hedges throughout — this is the vendor's analysis of a tool it attributes to ToddyCat, framed as research rather than as a confirmed account of compromised organizations.

Defender Posture for Corporate Gmail Deployments

For organizations that run their corporate email on Google Workspace, the practical response to a disclosure like this is a review of the OAuth-token surface rather than an emergency password rotation. The controls that matter most sit in the Google Admin console: the inventory of third-party applications that have been granted access to mail scopes, the policies that govern which applications users can authorize, and the visibility teams have into tokens that have already been issued. A disclosure centered on OAuth-token abuse is a prompt to confirm those controls are configured and actually watched, not just present.

The concrete steps are familiar to identity teams and worth restating in this context. Enumerate the applications with access to Gmail scopes and remove ones that are unused, unknown, or over-permissioned. Prefer an allowlist model for third-party app access to mail where the business can tolerate it, so that new authorizations are a deliberate act rather than a default. Confirm that administrators can revoke tokens quickly and that a runbook exists for doing so at scale. And treat the ability to see and cut off token-based access as a first-class part of the mail-security posture, on par with the anti-phishing and account-protection controls that usually get more attention.

None of this requires knowing the internals of the tool Kaspersky documented. The defender value of the disclosure is that it re-centers a control surface — application authorizations and the tokens they produce — that is easy to leave unmanaged precisely because it is meant to be convenient. For Gmail-dependent organizations, the week's work is to make that surface visible and governed.

Detection-Engineering Review per the Published Indicators

Beyond configuration, the disclosure is a cue for detection engineers to review coverage against the behaviors implied by the reporting. Kaspersky's Securelist write-up is the place to source any indicators the research provides; the defender exercise is to map those against existing telemetry and alerting rather than to reverse-engineer the tool. The relevant question is whether current detections would surface anomalous authorization and token activity around corporate Gmail at all.

In practice that means turning to the Google Workspace audit and login logs and asking specific questions of them. Are new OAuth grants to mail scopes logged, reviewed, and alertable? Would a token being used from an unexpected client, network, or geography generate a signal? Is there a baseline for normal application-driven mail access so that a deviation stands out? These are detection-engineering questions that a research disclosure like this one usefully forces, independent of the specific tool that prompted them.

The point is not to chase a single tool's signature but to ensure the token-abuse pattern — access that looks authorized because it technically is — is something the security operations pipeline can see. That pattern is the hard case for detection precisely because a valid token does not look like a failed login or a brute-force spike; it looks like normal, sanctioned access until the volume, source, or timing of the access says otherwise.

Google's Response and What to Watch

As of Kaspersky's disclosure, several external-facing questions are unresolved, and defenders should hold them open rather than assume answers. It is not confirmed whether Google issued a formal advisory in response to the research, nor whether the platform revoked the specific tokens the reporting describes as abused. Those are precisely the developments that would change the calculus for affected organizations, because platform-side revocation or guidance would shift some of the burden off individual administrators.

The watch items are therefore straightforward. Security teams following this disclosure should monitor for any statement or advisory from Google regarding the reported technique, watch for changes to how Google Workspace handles or surfaces the class of authorization the reporting implicates, and note any subsequent research that corroborates or extends Kaspersky's account. In the meantime, the prudent posture is to treat the OAuth-token surface as the organization's own responsibility to govern and monitor, on the assumption that platform-level mitigation, if it comes, will supplement rather than replace local controls.

This kind of open-question discipline is a recurring feature of research disclosures in the nation-state space, where the reporting vendor documents tooling and behavior while the platform's response, the victim set, and the campaign timeline arrive later, if at all. The same measured posture applied to prior identity-centric disclosures such as the OAuth device-code variant of Tycoon2FA against M365 serves here: act on the control surface now, and let the confirmed facts fill in as they do.

Scope and Impact

The scope Kaspersky claims is deliberately bounded. The research documents a tool attributed to ToddyCat and describes its reported orientation toward corporate Gmail via OAuth authorization tokens; it does not present a roster of victim organizations or a confirmed count of compromised accounts. That is a normal posture for a tooling-focused disclosure, and it means the impact should be read as a capability the actor is assessed to possess rather than as a measured breach total. ToddyCat is an established APT presence in threat reporting, and its appearance alongside identity-focused tooling fits a broader pattern in which state-aligned actors increasingly target the authorization layer that sits above passwords — a pattern also visible in coverage of groups such as the Russia-linked Secret Blizzard/Kazuar activity and China-nexus espionage clusters like Showboat.

The impact for defenders is best framed as exposure rather than as a known loss. Any organization that depends on corporate Gmail and grants third-party applications access to mail scopes carries the token surface this research implicates, whether or not it was a target. That framing keeps the response proportionate: the disclosure does not warrant panic, but it does warrant a deliberate look at authorization hygiene for the same reasons that other espionage-tooling reports — from Webworm's China-nexus toolset to the Shadow / Earth 053 activity in Poland and Asia — have prompted reviews of the specific access paths they implicate.

Because the disclosure withholds a victim set and a timeline, the honest impact statement is a conditional one: the reported capability raises the priority of OAuth-token governance for Gmail-dependent organizations, and the true scale of any real-world use will only become clearer if Kaspersky, Google, or independent researchers publish more. Until then, the safe assumption is that the technique class is live and worth defending against, without overstating how widely it has been deployed.

Response and Attribution

Kaspersky attributes the Umbrij tool to ToddyCat, an advanced persistent threat group it has tracked across prior research; the current write-up is presented as the second part of that continuing analysis. Attribution in cases like this rests on the vendor's own tradecraft analysis and toolset overlaps, and Kaspersky frames it as an assessment rather than as a courtroom-grade finding. Whether the activity overlaps with other tracked APT clusters is not confirmed in the disclosure, and defenders should treat any such linkage as an open question until corroborated.

On the response side, the most consequential unknown is the platform's. It is not confirmed whether Google issued a formal advisory or revoked the abused tokens, and the reporting does not describe a coordinated-disclosure timeline. That leaves the near-term response largely in defenders' hands — a familiar situation for research disclosures, and one that mirrors how identity-focused nation-state reporting has landed before, including coverage of China-linked espionage groups operating against government and Asian targets. The constructive move is to act on what is controllable now: token inventory, app-authorization policy, and detection coverage for anomalous mail access.

For attribution watchers, the items to track are corroboration from other vendors, any Google statement that confirms or contextualizes the technique, and future Securelist installments that may extend the ToddyCat series. Each would firm up a picture that, at this stage, is a single vendor's well-supported but appropriately hedged account of a tool it attributes to a known state-aligned actor.

Open Questions

Several specifics are unresolved at the time of publication and should not be filled in by inference. Kaspersky did not name the victim organizations, so the real-world footprint of the tool is unknown. The reporting does not fix a public time window for the activity, so how long the capability has been in use is unclear. It is not confirmed whether Google issued a formal advisory or revoked the tokens the research describes as abused, which leaves the platform-side response an open item. And it is not established whether this activity overlaps with other tracked APT clusters, so any suggestion of a broader campaign linkage remains speculative for now.

What is established is enough to justify the defender posture this article recommends: Kaspersky, in the second part of its ToddyCat analysis, documented a tool it calls Umbrij that reportedly targets corporate Gmail through OAuth authorization tokens, and it attributes that tool to the ToddyCat APT group. From that, the durable takeaway for Gmail-dependent organizations is not a specific indicator to block but a control surface to govern — the authorizations and tokens that grant applications access to mail — and the detection coverage that would surface abuse of it.

The CyberSignal Analysis

The reported facts above are Kaspersky's; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — The Token Is the Target, Not the Password

The most useful reframing in this disclosure is that the reported abuse orients around OAuth authorization tokens rather than passwords. That shifts the defensive center of gravity away from credential strength and reset cadence and toward the token lifecycle — grant, duration, monitoring, and revocation. An organization that responds to a report like this with a password-reset drill is answering a question the disclosure did not ask.

Our reading is that mail security in a Workspace or Microsoft 365 environment is increasingly an authorization-management problem. The controls that bound this class of risk are application-access policy, token visibility, and fast revocation — not the anti-phishing measures that dominate most mail-security programs. Treating the token surface as a crown-jewel control, rather than a convenience feature, is the posture shift the disclosure argues for.

Signal 02 — Authorized-Looking Access Is the Hard Detection Case

A valid OAuth token does not trip the detections tuned for failed logins, brute-force spikes, or impossible-travel on interactive sign-ins. Access that is technically authorized looks like normal, sanctioned activity until its volume, source, or timing says otherwise. That is precisely why this pattern is the hard case for a security operations pipeline, and why a research disclosure like this one is a useful forcing function for a detection-coverage review.

The actionable interpretation for detection engineers is to test explicitly against token-based access anomalies: new grants to mail scopes, tokens used from unexpected clients or geographies, and application-driven mail access that deviates from an established baseline. Teams instrumented to see those signals in Workspace audit logs will bound this class of incident; teams that only watch interactive authentication will not.

Signal 03 — Treat the Open Questions as Standing, Not Temporary

The unknowns in this disclosure — no named victims, no fixed timeline, no confirmed Google advisory or token revocation, no established overlap with other clusters — are not a reason to discount it, but they are a reason to act on the controllable surface now rather than wait for a fuller picture. Our assessment is that the platform response is the item most likely to move, and the one worth watching most closely, because any Google-side revocation or guidance would meaningfully change the local burden.

The forward-looking posture is to govern the OAuth-token surface as an ongoing responsibility and to treat corroboration, platform guidance, and future Securelist installments as the signals that will firm up the assessment. A single vendor's hedged, well-supported tooling analysis is enough to justify hygiene work; it is not yet enough to characterize the campaign's real-world scale, and defenders should hold that line.

Sources