Salesforce OAuth incident: safe re-enable path for Drift and Salesloft, How To Fix

maya933
Sep 9
2 min read

A clean, safe re-enable path for Drift and Salesloft

Attackers stole OAuth tokens tied to the Salesloft Drift integration, then used those valid tokens to call Salesforce APIs and export data. This is token abuse via a third-party Connected App, not a core Salesforce bug. Focus your response on governance and validation: revoke and rotate, re-enable with least privilege, and use Salesforce Event Monitoring to verify detections.

What happened

Aug 28, 2025: Salesforce disabled the connection between the Drift app and Salesforce for customers, and clarified the issue did not arise from a Salesforce platform vulnerability.
Sep 2, 2025: Unit 42 published actionable guidance for potentially affected Salesforce environments, including Event Monitoring hunting cues and query patterns.
Sep 7, 2025: Salesloft reported the Salesforce integration was restored.
Google’s team attributed activity to UNC6395 and described OAuth token abuse and response steps.

Why it matters

SaaS-to-SaaS tokens can carry broad scopes and allow API calls without an interactive login or MFA challenge. In Salesforce this lets a Connected App reach data directly. Reduce risk by enforcing least privilege, and verify that Event Monitoring and your alert rules detect and notify on unusual API use and bulk exports.

Snapshot actions for Salesforce admins

Each action includes one breadcrumb so your team knows where to click, plus an official doc where helpful.

Scope: inventory who is using what
- Breadcrumb: Setup → Connected Apps OAuth Usage. Review app entries, click Manage App to view policies and active users. Identify Drift and Salesloft, surface unknown apps for removal or explicit approval.
Revoke: remove risky authorizations and rotate secrets
- Breadcrumb: On the User Detail page, under OAuth Connected Apps, choose Revoke. For scripted or bulk revocation, call the endpoint https://{MyDomainName}.my.salesforce.com/services/oauth2/revoke. Rotate API keys and secrets for affected integrations.
Patch: no SaaS patch applies, enforce least privilege and controlled re-enable
- Breadcrumb: Manage Connected Apps, set Permitted Users: Admin approved users are pre-authorized, restrict scopes, and apply policies like session timeout or high-assurance sessions where appropriate.
Detect: hunt for suspicious queries and bulk exports
- Breadcrumb: Event Monitoring → EventLogFile. Pull API and BulkApi events, correlate to the integration user, look for unusual time windows, large exports, and distinctive query patterns, for example UniqueQuery spikes. Use the Unit 42 patterns to prioritize.

Validation, not just configuration

Configuration without proof leaves gaps. After tokens are revoked and scopes tightened, validate two things.

Safe re-enable really works. The app functions with least-privilege scopes and pre-authorized users, no unnecessary grants.
Detections actually trigger. Event Monitoring captures Bulk API or unusual SOQL activity and cannot be trivially evaded by the integration user. Test with Unit 42’s cues, then tune alerts.

Compliance lens

This is an ICT third-party and supply-chain governance issue. The actions above map directly to DORA and NIS2 oversight of third-party access and incident-response validation, and align with SOC 2, ISO 27001, and HIPAA controls for vendor access, least privilege, and monitored data egress. Your evidence package should include revocation records, updated Connected App policies, and Event Monitoring queries and results tied to the re-enable decision.