# ToddyCat-Linked Umbrij Malware Hijacks Gmail via OAuth API Abuse


A sophisticated threat actor known as ToddyCat has deployed a new malware called Umbrij designed to secretly access victims' Gmail accounts through abuse of the Google API, according to research published this week by Kaspersky. The campaign represents a shift in targeting tactics toward cloud-hosted corporate email communications, demonstrating how attackers are increasingly weaponizing legitimate authentication mechanisms to circumvent traditional security controls.


## The Threat: Umbrij's OAuth Attack Method


Umbrij is engineered specifically to compromise email access by exploiting the OAuth protocol, which governs how third-party applications request and receive authorization to access Google accounts. Rather than attempting to steal passwords or session tokens through phishing or malware keylogging, the attackers behind Umbrij pursue a more sophisticated path: they trick victims into granting OAuth consent to a malicious application that then gains persistent access to their Gmail inbox.


Key characteristics of the Umbrij malware:


  • API-focused architecture: Designed to interact directly with Gmail via Google's official APIs rather than through the web interface
  • OAuth token persistence: Obtains long-lived OAuth tokens that remain valid even after password changes
  • Email exfiltration: Capable of downloading email contents, attachments, and metadata
  • Minimal detection footprint: Avoids traditional email client detection methods by using API calls
  • Targeted deployment: Limited distribution suggests careful targeting rather than mass campaigns

    • The use of OAuth is particularly significant because it bypasses many email security controls that monitor unusual login attempts or unfamiliar devices. From Gmail's perspective, the access appears legitimate—it's an authorized application doing exactly what the user granted it permission to do.


    ## Background and Context: ToddyCat's Espionage Focus


    ToddyCat is a sophisticated, state-aligned threat actor that has operated since at least 2020, primarily targeting government, defense, and critical infrastructure sectors across Southeast Asia and beyond. The group's campaigns demonstrate advanced operational security, precise targeting, and a focus on maintaining long-term access for espionage purposes rather than pursuing financial gain.


    Historical context:


  • First public attribution: Kaspersky named ToddyCat in 2023, linking attacks using custom malware tools and infrastructure
  • Geographic focus: Primarily targets organizations in South and Southeast Asia, though broader global targeting has been observed
  • Persistence strategy: Uses living-off-the-land techniques and legitimate tools to avoid detection
  • Tool evolution: Regularly develops new malware variants adapted to specific targets and defensive measures

    • The Umbrij discovery represents an evolution in ToddyCat's toolkit. Previous campaigns relied on custom backdoors and lateral movement techniques. The shift toward email API abuse suggests the group has adapted to increasingly mature endpoint detection and response (EDR) deployments, seeking softer targets in the cloud infrastructure.


    ## Technical Details: How the Attack Works


    Kaspersky's analysis reveals a multi-stage attack flow that transforms OAuth from an authentication convenience into an espionage weapon.


    ### Stage 1: Initial Compromise

    Victims receive targeted phishing emails or are redirected to malicious websites hosting a convincing Google login page or OAuth consent screen. The social engineering typically leverages:

  • Urgent business requests ("Verify your account immediately")
  • Authority impersonation (appearing to come from IT departments or executives)
  • Contextual targeting (references to victim organizations or recent events)

    • ### Stage 2: OAuth Consent Manipulation

    Rather than requesting basic Gmail access, the malicious OAuth application requests permissions for:

  • https://www.googleapis.com/auth/gmail.readonly — Read all email messages
  • https://www.googleapis.com/auth/gmail.metadata — Access email metadata and labels
  • Additional permissions for calendar, contacts, or other sensitive data

    • Many victims may not notice that they're granting access to an application with unfamiliar branding, or they assume the request is legitimate.


    ### Stage 3: Token Generation and Exfiltration

    Once the user grants consent, Google's OAuth flow generates:

  • An access token (short-lived, typically 1 hour)
  • A refresh token (long-lived, potentially indefinite)

    • The attacker captures both tokens and stores them on their infrastructure. The refresh token is the crown jewel—it allows indefinite re-authentication without requiring the user's password or any further interaction.


    ### Stage 4: Remote Email Access

    With valid OAuth tokens, the attacker can now:

  • Query the Gmail API to list all messages in the victim's inbox
  • Download full email contents and attachments
  • Monitor incoming mail in real-time
  • Search for specific keywords or senders
  • All while leaving minimal traces in Gmail's activity logs, since API access appears as legitimate application activity

    • ## Implications: Who's at Risk and What's Exposed


    This attack method poses particular risks to organizations relying on cloud email infrastructure without robust API security controls.


    High-risk targets:

  • Corporate executives and strategic planners — Attackers gain access to sensitive business communications, merger discussions, strategic plans
  • Government and defense sectors — Classified or sensitive correspondence becomes accessible
  • Financial institutions — Transaction details, regulatory communications, and deal information
  • Media organizations — Sources, pending investigations, and editorial correspondence

    • What attackers can access:

  • Complete email histories (years of archived correspondence)
  • Confidential attachments (financial documents, contracts, security policies)
  • Meeting invitations and calendar details
  • Contact networks and organizational hierarchies
  • Metadata revealing communication patterns and priorities

    • Why traditional defenses fail:

  • Email gateway security (spam filters, DLP) cannot inspect API-accessed messages
  • Unusual login detection is bypassed; the access appears to come from Google's infrastructure
  • Multi-factor authentication doesn't stop OAuth consent attacks
  • Email backup and archival systems may not capture API-based access anomalies
  • Organizations often lack visibility into which OAuth applications have been granted access

    • ## Recommendations: Defensive Measures


    Organizations should implement layered defenses to mitigate this threat:


    ### For Security Teams


    | Action | Priority | Implementation |

    |--------|----------|-----------------|

    | Audit OAuth applications | CRITICAL | Review all connected apps in Google Workspace > Security > Connected apps and OAuth. Remove unfamiliar applications. |

    | Restrict OAuth consent | CRITICAL | Configure Google Workspace policies to require admin approval before users grant OAuth consent to third-party apps. |

    | Monitor token usage | HIGH | Enable Google Workspace audit logs and review OAuth token activity for suspicious patterns. |

    | Implement Workspace Insights | HIGH | Use Google's built-in security features to detect unusual email access patterns. |

    | Deploy EDR at scale | HIGH | Ensure endpoint detection and response solutions monitor for OAuth token theft on workstations. |

    | Use CASB solutions | MEDIUM | Cloud Access Security Brokers can monitor API usage and block suspicious OAuth flows. |


    ### For Users


  • Scrutinize OAuth prompts: Never grant broad email permissions to applications you don't recognize
  • Review connected apps regularly: Visit myaccount.google.com/permissions and remove unfamiliar applications
  • Use passkeys instead of passwords: Reduces the attack surface for phishing and OAuth exploitation
  • Enable security keys: Hardware security keys provide the strongest defense against account compromise

    • ### Organizational Best Practices


  • Implement zero-trust architecture for cloud services, requiring verification at every API interaction
  • Use conditional access policies to restrict email access to known devices and locations
  • Maintain comprehensive email audit logging to detect unauthorized API access retroactively
  • Conduct regular phishing simulations specifically targeting OAuth consent screens
  • Establish incident response procedures for compromised OAuth tokens

    • ## HackWire Analysis


    The Umbrij campaign represents a fundamental shift in how attackers target email infrastructure. Rather than fighting your authentication system, they're weaponizing the trust you've placed in OAuth. This is elegant adversarial thinking: why compromise a Gmail server when you can convince the user to grant you permanent, authorized access?


    What makes this particularly dangerous is the detection gap. Traditional email security focuses on network perimeter and message content. It monitors what enters and exits your email system. But OAuth abuse happens *inside* the authorization boundary. From Gmail's perspective, the attacker is a legitimate application performing authorized actions. No alarm bells ring. No suspicious login attempt is flagged. The email simply vanishes into an API stream that your security tools aren't monitoring.


    The timing matters too. The business world has spent the last five years assuming that cloud providers handle security "so we don't have to." Google's security is indeed excellent for protecting infrastructure. But cloud doesn't eliminate social engineering, and it doesn't eliminate user error. In fact, it may amplify the impact—if a user in your organization accidentally grants OAuth access to a malicious application, you've just handed an attacker an all-access pass to years of corporate email.


    For defenders, the uncomfortable reality is that this attack works because it's *user-initiated*. No amount of firewall rules or EDR signatures will catch a user clicking "Allow" on an OAuth consent screen. The defense requires visibility into OAuth application permissions at scale, plus a cultural shift toward scrutinizing what applications users connect. That's operationally harder than patching a vulnerability.


    ToddyCat's adoption of this technique also signals that the threat actor has likely found it effective in their target environments. When sophisticated APT groups change tactics, it's usually because their previous approaches are no longer working. The shift toward OAuth abuse suggests that endpoint security has matured enough that traditional malware deployment is riskier for attackers. The cloud is the new frontier, and OAuth is the attack surface.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)