Salesloft Drift Breach
Background & Context
Drift is a conversational AI / chatbot platform often embedded into websites to engage leads, capture contact info, and integrate with CRM systems like Salesforce.
Salesloft acquired Drift in 2024. (CSO Online)
The core of the incident involves misuse of OAuth / refresh tokens, which were stolen and then used to access downstream systems that had been integrated via the Drift platform. (Google Cloud)
The attackers did not exploit a zero-day in Salesforce itself; the breach leveraged trust relationships and credential reuse / abuse. (Salesforce Ben)
Attack Timeline & Intrusion Mechanics
Here’s a reconstructed timeline and attack chain, based on forensic disclosures and threat intelligence:
| Phase | Dates / Period | Activities & Techniques |
|---|---|---|
| Initial foothold | As early as March 2025 (dormant presence) |
Attackers reportedly gained access to a Salesloft GitHub account or internal code repository,
possibly via phishing or credential reuse.
Source: Cybersecurity Dive |
| Token theft & staging | June → August 2025 |
Using internal access, adversaries harvested OAuth / refresh tokens and internal secrets
(API keys, config files). Some tokens were legacy or residual from pre-acquisition Drift usage.
Source: CSO Online |
| Active exploitation | August 8–18, 2025 |
Attackers used stolen tokens to impersonate the Drift integration, connect to customer Salesforce instances,
and execute structured SOQL queries to extract data.
Source: WTW |
| Lateral reconnaissance & credential hunting | Within exfiltrated datasets |
Attackers scanned stolen data for embedded secrets (AWS keys, Snowflake tokens, passwords)
to pivot further into connected systems.
Source: Salesforce Ben |
| Anti-forensics & cleanup | During / after exfiltration |
Adversaries deleted or masked query jobs (SOQL jobs) to obscure traces, but logs remained intact.
Source: The Hacker News |
| Incident response & containment | From August 20 onward |
Salesloft and Salesforce cooperated to revoke tokens, disable Drift integrations,
remove it from AppExchange, and engage external DFIR teams.
Source: Google Cloud Blog |
A few key points:
The root cause appears rooted in credential / token management, not a zero-day in a major platform.
Legacy / dormant OAuth tokens appear to have played a critical role — i.e. “sleeping” credentials that weren’t rotated or audited. (CSO Online)
The attackers displayed good operational discipline (minimal noise, data exfiltration through structured queries, cleanup of jobs). (Dark Reading)
Scope, Impact & Affected Parties
Affected Services & Integrations
While the original public disclosure centered on Salesforce, the incident eventually widened:
Google Workspace: Attackers also compromised OAuth tokens associated with the “Drift Email” integration and accessed email from a very small number of Google Workspace accounts (only those explicitly tied to Drift). (SecurityWeek)
Other cloud services: Because attackers harvested credentials inside Salesforce, they may have pivoted to AWS, Sandflake, and other integrated systems. (Salesforce Ben)
Additional SaaS connectors: Any service tied to a Drift integration should treat its OAuth tokens as potentially compromised. (Google Cloud)
Number & Categories of Victims
Over 700 organizations are estimated to have been impacted (public disclosures include Zscaler, Palo Alto Networks, Cloudflare, Tenable, Qualys, SpyCloud, etc.). (cm-alliance.com)
Impacted data is typically in CRM / support systems: contact names, business emails, job titles, support case content, licensing info. (Dark Reading)
Some organizations also disclosed that configuration data or tokens (e.g. AWS keys in support ticket data) may have been captured. (Dark Reading)
Crucially, in most disclosures so far, core product infrastructure or direct internal systems of the victims have not been compromised—only via the SaaS integration vector. (Dynatrace)
Uncertainties and Open Questions
Full blast radius is still unknown. Some victims may yet come forward. (Dark Reading)
Whether stolen credentials have been further abused is not yet confirmed.
Attribution is unsettled. Google Threat Intelligence (GTIG) ascribes the activity to a group called UNC6395, but the hacker group ShinyHunters has publicly claimed responsibility. Google says it has no compelling evidence linking ShinyHunters. (The Hacker News)
The exact chain from initial GitHub compromise → OAuth token theft is still being fleshed out. (CyberScoop)
The role of legacy / inherited tokens (i.e. tokens prior to the Salesloft acquisition of Drift) remains speculative but critical. (CSO Online)
Technical Deep Dive: Key Vulnerabilities & Attack Vectors
Here are the pivotal weak points that enabled the attack, and how they were leveraged:
1. Overly Broad OAuth Scope & Long-Lived Tokens
If an OAuth integration is granted broad privileges (e.g. “read all data”, “run queries”, “export”), possession of a valid token yields deep access. Combine that with long-lived refresh tokens that are rarely rotated, and you have a potential time bomb.
Attackers leveraged stolen refresh & access tokens to continue queries, maintain persistence, and reauthenticate as needed. (Google Cloud)
2. Legacy / Unrotated Token Residue
Tokens that were created before new security policies, or inherited via mergers/acquisitions, can be forgotten in token inventories. These “zombie” credentials are often not monitored or rotated, giving attackers a long window.
In this case, it appears some tokens predated the Salesloft acquisition of Drift, and attackers exploited that fact. (CSO Online)
3. Exfiltration via Structured Queries (SOQL)
Rather than dumping entire object stores, the attackers executed custom SOQL queries to selectively harvest data, making it more surgical and stealthy. (Krebs on Security)
This allowed filtering for records likely to contain credential data, saving bandwidth and reducing noise.
4. Embedded Secrets Inside CRM Objects
A dangerous (and common) anti-pattern is storing secrets—API keys, VPN credentials, cloud tokens—in CRM or support ticket fields. Attackers inside the CRM can trivially parse these.
Because the attackers exfiltrated entire Salesforce object data, they could scan for those embedded secrets and pivot. (Salesforce Ben)
5. Anti-forensics via Job Deletion & Cleanup
The threat actors deleted or disabled the SOQL jobs they used, making investigation harder. However, though jobs were deleted, underlying logs were not altered. (The Hacker News)
That preserved a forensic trail—if victims knew where to look.
6. Chained Credential Harvesting
After gaining access to CRM data, the attackers scanned and matched cloud credentials, then likely tried lateral moves into AWS, Snowflake, or other services. (Salesforce Ben)
This chained approach amplifies the blast radius far beyond just a CRM compromise.
Response, Remediation & Defensive Controls
Actions Taken by Salesloft / Salesforce & Victims
Revoked all active and refresh OAuth tokens associated with Drift integrations. (Google Cloud)
Disabled Drift’s integration in Salesforce, Slack, and Pardot temporarily. (Google Cloud)
Removed Drift from the Salesforce AppExchange until further notice. (Salesforce Ben)
Engaged third-party DFIR / forensic firms (Mandiant, Coalition) to audit and validate platform integrity. (WTW)
Restored integrations gradually after security audits. (Cybersecurity Dive)
Many victim organizations likewise revoked tokens, rotated API keys, disabled Drift, and audited their logs and secret hygiene. (TechRadar)
Recommended Best Practices & Defensive Measures
From this incident, a number of defensive principles and mitigations emerge:
Token Hygiene & Rotation
Regularly rotate OAuth access and refresh tokens — ideally automatically.
Enforce short token lifetimes where possible.
Revoke tokens not used in a defined threshold period.
Granular OAuth Scope & Least Privilege
Only request the minimal permission set required (e.g. read-only, specific objects) rather than “full access.”
Use scoped, capability-limited tokens rather than broad ones.
Token Inventory & Shadow Credentials Discovery
Maintain a centralized catalog of issued tokens across all integrations, including legacy ones.
Audit for dormant or unused tokens (“zombie” tokens).
Particularly after M&A, reconcile inherited integrations or credentials.
Secrets Management Discipline
Avoid storing secrets (API keys, credentials) in CRM, ticket systems, or user-editable fields.
Use dedicated secrets vaults or environment-secured storage mechanisms.
Anomalous Query & Behavior Monitoring
Monitor SOQL/query job patterns, especially large exports or atypical queries.
Alert on bulk data exports, elevated read volumes, or unusual data access times.
Logging, Retention, and Integrity
Ensure logs (query jobs, API calls, token issuance) are retained, immutable, and audited.
Even if an attacker deletes their job, logs should show their actions.
Zero Trust & Conditional Access Controls
Use conditional access policies for OAuth integrations (e.g. IP restrictions, device trust).
Require reauthentication or MFA for high-scope tokens.
Segment and isolate high-value systems (e.g. CRM, cloud accounts) from general network access.
Incident Playbooks for OAuth Compromise
Have a standardized revocation / rotation playbook for OAuth incidents.
Include forensic steps (log correlation, timeline reconstruction, lateral pivot detection).
Pre-position incident response retainer services with OAuth / SaaS expertise.
Supply-chain & Fourth-party Risk Governance
Evaluate not only your vendors, but vendors’ vendors (4th parties).
Post-acquisition audits: when you acquire a company (or a component), immediately assess their credential hygiene, OAuth tokens, legacy integrations, and hidden 3rd/4th party relationships.
Continuous monitoring of vendor connections, even for rarely used integrations. (CSO Online)
Lessons & Key Takeaways
OAuth is powerful — but also perilous. Once a token is compromised, the attacker inherits exactly the permissions that application had.
Legacy credentials are hidden landmines. Tokens created years ago, possibly forgotten, can remain valid and ripe for abuse.
Complex SaaS integration landscapes expand your attack surface. Every connected tool, integration, and plugin is a potential pivot point.
Operational security matters. The adversary in this campaign showed restraint and stealth: delete jobs (but not logs), target narrow data, limit noise.
Detection is possible — if you know where to look. Logs, query history, and devops pipelines can reveal anomalies if instrumented.
Recovery must be surgical and comprehensive. Revoking tokens is necessary but not sufficient — you must also sweep for hidden credentials, validate downstream systems, and monitor for follow-on activity.
Zero-trust thinking must extend to SaaS integrations. Identity and access boundaries should encompass third-party applications as first-class principals.
