The Salesloft OAuth compromise: what it changed, and what to do next

TL;DR
In early August 2025, a threat cluster tracked as UNC6395 abused stolen OAuth tokens from Salesloft’s Drift integrations to authenticate as the app into customer environments, first into Salesforce, then to Google Workspace accounts tied to Drift Email application, with potential exposure to other integrations.
The access allowed for bulk queries and data exfiltration, followed by credential mining for secrets to power follow-on access. On Aug 20, Salesloft and Salesforce revoked Drift tokens and Salesforce removed the app from AppExchange; Salesforce also temporarily disabled the Drift integration with Salesforce, Slack, and Pardot as a precaution. Later, Google revoked the specific Drift Email tokens and disabled that integration.
This was not a Salesforce or Google Workspace vulnerability. It is a non-human identity (NHI) problem, requiring identity-first governance that treats tokens, apps, and service accounts as first-class citizens and provides monitoring and proactive security to their access.
What made this campaign different?
- It perfected the credential-harvest loop: Exfiltration was not the goal, it was a means to extract secrets from CRM data, then pivot into cloud and data platforms. That’s why the impact didn’t stop at Salesforce.
- It bypassed human-centric controls by design: OAuth tokens are NHIs. Once stolen, they authenticate as the app, so no MFA prompts and most user risk controls never trigger.
- It created just enough confusion to slow you down: The actor cleaned up the obvious traces (like saved query jobs), while leaving enough background noise to look like routine app traffic. Because the token authenticated as the app, attribution blurred and telemetry was fragmented across Salesforce, the integration, and identity provider (IdP).
- It forced a multi-SaaS response: Drift sat in the middle of multiple platforms, so one stolen grant became repeatable access across tenants and adjacent systems. Revoking in one plane didn’t kill access everywhere. That’s why this was the perfect campaign against NHI governance debt: ownerless connected apps, stale scopes, and inconsistent rotation turned a single OAuth theft into a multi-SaaS blast radius.
What most postmortems miss
Ownership debt: Under pressure, too many teams cannot answer: “Who owns this connected app or service account?” Without accountable ownership, revocation and rotation stall, and risky access creeps back in.
Token governance debt: OAuth grants age in place. Scopes drift. Session settings and IP policies rarely get revisited. Most teams cannot enforce maximum lifetimes or rotation SLAs for these NHIs.
Change-safe rotation: Rotation needs guardrails, who approves, what to test, how to roll back, and how to notify downstream consumers. Otherwise teams defer action during incidents because they fear outages more than risk.
How Oasis helps you close the loop
Below is how customers use Oasis today to respond to incidents like UNC6395 and to harden for the long term.
1) Detect and contain misuse with NHI-native ITDR
Oasis continuously monitors NHIs across on-prem, SaaS and cloud, automatically detecting patterns that signal compromise. For example, we can spot abnormal SOQL query volumes from a connected app, API activity from unexpected geographies, or token use outside normal hours/baselines, and leaked credentials (e.g., AKIA keys, Snowflake tokens, OAuth refresh tokens) turning up in exports or file stores. Scout, our ITDR engine, uses AuthPrint to profile and match activity against known adversary tactics, cutting noise and speeding triage. If your organization is affected by a campaign like the Salesloft Drift compromise, Oasis will automatically flag it and generate an alert in real time.
Why it matters here: The Salesforce exfiltration was API-centric and time-boxed. Traditional user-focused detections would miss it. With Oasis, organizations already have policy-driven monitoring tuned for NHIs. This means exfiltration attempts tied to OAuth tokens or connected apps are detected immediately and routed into automated containment workflows, such as revoking the token and rotating the associated Salesforce account secret.

