Google Workplace Included in Salesloft Drift App Attack

If your company uses Salesforce, Google Workspace (sometimes called “Google Workplace” in headlines), and a few handy
sales tools to glue everything together, you probably felt a weird chill in late summer 2025like someone left the
office fridge open, except the fridge was your SaaS stack.

The Salesloft Drift app attack became a headline-grabber because it didn’t rely on a flashy “zero-day” or a dramatic
Hollywood-style hack. Instead, it exploited something far more modern and far more common: trusted integrations.
In this incident, attackers leveraged stolen OAuth tokens tied to Salesloft Drift to access data in
Salesforce environments andcritically for many organizationsextended impact to a small number of
Google Workspace email accounts connected through Drift’s email integration.

The takeaway is uncomfortable but useful: you can do everything “right” with passwords and multi-factor authentication
(MFA) and still get burned when an integration shows up holding what looks like a valid VIP badge. This article breaks
down what happened, why Google Workspace was included, what attackers were after, and how organizations can reduce the
risk of SaaS supply chain and token-based attacks going forward.

What Happened: The Attack in Plain English

Salesloft’s Drift platform is commonly integrated with Salesforce to support sales and customer engagement workflows.
Those workflows often rely on OAuth, which is a secure way to let an application access specific resources without
handing over a user’s password.

In the Salesloft Drift app attack, threat actors obtained OAuth (and in some cases refresh) tokens associated with
Drift integrations. With those tokens, they could authenticate like the legitimate app and perform actions that looked,
from a system perspective, like normal integration behaviorjust at a very not-normal scale.

The incident drew intense attention because it demonstrated a “logged-in” style of compromise: instead of breaking
into systems, attackers signed in using delegated access. And when you can sign in as a trusted integration,
you can often bypass controls designed for human logins (like MFA prompts), because the integration isn’t “logging in”
the same way a person does.

Why Google Workspace (Google Workplace) Was Included

Drift didn’t only connect to Salesforce. Many organizations also enabled Drift’s email integrationoften referred to as
“Drift Email”to sync communications, track outreach, or support sales activity. When Google later confirmed that OAuth
tokens associated with that email integration were compromised, it meant a limited set of Google Workspace accounts
could be accessedspecifically, accounts that had been configured to connect to Salesloft Drift.

It’s worth stressing what this does and doesn’t mean. The incident wasn’t described as a breach of Google’s
core systems. It was an integration problem: tokens granted to a third-party app were abused. But from an admin’s point
of view, that nuance matters mostly in the post-incident report, because the operational reality is the same:
email data can be exposed, and email is where most organizations store the context attackers lovethreads,
attachments, invoices, internal conversations, escalation chains, and “quick questions” that are never actually quick.

A Timeline That Explains the “How Did This Get So Big?” Feeling

Public reporting and advisories outlined a multi-stage timeline that is now typical of SaaS supply chain incidents:

• Earlier foothold and reconnaissance (spring 2025): Investigations described attacker activity in
  Salesloft/Drift environments over a period of months, consistent with staging and exploration rather than a single-day smash-and-grab.
• Salesforce data theft window (mid-August 2025): Attackers used compromised tokens to access numerous
  Salesforce customer instances and exfiltrate data using API-driven methods.
• Google Workspace impact confirmed (August 2025): Google later confirmed that compromised tokens for the
  Drift email integration were used to access email from a very small number of Google Workspace accounts that had enabled the integration.
• Containment actions: Actions described publicly included revoking relevant tokens and disabling certain integration functionality while investigations continued.

The punchline is: attackers didn’t need to compromise every service directly. They only needed to compromise the
connections between servicesand then use those connections as highways.

How OAuth Token Theft Turns Integrations Into “Master Keys”

OAuth is designed to be safer than sharing passwords. But it introduces a new security object to defend:
the token. Tokens are powerful because they represent delegated trust. If a user (or admin) grants an app
permission to read certain data, the app receives tokens that let it do exactly thatoften without repeated prompts.

Here’s why stolen tokens are so dangerous in real-world incidents:

1) Tokens can bypass human-focused security

MFA protects interactive logins. OAuth tokens can allow access without triggering the same interactive checksespecially
when the token is already issued and valid. That’s not a flaw in MFA; it’s a reminder that MFA is one layer, not a force field.

2) Refresh tokens can extend access

Depending on configuration, refresh tokens can keep access alive longer than you’d expect. That turns a one-time theft
into persistent accessuntil tokens are revoked.

3) API access enables high-volume extraction

Once authenticated, API calls can pull data quickly and consistently. In the public reporting around this campaign,
attackers were described as running large volumes of queries to collect sensitive information at scale.

4) The activity can blend in

A malicious login at 3:00 a.m. from a new country looks suspicious. A trusted integration calling an API looks like
Tuesday. Defenders have to spot the difference between “normal usage” and “normal usage, but with a forklift.”

