When Integrations Become Infiltrations: What the Salesloft Drift Breach Reveals About SaaS Risk 

When integrations become attack vectors 

In August 2025, attackers infiltrated Salesforce environments by hijacking OAuth tokens from integrations with Salesloft — including its subsidiary Drift — two widely used sales engagement platforms. The breach impacted multiple organizations, including Zscaler and Palo Alto Networks, and exposed sensitive customer data without triggering traditional security alerts. 

According to Zscaler’s incident report, attackers gained access to OAuth tokens stored in Salesloft’s infrastructure and used them to impersonate Salesforce integrations. These tokens were valid and scoped for broad access, allowing attackers to query sensitive objects like Account, Opportunity, User, and Case — without breaching Salesforce directly.  

In other instances, the attackers abused integrations with Google Workspace, demonstrating how trusted SaaS connections can become high-impact attack vectors across multiple platforms. 

The expanding blast radius of SaaS 

SaaS platforms like Salesforce, Google Workspace, and Microsoft 365 are deeply interconnected with third-party apps. Each integration expands the blast radius, which is the scope of damage an attacker can inflict with a single compromised identity or token. 

In this case, the attackers didn’t need to compromise Salesforce directly. They hijacked OAuth tokens from Salesloft and Drift integrations — tokens already granted access to Salesforce data. These tokens were likely stolen via the recent UNC6395 phishing campaign. Once inside, they used legitimate API calls to extract sensitive records. 

This wasn’t a Salesforce vulnerability. It was a supply chain attack that exploited trust in a third party.

How the attack worked 

The attackers used a multi-step approach: 

Compromise the OAuth token: The attackers obtained OAuth tokens from Salesloft and Drift integrations. A recent phishing campaign is suspected to be the source of these compromised OAuth tokens, but we do not know for sure.

Use the token to access Salesforce APIs: With the token in hand, the attackers made legitimate API calls to Salesforce endpoints, which were indistinguishable from regular integration traffic. Unlike username/password auth, API tokens don’t require a second factor, so MFA is out of scope.

Enumerate the environment: Before exfiltrating data, the attackers ran reconnaissance queries to understand the scope of available data. These included:

	
		
*
SELECT COUNT() FROM Account; 
SELECT COUNT() FROM Opportunity; 
SELECT COUNT() FROM User; 
SELECT COUNT() FROM Case; 
	

These queries are standard Salesforce Object Query Language (SOQL) calls. They don’t raise alarms in most environments because integrations and internal tools commonly use them. But in this context, they were used to map out the data landscape before exfiltration. 

Exfiltrate sensitive data: The attackers targeted standard objects like Lead, Contact, and Account, and custom objects unique to each breached company’s Salesforce organization, extracting fields such as names, emails, phone numbers, and other PII. 

Avoid detection: Traditional security tools didn’t flag the activity as suspicious because the access came from trusted integrations. 

The technique of using OAuth tokens to impersonate integrations is increasingly common. It bypasses MFA, avoids login alerts, and blends into regular traffic. 

How to protect your Salesforce organization today 

While Salesforce itself wasn’t vulnerable, the breach exposed how easily trust in integrations can be abused. Fortunately, Salesforce allows admins to harden and limit access for third-party OAuth applications. When installing a new app, admins can enforce policies that restrict which users can grant permissions on behalf of the organization. 

For integrations not intended for employee use, such as backend connectors, we recommend creating a dedicated user with scoped permissions and limiting access to that user alone. If possible, restrict the IP range from which the application can connect.  

In the case of the Drift application, had Salesloft provided its IP range and enforced restrictions, the attacker’s job would have been significantly more challenging. 

As of September 2, Salesforce now requires new OAuth applications to be installed with policies in place before they can be used — a critical step toward reducing integration risk. 

Automatically remediate user risk with Varonis for Salesforce.

Get your assessment

Protect data first, not last 

This breach is a case study in modern SaaS risk. It shows that: 

• Integrations are attack vectors 
• Sensitive data is always the target 
• Perimeter defenses are no longer enough 

