COMMENTARY: The Salesloft OAuth compromise in August 2025 was not just another entry in the long list of security incidents making headlines. It revealed an uncomfortable truth about modern enterprises: attackers are adapting faster than most organizations are refining their defenses, particularly when it comes to non-human identities.These are the tokens, apps, and service accounts that keep business systems connected and functioning. They are invisible in day-to-day operations, yet when stolen, they provide a direct path into critical platforms.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]Understanding this incident requires looking beyond the surface. It was not a vulnerability in Salesforce or Google Workspace. Rather, it was an abuse of OAuth tokens, a form of non-human identity. Once stolen, these tokens let attackers impersonate trusted applications, query data at scale, and harvest secrets to fuel further compromise. Because traditional defenses focus on human users, the campaign sidestepped the usual barriers like multi-factor authentication (MFA) or user-based anomaly detection.The Salesloft incident demonstrates that attackers are increasingly targeting the connective tissue of enterprise operations: non-human identities. Traditional security controls built around people are not enough.Organizations need to embed ownership and accountability into every integration, enforce strict lifecycle management for tokens and credentials, and normalize safe rotation practices so that incidents do not trigger panic or downtime. Most important, security teams must begin treating non-human identities as first-class citizens within their identity and access management strategies.Teams should not just revoke and rotate in response to an active threat, but prepare in advance. Make governance, monitoring, and lifecycle controls for non-human identities fundamental to enterprise security. Organizations that embrace this approach are better positioned to detect, contain, and recover quickly when the next OAuth compromise inevitably arrives.Danny Brickman, chief executive officer, Oasis Security SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
What happened
In early August, a threat cluster tracked as UNC6395 stole OAuth tokens tied to Salesloft’s Drift integrations. Using these tokens, they gained entry to Salesforce and then to Google Workspace accounts connected through Drift Email. Indicators suggest other integrations were also exposed. With this access, attackers ran bulk queries and exfiltrated data while searching for credentials that could expand their foothold.By Aug. 20, Salesloft and Salesforce had revoked Drift tokens, Salesforce removed the app from AppExchange, and Salesforce integrations with Slack and Pardot were temporarily disabled. Later, Google revoked the specific Drift Email tokens and disabled that integration. The actions contained the immediate threat, but the broader lessons remain urgent.What made this campaign different?
The attackers perfected the credential-harvest loop. Data was not the final prize, but a means to discover additional secrets embedded in CRM systems. This let them pivot into cloud and data platforms, extending the blast radius beyond the initial entry point.They bypassed human-centric controls. OAuth tokens authenticate as the application itself. Once stolen, they do not trigger MFA prompts or user-based risk policies.They blurred attribution and slowed response. The attackers cleaned up obvious traces, like saved query jobs, while leaving enough background activity to appear normal. Because authentication was tied to the app rather than an individual, evidence was scattered across Salesforce, integration logs, and identity providers, delaying detection.They forced a multi-SaaS response. Drift acted as a bridge between multiple systems. Revoking access in one environment did not automatically sever access in others. This amplified the impact of what began as a single token theft.What most postmortems miss
Many after-action reviews focus narrowly on revoking tokens and reviewing logs. Those steps are necessary, but they do not address the underlying issues that make these attacks so effective.Ownership debt has become one of the biggest blind spots. Too many organizations cannot quickly answer the question of who owns a connected app or service account. Without a clear owner, revocation stalls and risky access reappears over time.Token governance debt presents another challenge. OAuth tokens often live far longer than they should, with permissions that grow over time. Few organizations enforce expiration dates or rotation schedules, leaving these tokens as lingering vulnerabilities.Change-safe rotation frequently gets overlooked. Teams hesitate to rotate credentials during incidents because they fear outages. Without defined guardrails for approvals, testing, rollback, and notifications, rotation feels risky. This hesitation leaves attackers with more time to operate.Best practices that matter now
Organizations that rely on Salesforce, Google Workspace, or other integrated platforms cannot afford to treat non-human identities as an afterthought. A few best practices stand out:- Investigate for compromise: Review authentication logs, API activity, and unusual query behavior tied to Drift or OAuth grants. Look specifically for traffic originating from Tor exit nodes or suspicious user-agents.
- Hunt for exposed secrets: Search CRM records and file storage for leaked credentials such as AWS keys, Snowflake tokens, or OAuth refresh tokens. Tools like TruffleHog can assist, but targeted keyword searches and log reviews are equally important.
- Revoke and rotate credentials: Revoke all Drift-related tokens and rotate any exposed keys or passwords. Reset associated user accounts and enforce shorter session lifetimes to limit exposure.
- Harden access controls: Restrict connected app scopes to the minimum necessary permissions, enforce IP restrictions where possible, and review profiles to ensure the “API Enabled” permission gets granted only when required.
