OAuth token theft is a method attackers use to bypass your password and multi-factor authentication entirely. Instead of cracking credentials, they steal the temporary keys (tokens) that apps like your phone or browser use to connect to Gmail on your behalf. Once an attacker has that token, they can read, search, and download your email as if they were you, and your account shows no failed login attempts.
The latest campaign, tied to a group called ToddyCat, plants malware on a victim’s machine, silently launches a hidden browser session, walks through Google’s OAuth login flow, and captures the authorization code before it’s exchanged for an access token. That token is then used to call the Gmail API directly. The malware logs every action and ships the data out to a command server, all while the victim sees nothing unusual in their inbox.
For small and mid-sized businesses, this matters because business Gmail (Google Workspace) accounts hold everything: contracts, payroll threads, vendor invoices, customer lists, and often credentials or reset links for bank accounts and SaaS platforms. A stolen OAuth token gives an attacker weeks or months of silent access, enough time to map your organization, pivot to financial fraud, or sell the data to a competitor.
How does OAuth token theft actually work?
OAuth is the protocol that lets you click “Sign in with Google” on a third-party app without handing over your password. Google gives the app a token that grants limited, scoped access (for example, read-only access to your calendar). The app uses that token to call Google’s API on your behalf.
Attackers exploit this by planting malware that mimics a legitimate app requesting OAuth consent. The malware uses a technique called DLL side-loading, where a trusted, digitally signed executable (for example, a legitimate Google or Microsoft binary) is tricked into loading a malicious library file instead of the real one. Once running, the malware spawns a headless Chromium browser (a version of Chrome with no visible window), navigates to Google’s OAuth authorization page, auto-fills the user’s credentials (often harvested from saved browser passwords or session cookies), and completes the consent flow.
The result is an authorization code, which the malware immediately exchanges for an access token and a refresh token. The access token grants API access for a short window (typically one hour), while the refresh token can be used to request new access tokens indefinitely, until the user explicitly revokes it or changes their password with the “sign out of all sessions” option checked.
Because the token is obtained through a nominally legitimate OAuth flow (the user’s machine initiated it, even if malware did the clicking), Google’s systems see it as a normal app authorization. No suspicious login location, no MFA prompt, no alert.
What can an attacker do with a stolen Gmail token?
Once an attacker holds a valid OAuth token for your Gmail account, they can perform any action the token’s scope permits. In the ToddyCat campaign, the scope included full Gmail API access, meaning the attacker could list all messages, read entire threads, download attachments, search for keywords (“invoice,” “password,” “contract”), and even send email on your behalf if the scope allowed it.
For a professional services firm, that means an attacker can silently harvest client data, billing records, and proprietary methodologies. For a manufacturer, it could expose supply-chain negotiations, pricing, and engineering drawings shared via email. The attacker can also search for reset links or one-time codes sent to the account, letting them pivot into your bank, QuickBooks, or ERP portal.
Because the access happens via API (not webmail), it generates no “new device” notifications, leaves no entry in the standard “devices and activity” log, and produces no failed-login alerts. The only forensic trace is buried in Google Workspace’s OAuth token audit logs, which most small businesses never review.
Equally concerning, if the attacker uses the token to read email in real time, they can monitor your communications with IT support, lawyers, or incident-response teams. If you say “we think we’ve been breached,” the attacker knows to accelerate data exfiltration or wipe their tracks. That intelligence advantage turns a data theft into a coordinated extortion or business-disruption event.
Why does this matter more now?
OAuth token theft is not new, but three factors make it a higher-priority risk for SMBs today. First, business email has consolidated onto a few platforms (Google Workspace, Microsoft 365), so a single successful OAuth attack can compromise an entire organization’s communications at once. Second, attackers have industrialized the technique. The malware samples described in the ToddyCat campaign use off-the-shelf components (headless Chromium, Python scripts, publicly documented API calls) that any moderately skilled actor can replicate or purchase. Third, ransomware and business email compromise (BEC) gangs have started using stolen OAuth tokens as a persistence mechanism. Even after you force a password reset and wipe endpoints, the token remains valid until explicitly revoked.
The business consequence is straightforward: a breach that starts with OAuth token theft bypasses your most visible defenses (password policy, MFA, login alerts) and runs silent until you either notice missing data, receive a ransom note, or learn from a customer that someone impersonated your CFO via email. By that point, the attacker may have already sold your client list, filed fraudulent tax returns using employee W-2s, or poisoned your vendor payment instructions. For more on the downstream impact of breaches that bypass perimeter controls, see our guide to data breach risk.
What are four concrete steps to protect against OAuth token theft?
First, audit third-party app access every month. In Google Workspace, go to the Admin console, navigate to Security > Access and data control > API controls > App access control, and review which apps have OAuth tokens for each user. Revoke any app that is unfamiliar, unused, or granted overly broad scopes (for example, full Gmail access when the app only needs to send calendar invites). Attackers rely on the fact that most organizations authorize an app once and never look again.
Second, enable workspace-level security alerts and OAuth token monitoring. Google Workspace Enterprise editions (and some Business editions) offer alerts for “government-backed attack,” “suspicious OAuth grant,” and “device compromise.” Turn these on, route them to your security mailbox (not the inbox of a single admin who may be on vacation), and designate someone to triage alerts within four hours. If you see an OAuth grant for an app you don’t recognize, investigate immediately. Tools like Google’s Security Investigation Tool can show you which user authorized the app, from which IP, and what data the app accessed.
Third, deploy endpoint detection that monitors for DLL side-loading and headless-browser activity. Modern endpoint detection and response (EDR) platforms can flag when a signed binary loads an unexpected DLL from a non-standard path, or when Chromium or another browser launches with command-line flags that hide the window. These are not smoking guns (developers legitimately use headless browsers for testing), but they are high-value signals. Configure your EDR to alert (not just log) on side-loading events and route those alerts to your MSP or internal IT lead. If you operate in manufacturing or another sector with air-gapped or lightly managed endpoints, prioritize EDR on any machine that can reach the internet and access business email.
Fourth, educate users to recognize consent-phishing. OAuth token theft often begins with a phishing email that asks the user to “review a shared document” or “authorize a calendar plugin.” The link leads to a real Google OAuth consent screen, so it looks legitimate. Train users to pause before clicking “Allow” and to check the app name, developer, and requested scopes. If an app asks for full Gmail access just to view a PDF, that’s a red flag. Make it easy for employees to forward suspicious requests to IT before clicking. For organizations that regularly handle sensitive client data (law firms, accounting practices, healthcare billing), consider our professional services security guidance.
How much does it cost to fix if you’ve already been hit?
If you discover an active OAuth token theft (for example, your CFO notices unfamiliar “authorized apps” or your MSP finds a suspicious token in the audit log), the immediate remediation is free but time-intensive. You’ll revoke the token, force a password reset on the affected account, sign the user out of all sessions, and run an endpoint scan to find and remove the malware. Budget two to four hours of internal or MSP time per affected user.
The real cost comes from the investigation and recovery. You need to determine what data the attacker accessed (every email read, every attachment downloaded), whether they forwarded anything externally, and whether they used the access to pivot into other systems. A forensic email-log review typically costs $3,000 to $8,000 for a ten-user environment and scales linearly. If the attacker exfiltrated customer data or financial records, you may face notification obligations under state breach laws (Connecticut’s data breach notification statute, for example, requires notice within a reasonable time). Legal counsel and notification costs can add another $10,000 to $50,000 for a mid-sized breach.
Lost business is harder to quantify but often larger. If a client learns that their contract terms or proprietary data were exposed, they may terminate the engagement, demand a discount, or require a costly third-party audit before continuing. If the attacker used your email to send a fraudulent invoice or wire instruction (a common follow-on to BEC), you may be liable for the loss, especially if your cyber insurance policy excludes social engineering without specific coverage. The bottom line: an OAuth token theft that runs undetected for 60 days can easily cost a 20-person firm $50,000 to $150,000 in remediation, legal fees, and lost revenue.
Do I really need to worry about this, or is it rare?
OAuth token theft is not a daily occurrence for most SMBs, but it’s no longer exotic. The ToddyCat campaign has been active for years, and similar techniques have been documented in attacks by groups like APT28 (Fancy Bear) and scattered criminal actors targeting business email. The method is attractive to attackers precisely because it bypasses the defenses (MFA, strong passwords, login alerts) that organizations invested in over the past five years.
If your business handles any of the following, you’re a higher-value target: contracts or proposals worth more than $100,000, customer lists that competitors would pay for, payroll or tax records, healthcare billing data, or intellectual property (formulas, designs, proprietary processes). Attackers don’t need to breach every company; they need to breach one in your industry vertical, harvest its client list, and then use that intelligence to craft convincing phishing emails to the rest of the sector.
The honest answer is that OAuth token theft is rare enough that you shouldn’t lose sleep, but common enough that you should implement the four controls above. Monthly OAuth audits, workspace alerts, endpoint detection, and consent-phishing awareness cost little to nothing if you already have Google Workspace and an MSP relationship. Skipping them is a choice to accept a known, documented risk with a clear remediation path.
What should I do right now?
Log into your Google Workspace Admin console (or ask your MSP to do it), navigate to Security > API controls, and review the list of authorized apps for your top five users (owner, CFO, office manager, anyone who handles vendor payments). If you see anything unfamiliar, revoke it and ask the user whether they remember authorizing it. That five-minute check will catch the majority of OAuth compromises before they cause damage.
Then schedule a recurring calendar reminder (first Monday of each month) to repeat the audit. Add a second task: review the security alerts in the Admin console or your SIEM. If you don’t have workspace security alerts enabled, turn them on today. If you’re not sure how, your MSP can configure them in under 30 minutes. For broader guidance on preventing credential theft and lateral movement after a breach, see our cybersecurity learning center.
Finally, brief your team at the next all-hands or in your monthly security tip email. Show them a screenshot of a real OAuth consent screen and explain that if an app asks for “full Gmail access” or “read all files in Drive,” they should forward the request to IT before clicking Allow. Most users want to do the right thing; they just need to know what to look for. That ten-minute conversation will stop more OAuth attacks than any technical control, because the attacker still needs a human to click the button.
Keep reading
Sources
Source: ToddyCat-Linked Umbrij Malware Abuses OAuth to Access Gmail via Google API