What Attackers Were After (And Why Email Became Part of the Prize)

The Salesforce portion of the campaign was widely discussed as data theft at scalecustomer records, support cases,
and business data. Reporting also described attackers hunting for valuable “secondary secrets” stored in systems that
weren’t meant to be secret vaults: things like cloud access keys, passwords, and service tokens embedded in notes,
cases, or internal documentation.

Email access adds another layer of value because inboxes are the ultimate context engine. Even limited mailbox access can:

• Reveal sensitive attachments (contracts, SOWs, invoices, security questionnaires)
• Expose organizational relationships (vendors, legal counsel, customer escalation contacts)
• Enable extremely convincing social engineering (replying in-thread, impersonating the right person at the right moment)
• Provide intelligence for follow-on attacks (password reset patterns, internal tooling references, help desk workflows)

Put simply: Salesforce is the “what.” Email is the “how, who, and when.” Combine them and attackers don’t just steal
datathey steal the map of how your business runs.

Immediate Steps for Organizations: What to Do Without Panicking (Much)

If you’re responsible for security or IT operations, the goal is rapid containment followed by deliberate improvement.
Here’s a practical, defensive checklist that aligns with guidance commonly recommended in major token-abuse incidents.

1) Inventory and reduce third-party app exposure

• List all OAuth-connected apps in Google Workspace and Salesforce (and any other connected SaaS platforms).
• Remove unused integrationsespecially those nobody can confidently explain.
• Restrict app access to approved apps and approved scopes wherever possible.

2) Revoke tokens and rotate secrets (strategically)

• Revoke affected tokens for integrations tied to the incident, and reauthorize only if needed.
• Rotate API keys and credentials that may have been stored in Salesforce records, support cases, or internal docs.
• Prioritize high-impact secrets first: cloud provider keys, data warehouse tokens, privileged service accounts.

3) Hunt for “integration-shaped anomalies”

Your classic threat hunting playbook (new user, weird login, suspicious device) is still useful. But token abuse
often shows up differently:

• Unusually high API call volume over short periods
• Bulk export patterns that don’t match business workflows
• Access to objects or mailboxes that the integration rarely touches
• Unusual user-agent strings or automation patterns tied to API clients

4) Validate what was accessed, not just what was “at risk”

Security incidents can turn into guessing contests if you don’t anchor the response in logs. Focus on audit data:
which objects were queried, what timeframes, which mailboxes, which IP ranges, and which token identities were used.
Then decide what to notify, what to reset, and what to monitor for follow-on activity.

Hardening Google Workspace Against OAuth Abuse

Google Workspace is frequently targeted because it’s central to identity, communication, and document sharing. The
best defenses reduce the chance that a single OAuth authorization becomes a long-lived permission slip.

Use least privilege like you mean it

When evaluating integrations, treat broad email scopes as high risk. If an app requests “read all mail,” ask why.
If the answer is “because it’s convenient,” that’s not an answerit’s an apology wearing a trench coat.

Enforce admin control over third-party app access

Many organizations tighten policy so only approved apps can access Workspace data, and risky scopes require explicit
admin approval. This reduces the odds of surprise authorizations and helps keep app inventories clean.

Segment integration accounts

If an integration truly needs email access, consider using a dedicated mailbox or service identity designed for that
purposerather than granting access through a high-privilege executive or a broadly used shared inbox.

Detect token abuse with alerting and audits

Build alerting around unusual third-party app activity and unusual access patterns. Treat “new app added” and “app
permissions changed” as security-relevant events, not mere IT trivia.

Hardening Salesforce Against Token-Based Data Theft

Salesforce environments can contain extremely sensitive data, including customer records and support information.
When attackers access Salesforce through a trusted connected app, defenders need controls that focus on the integration path.

• Review connected apps and remove or restrict those that are not necessary.
• Limit API access to the minimum required by role, integration, and environment.
• Monitor for bulk export patterns and unusual query behavior.
• Isolate and protect secrets: discourage storing passwords, keys, and tokens inside CRM fields, notes, or case attachments.

One of the most pragmatic lessons from campaigns like this is organizational, not technical: if your CRM has become a
“secret drawer,” it will eventually be treated like oneby someone who isn’t supposed to have the key.

The Bigger Lesson: Fourth-Party Risk Is Now Everyone’s Problem

Traditional third-party risk asks: “Do we trust Vendor A?” Fourth-party risk asks: “Who does Vendor A trust… and do they
trust anyone who trusts anyone who trusts our email?” (SaaS supply chains are basically a family tree drawn by a caffeinated intern.)

The Salesloft Drift incident reinforced a modern reality: organizations don’t just rely on vendors; they rely on the
integrations that connect vendors. Security models have to account for non-human identities (apps, tokens, service
accounts) with the same seriousness we apply to employee identities.