2) Make ownership real and auditable
Oasis automatically proposes and assigns identity owners and runs ownership attestation campaigns over time. During response, you can see the accountable owner for each Salesforce integration, app, or service account and reach them with one click. That eliminates stalled revocations and “who owns this?” hunting in Slack threads.
3) Rotate Salesforce identities and connected credentials safely
Oasis provides policy-based secret rotation with change-safe guardrails. That includes Salesforce accounts and integration credentials. You can run on-demand rotation during incident response or enforce scheduled rotation long term, with approvals, test windows, and rollback plans that fit production realities. Oasis is vault-agnostic and identity-centric, so rotation respects where credentials actually live and who uses them.
Why it matters here: GTIG recommends revoking and rotating OAuth tokens and any secrets discovered in the exfiltrated data. With Oasis, you can automate that across environments with fewer outages and fewer manual steps.
4) Shift left so the next integration is secure by default
With Oasis NHI Provisioning, new NHIs are created with the right scopes, owners, and policies from day one, or as federated identities with no long-lived secrets at all. Our Outpost architecture performs privileged operations inside your perimeter, so secret generation and storage stay local. This prevents the next Drift-style trust path from becoming an evergreen backdoor.
A focused playbook you can apply now with Oasis
Triage and revoke
- Check impact in Oasis, open your incident view to see if your organization is already flagged. Oasis automatically detects and alerts if your tenant shows indicators of the Salesloft Drift campaign, including anomalous connected-app API activity and time-bounded query spikes tied to OAuth tokens.
- Revoke Drift access paths. In Salesforce, revoke the Drift connected-app/token for impacted orgs. In Google Workspace, confirm Drift Email tokens are revoked and review Admin/Token audit around Aug 9; re-authorize only if required.
- Pull the right Salesforce logs. Collect Event Monitoring (API, URI, Bulk API, ReportExport, ApexCallout) and Connected App OAuth Usage; inventory UniqueQuery events for Aug 8–18. If Salesforce is connected to Oasis, view these indicators in the Oasis context panel next to affected identities.
Hunt for secrets and blast radius
- Hunt for leaked credentials, search Salesforce objects for credential markers like AKIA (AWS), snowflakecomputing.com (Snowflake), and common secret keywords. Run a targeted scan using tools like TruffleHog against high-value exports.
- Use Oasis Secret Discovery. It monitors high-risk Salesforce data: ContentVersion (Files), EmailMessage, Case, FeedItem, for patterns like AWS keys, Snowflake tokens, OAuth refresh tokens, private key headers, and org login URLs. On a match, Oasis opens a trackable issue, links it to the right identity and owner, and provides one-click remediation.
- Bound the blast radius, cross-check IOCs including suspicious user-agents and Tor exit nodes in your logs to bound the activity set.
Rotate and harden
- Rotate with guardrails, run on-demand rotation workflows for affected Salesforce accounts and connected-app credentials. Workflows include approvals, test windows, automated notifications to owners, and rollback protections so you can move fast without breaking business processes.
- Turn on location guardrails, if the actor activity originated from restricted geographies, enforce location restrictions in Oasis and add conditional access controls to reduce recurrence risk.
Prove, prevent, and operationalize
- Attest ownership, launch ownership attestation for all Salesforce-connected apps and high-privilege service accounts so there is a named human on the hook for each identity going forward.
- Make secure the default, shift new integrations into Oasis NHI Provisioning so they inherit least-privilege scopes, ownership, and rotation policies by default. Use Oasis Outpost where needed so secret generation and storage stay inside your perimeter.
Why this approach stands apart
Most guidance stops at “revoke, rotate, review logs.” That is necessary but not sufficient. The Salesloft–Drift incident showed the real risk lives in the credential harvest loop and the governance debt around NHIs that lets tokens persist, scopes bloat, and ownership evaporate. Our view:
- Identity-centric detection is required to catch NHI abuse quickly. User-focused tools miss it.
- Ownership and lifecycle are security controls, not paperwork. They determine how fast you can respond.
- Safe automation for rotation across Salesforce and your broader stack is what closes the loop without breaking the business.
- Provisioning with policy prevents tomorrow’s trust chain from becoming yesterday’s breach write-up.
If you were touched by this campaign or just want to get ahead of the next one, we can help you stand up the above controls quickly, align owners, and automate the rotations and reviews that matter.
Request a demo to see how Oasis Security can help you with a campaign like the Salesloft Drift compromise.
We do newsletters, too
Discover tips, technical guides and best practices in our biweekly newsletter.