The goal isn’t just to detect threats; it’s to reduce the blast radius before the next login becomes the subsequent breach. 

The trend is clear: attackers are bypassing the endpoint entirely. Breaches like this don’t involve EDR-controlled systems or network connections that route through a CASB/SSE. These threat actors are operating purely in the cloud.  

Instead of trying to drop malware on a heavily monitored computer, they’re exploiting trust relationships, identities, tokens, and APIs. 

To defend against integration-based breaches, organizations must shift from perimeter-first to data-first security.  

How Varonis helps

Varonis offers extensive coverage for SaaS apps, from Salesforce to M365, Google Workspace, and more. You can view our full coverage list here.

We employ a preventative approach, combining DSPM and SSPM to continuously detect any posture issues or overly permissive access that could expose sensitive data.

We can identify, flag, and even automatically fix some SaaS-related risks. Many of these concerns are related to third-party app risks.  

We can identify dozens of Salesforce-specific configuration risks and toxic combinations immediately upon connecting Varonis for Salesforce. 

Varonis doesn’t just alert you to posture issues by opening ServiceNow or Jira tickets (you can do that, by the way); it remediates them. You can configure remediation actions to fit your needs. They can be done as one-time actions, on a schedule, or continuously. Broadly, our remediations cover actions such as: 

• Revoking excessive permissions 
• Removing risky third-party apps 
• Disabling stale accounts 
• Deleting redundant, obsolete, and trivial (ROT) data 

For each SaaS application we connect to, we analyze which third-party apps are connected, their access levels, what types of sensitive data those apps can view, modify, or delete, and what the application (and its users) are doing. 

Automatic blast radius reduction

In addition to remediating misconfigurations, we help enforce least privilege for human users, OAuth applications, and AI agents. 

In the case of Salesloft Drift, many customers likely have a stale OAuth token. They no longer use Drift but have left the attack vector open. Varonis can identify stale third-party app connections and auto-remediate them without impacting users. 

Even if a third-party integration is actively being used, Varonis can help ensure that the permissions are right-sized by comparing the granted permissions to those used. In doing so, you limit the scope of the damage that can be done in case of a breached token. 

Context-aware detection of abnormal access 

In addition to the preventative measures mentioned above, Varonis monitors and analyzes all activity across SaaS apps and their connected IdPs and looks for abnormal behavior. 

We can detect threats that perimeter tools miss because we’re ingesting all of the SaaS and IdP logs. We flag integrations that query objects they’ve never touched, spike access volumes, or use OAuth tokens suspiciously — like the enumeration pattern seen in the Zscaler breach (SELECT COUNT() across multiple Salesforce objects). 

This isn’t just anomaly detection. Data-aware threat detection understands what regular data access is and what is not. 

Here are some examples of UEBA threat models built into Varonis that could help detect a compromised OAuth token, insider threat, and other hard-to-detect behavior: 

• Abnormal behavior: excessive access to different Salesforce records 
• Abnormal behavior: OAuth application access from an anonymous network (VPN/Tor) 

Real-time sensitive data classification 

To protect your sensitive data, you need to know what you have. Some organizations don’t fully understand which SaaS app instances exist, what they’re used for, or if they contain sensitive information that could be targeted.

Varonis automatically discovers and classifies sensitive data across SaaS platforms like Salesforce, Google Workspace, and Microsoft 365. We don’t sample or scan periodically; we continuously monitor with 98% classification accuracy for structured and unstructured data.

This gives security teams a real-time map of where sensitive data resides, who can access it, and how exposed it is — even as permissions, integrations, and usage patterns change.

This is especially useful for identifying test and development instances containing real customer data that should be deleted or protected at all costs, just like production.  

Free Salesforce Risk Assessment 

The Varonis team of security experts is here to help if you've been impacted by this breach or if you just want to ensure your Salesforce data is secure. 

Reach out for one of our free Salesforce Data Risk Assessments which are designed to not only give you a summary of your data security risks, but also provide actionable recommendations for simpler, safer permission structures.