The best long-term program improvements tend to look like this:

• Integration governance: centralized visibility into what apps connect to what data.
• Permission discipline: least privilege scopes, frequent reviews, removal of unused grants.
• Token lifecycle management: rapid revocation capability and clear ownership of each integration.
• Incident drills: practice “revoke and reauthorize” workflows so it’s not a first-time experience during a real event.

Conclusion: Trust Is a FeatureUntil It’s a Vulnerability

“Google Workplace included in the Salesloft Drift app attack” reads like a strange crossover episodeCRM meets email
meets chatbot meets bad day. But the storyline is consistent with how modern breaches unfold: attackers exploit trust,
not just code.

If your organization uses integrated SaaS tools, the goal isn’t to unplug everything and go back to spreadsheets
(though spreadsheets never breached anyone; they just quietly ruin budgets). The goal is to run integrations like
production systems: inventory them, constrain them, monitor them, and be ready to revoke access fast.

Because in 2026 and beyond, the question isn’t “Do we have MFA?” It’s “Do we have a plan for the things that log in
without MFAbecause we told them they could?”

Experiences From the Front Lines (Composite Stories & Practical Lessons)

The most interesting part of incidents like the Salesloft Drift app attack isn’t the headlineit’s the week afterward,
when teams discover how many business processes quietly depend on a single integration toggle.

Experience #1: The “Why Is Salesforce So Busy?” Mystery

A common early signal in token-based campaigns is not a dramatic alert, but a performance question. A sales operations
manager notices reports timing out. A Salesforce admin sees unusual API usage spikes that don’t match any campaign or
quarterly push. At first, it looks like normal “end-of-month chaos.” Then someone asks the key question:
“Who is doing all these queries?”

In many environments, integrations are allowed to operate broadly because they make work easierlead routing, activity
tracking, chat-to-CRM syncing. So the first response is often to hunt for a misconfigured tool or a new automation.
The lesson teams report learning quickly: treat high-volume API behavior as a security signal, not just
a billing or performance signal. If you can’t quickly tie activity back to a known workflow owner, you’re already behind.

Experience #2: The “Google Told Us to Revoke Tokens” Fire Drill

When a platform provider revokes or flags tokens, admins usually discover two things at once: (1) the organization
has more connected apps than anyone remembered, and (2) business users interpret “revoke access” as “security is
breaking productivity on purpose.” That tension is real.

The teams that handled it best tended to do three things fast: identify which users actually had the integration enabled,
communicate a simple timeline (“We’re disabling X today, restoring approved access tomorrow”), and offer a workaround
for critical functions. The best lesson: build a lightweight internal playbook for “integration outages,” because your
response shouldn’t require improvising a policy debate in Slack while executives ask why email sync disappeared.

Experience #3: The Unexpected Secret Hunt

Many organizations learned (again) that secrets leak into places they don’t belong. Support cases can contain cloud keys.
Deal notes can include credentials shared “temporarily.” Attachments can hold configuration exports. During post-incident
review, teams often ran searches for patterns that indicate secrets (key formats, token strings, “password:” labels) and
found more than they expected.

The practical takeaway isn’t just “rotate keys.” It’s to reduce the chance that your CRM and inbox become a secret
repository in the first place. Teams that made real progress updated internal guidance (and sometimes tooling) so that
sensitive credentials are stored in dedicated secret management systemsnot pasted into cases, emails, or notes.

Experience #4: The AftershockPhishing, Impersonation, and “Are You Sure This Is Real?”

Even limited email access can create long-tail risk. People reported heightened phishing attempts that referenced real
projects, real clients, and real internal languageexactly the kind of detail that makes employees hesitate before
hitting “Report Phish.” Some organizations also reported dealing with extortion-style messaging that arrived well after
the initial incident window, making it harder to connect the dots.

The best response pattern here wasn’t technicalit was behavioral: organizations reminded teams to verify unusual
requests out-of-band, trained staff on “in-thread” impersonation risks, and used clear escalation paths for employees
to ask, “Is this email weird, or am I just tired?” (Spoiler: sometimes it’s both.)

Experience #5: The Integration Clean-Up That Actually Stuck

The happiest endingif you can call it thatwas when companies used the incident to finally rationalize their app stack.
They created an “integration owner” model (every connected app has a named business owner and a named technical owner),
scheduled periodic permission reviews, and implemented tighter approval for high-risk scopes like broad email access.

A surprisingly effective tactic: treat integrations like employees. Employees need onboarding, access reviews, and offboarding.
Integrations need the same. If a tool can read your email or export your CRM data, it deserves the same governance you’d
apply to a new hirepreferably one with fewer caffeinated opinions and more audit logs.