Breaking down the Salesloft Drift OAuth breach

In August 2025, attackers exploited stolen OAuth tokens from the Drift–Salesloft integration to extract sensitive Salesforce data and credentials from hundreds of organisations, including some of the biggest names in tech. While the incident was shocking, it wasn’t surprising – and served as a wake-up call about the blind trust many organisations place in third-party integrations. The very shortcuts that make our apps work seamlessly together can, in the wrong hands, become an open backdoor.

In this blog, we’ll unpack what happened, how the attackers pulled it off, who was caught in the blast radius, and what steps your organisation should be taking now to avoid becoming the next supply chain cautionary tale.

Incident at a glance

In early August 2025, a threat actor tracked by Google’s Threat Intelligence Group (GTIG) as UNC6395 exploited compromised OAuth access and refresh tokens issued to the Salesloft–Drift integration, a third-party app connecting the Drift chatbot to Salesforce. These tokens allowed attackers to bypass standard authentication controls, including multi-factor authentication (MFA), and gain direct access to numerous Salesforce customer environments.

During the campaign, attackers leveraged OAuth tokens to query Salesforce objects and extract large volumes of customer data, with a particular focus on harvesting credentials such as AWS keys, Snowflake tokens, and plaintext passwords. Reports also indicate that steps were taken to reduce visibility of the activity, though core event logs continued to provide traces for forensic review.

This campaign followed a broader trend of OAuth-based attacks against Salesforce instances, including earlier incidents attributed to the ShinyHunters group, which leveraged voice phishing to trick employees into approving malicious integration, that affected companies such as Google, Cisco, Farmers Insurance, Workday, Adidas, Qantas, Allianz Life, and the LVMH subsidiaries among others.

The attack timeline: From exploitation to containment

• March through June 2025
  UNC6395 accessed the Salesloft GitHub account. With this access, the threat actor was able to download content from multiple repositories, add a guest user and establish workflows. The threat actor then accessed Drift’s AWS environment and obtained OAuth tokens for Drift customers’ technology integrations.

• 8-18 August: Persistent window of exploitation
  UNC6395 operated over a ten-day period using stolen OAuth tokens to systematically query and extract Salesforce customer data.
  

• 20 August
  Salesloft, in conjunction with Salesforce, revoked all active access and refresh tokens related to the Drift integration, and Salesforce removed the Drift app from the AppExchange.
  
  

• By 28 August
  Salesforce further disabled all integrations between Salesforce and Salesloft technologies.
  
  

• 28 August
  As investigations progressed, Salesforce disabled all remaining integrations with Salesloft technologies. On the same day, Google Cloud’s Threat Intelligence team confirmed that the breach extended to Drift Email for Google Workspace, leading Google to revoke compromised tokens and disable the integration.
  
  

• 1 September
  Zscaler confirmed it was among the organisations impacted by the Drift-related breach. Attackers had used stolen OAuth and refresh tokens to access its Salesforce instance, where they exfiltrated customer data including names, email addresses, job titles, product usage information, and related details.
  
  

• 7 September at 8:20PM
  Salesloft reported “that the integration between the Salesloft platform and Salesforce is now restored. Salesforce users can once again leverage the full capabilities and integrations of the Salesloft platform with confidence.”
  
  

How it went down

So what did the attackers go after? UNC6395 carried out a highly organised data exfiltration campaign by running SOQL queries against core Salesforce objects, including 'Cases', 'Accounts', 'Opportunities', and 'Users'. This allowed them to extract large amounts of sensitive data. Once the information was exported, the attackers attempted to cover their tracks by deleting Salesforce query job records, but the crucial event logs were left untouched.

In terms of data collected, the core focus was credential harvesting. The threat actor collected valuable credentials such as AWS access keys (AKIA), Snowflake access tokens, plaintext passwords, as well as other tokens that could enable access to critical systems.

The scope of the campaign was staggering. More than 700 organisations are believed to have been affected, cutting across industries and geographies. Several high-profile organisations, including Cloudflare, Palo Alto Networks, and Tanium, have publicly confirmed their exposure. For companies like these, which are trusted to secure the digital backbone of other organisations, the breach emphasises not only the direct risks but also potential knock-on effects it could have across their client base. The full impact is still to be determined, and a dedicated website, driftbreach.com, has been set up to list companies that have publicly disclosed their connection to the Drift Breach.

Recommended actions

At KYND, we’ve already identified potential exposure to this type of vulnerability across our clients’ and partners’ environments, which shows just how widespread the risk can be. That’s why, to help limit the impact of the Salesloft Drift breach and to strengthen defences against similar threats, we strongly recommend organisations take the following steps:

1. Immediate containment

• Revoke and rotate credentials: Immediately revoke and reissue all Drift-related OAuth tokens and API keys. Rotate any credentials potentially exposed in Salesforce, including passwords, AWS access keys, Snowflake tokens, and other secrets.
  
  

• Disable or re-authenticate drift integrations: Remove or re-authenticate the Drift–Salesforce integration after revocation. Consider suspending use until security assurances are in place.
  
  

2. Detection and investigation

• Review logs thoroughly: Analyse Salesforce logs, audit trails, and Event Monitoring data from 8 August 2025 onward. Pay close attention to:
  

  • Unusual SOQL “UniqueQuery” activity

  • Query job deletion records

  • Suspicious authentication patterns or unexpected user-agent strings
    
    

• Search for exposed secrets: Use tools such as Trufflehog to scan Salesforce and other connected SaaS platforms for leaked credentials (e.g. AKIA, Snowflake, password, secret, key).
  
  

3. Strengthen technical controls

• Harden connected apps: Apply least-privilege principles to Salesforce apps by:
  

  • Restricting app scopes to minimal permissions

  • Enforcing IP restrictions for connected apps

  • Removing “API Enabled” from broad profiles and granting API access only via targeted Permission Sets
    
    

• Enhance monitoring: Deploy centralised logging and real-time monitoring for OAuth token use, API calls, and third-party integrations to detect anomalies quickly.
  
  

4. Broaden the response

• Extend beyond salesforce: Review and secure other Drift integrations, including email or collaboration tools such as Google Workspace. Monitor for abnormal activity across your wider SaaS ecosystem.
  
  

• Engage incident response support: If compromise is suspected, work with a trusted incident response provider for forensic analysis and remediation.
  
  

5. Build long-term resilience

• Strengthen access controls: Enforce multi-factor authentication universally and apply least-privilege access across all SaaS integrations.
  
  

• Assess supplier risk: Evaluate the security posture of third-party vendors to understand and mitigate supply chain risk.
  
  

• Educate employees: Provide regular training to help staff recognise phishing and social engineering attempts, which remain a common entry point for OAuth token theft.
  
  

Final thoughts

The lesson from this incident is clear: OAuth tokens, by design, can sidestep MFA, which makes them a high-value target when compromised. In a world where third-party integrations are deeply woven into daily operations, that weakness can quickly turn into broad lateral movement across an enterprise’s entire SaaS estate. This makes it essential to focus on the fundamentals: centralised logging, real-time monitoring of OAuth activity, and the ability to revoke tokens quickly. Just as important is prevention – limiting OAuth permission scopes, enforcing IP controls, and stripping integrations back to the minimum they need. Taken together, these steps can help effectively reduce the risk of another integration turning into an attacker’s backdoor.