Salesloft Drift Breach: Lessons on SaaS Security Risks

In late August, the tech world was shaken by a significant security incident involving the popular chatbot platform, Salesloft Drift. This event wasn’t just another data breach; it was a sophisticated supply chain attack that impacted hundreds of companies, from major tech firms to cybersecurity leaders. By exploiting a single integration, attackers managed to access sensitive corporate data on a massive scale. This post unpacks the Salesloft Drift breach, pulling from threat intelligence reports to understand what happened and what it means for SaaS security.

Why is this attack making headlines?

The Salesloft Drift breach is making headlines due to its significant impact on data security within SaaS platforms. This incident exposed sensitive customer information, raising concerns about vulnerability in cloud services and prompting discussions on the importance of robust cybersecurity measures to protect user data effectively.

The Salesloft Drift Breach Unpacked

The Salesloft Drift breach was a widespread data theft campaign where a threat actor exploited a vulnerability in the Drift application’s integration with other platforms. At its core, the attackers stole authentication tokens, which act like digital keys, allowing them to access the Salesforce instances of Salesloft’s customers.

Once inside, they systematically exported large volumes of sensitive information. Threat intelligence from Google suggests the primary goal was to harvest credentials, searching through the stolen data for secrets like API keys and passwords. This quiet, large-scale data harvesting campaign is what made the breach so impactful.

Background on Salesloft and Drift Integration

So, what are Salesloft and Drift? Drift, an AI chatbot agent acquired by Salesloft, is a popular tool for sales and marketing teams. Its main job is to engage website visitors and convert them into sales leads. To do this effectively, the Drift application integrates with many other business tools.

These third-party integrations are what make platforms like Salesloft Drift so powerful. By connecting to a company’s Salesforce CRM, for example, the chatbot can create new leads, log conversations, and streamline workflows. This connection is typically authorized using a standard called OAuth, which allows applications to share data without sharing your password.

However, this convenience comes with risks. When you connect two platforms, you create a new potential entry point for attackers. If one of the integrated platforms is compromised, the attacker may be able to use the trusted connection to access the other, highlighting the inherent dangers of a deeply interconnected SaaS ecosystem.

Discovery and Timeline of the Security Incident

The timeline of this security incident reveals a patient and methodical attacker. According to threat intelligence, malicious activity began as early as August 8th. For about ten days, the threat actor remained active, using their access to run queries and export data from Salesforce, including details from support cases.

The wider world became aware of the issue on August 20th, when Salesloft and Salesforce took the drastic step of disabling all Drift integrations globally. This action halted the attacker’s activity but also caused service disruptions for customers. Notifications to affected organizations began rolling out between August 26th and 29th, as the full scale of the compromise became apparent.

Companies like Cloudflare, PagerDuty, and Zscaler later published their own findings, confirming they were impacted and detailing their response efforts. This collaborative sharing of information helped piece together the full picture of this widespread attack.

How the Breach Happened

This breach happened because a threat actor successfully compromised authentication tokens associated with the Salesloft Drift application. These tokens, specifically OAuth tokens, were the keys that gave the Drift chatbot permission to interact with other platforms, like Salesforce.

Once the threat actor had these tokens, they could impersonate the legitimate Drift integration and gain access to the Salesforce environments of hundreds of companies. Security researchers noted that this is a classic example of a supply chain attack, where attackers don’t target a company directly but instead go after a trusted third-party vendor to infiltrate their ultimate target’s systems.

Attack Methods Used by Threat Actors

The threat actor, tracked as UNC6395 by Google’s Threat Intelligence Group, employed a focused strategy. The core of this supply chain attack revolved around the theft and abuse of OAuth tokens and refresh tokens from the Drift–Salesforce integration. This gave them unauthorized access to execute their campaign.

Instead of deploying ransomware, the attacker’s main goal was quiet data harvesting. They used the stolen access tokens to run queries within their victims’ Salesforce environments, systematically exporting customer relationship management (CRM) data. Their methods included:

• Enumerating Salesforce Objects: They first explored the data structure by listing available objects like “Case,” “Account,” and “User.”
• Executing SOQL Queries: The actor ran Salesforce Object Query Language (SOQL) queries to pull specific data, such as user details and case information.
• Searching for Secrets: After exfiltrating the data, they searched through it for valuable credentials like AWS access keys and passwords.

This approach allowed the threat actor to remain undetected for over a week while stealing massive amounts of data from hundreds of organizations.

Link to GitHub Account Compromise

The investigation into this security issue uncovered an even earlier point of failure. On September 8th, Salesloft revealed that the August breach was made possible by a prior compromise of its GitHub account. This initial hack occurred months earlier, between March and June.

During that period, hackers accessed Salesloft’s GitHub repositories, downloading content and establishing workflows. This unauthorized access allowed them to steal authentication tokens, including API keys and OAuth credentials, which were stored within the account. These were the same credentials later used to access Salesloft’s Drift platform and, subsequently, its customers’ connected applications.

The significant delay between the GitHub compromise and its discovery has raised concerns about the security posture and detection capabilities surrounding code repositories. This link demonstrates how a security issue in one area can cascade into a much larger, more damaging incident months down the line.

Data and Systems Impacted

The breach had a wide-ranging impact, affecting both the data stored within SaaS platforms and the systems connected to them. Because the attackers gained access via compromised tokens, they were able to pull a significant amount of Salesforce data from hundreds of organizations.

This wasn’t limited to just one type of information. The exfiltrated data included a mix of general customer information and, in some cases, highly sensitive information. The compromised systems extended beyond Salesforce, with a ripple effect on other platforms like Google Workspace that were also integrated with Drift.

Types of Data Compromised

The attackers targeted and successfully exfiltrated a variety of data types, primarily from Salesforce case objects. These objects are used for customer support and internal case management, meaning they contain a wealth of information. The compromised data ranged from basic contact details to potentially very sensitive data.

Most of the stolen information consisted of customer contact information and the contents of support tickets. This included names, emails, and phone numbers. However, a more serious risk emerged from the free-form text fields within support case data. Customers sometimes share credentials, logs, or API keys in support tickets for troubleshooting, and this sensitive data was also compromised.

Here is a breakdown of the types of data exposed in the breach:

Effect on Salesforce Instances and Other Platforms

The primary impact was on the Salesforce instances of Salesloft’s customers. The attackers used the stolen OAuth tokens to directly access and query Salesforce objects within these corporate environments. They systematically exported data from objects like “Cases,” “Accounts,” and “Users” from numerous Salesforce customer instances. Companies like Palo Alto Networks, Zscaler, and Cloudflare all confirmed their Salesforce tenants were accessed.

The impact wasn’t contained to just Salesforce. Google’s Threat Intelligence Group later confirmed that the threat actor also compromised OAuth tokens for the “Drift Email” integration. Using these, they accessed emails from a minimal number of Google Workspace accounts that were configured to integrate with Drift.

This shows how a single point of compromise can create a domino effect. The attackers used their initial foothold to pivot and access other integrated platforms, thereby expanding the breach’s blast radius and increasing the risk to additional systems and data.

Risks Posed by Third-Party SaaS Integrations

The Salesloft Drift incident is a powerful lesson in the risks of third-party SaaS integrations. While these connections boost productivity, they also expand your organization’s attack surface. Every time you authorize an application to access your data, you are trusting that vendor’s security.

This event was a textbook supply chain attack. The attackers didn’t need to breach hundreds of companies individually; they just needed to compromise one popular integration. The theft of OAuth tokens from Drift integrations gave them a master key to unlock a treasure trove of data across the entire customer base, demonstrating how interconnectedness can multiply risk.

Common Vulnerabilities in SaaS Ecosystems

The SaaS ecosystem, for all its benefits, has common vulnerabilities that threat actors are eager to exploit. This breach highlighted several weak points that are unfortunately widespread. A major issue is the failure to enforce the principle of least privilege. Integrations are often granted overly broad permissions, giving them access to more data than they actually need to function.

Another vulnerability is the improper handling of secrets like API keys and authentication tokens. When these are stored insecurely or are never rotated, they become a prime target. If an attacker gets their hands on a long-lived token, they can maintain access for an extended period.

Common vulnerabilities include:

• Overly Permissive Scopes: Granting applications “full access” when only specific permissions are needed.
• Storing Sensitive Information: Embedding secrets like passwords or API keys in places like CRM notes or support tickets.
• Lack of Credential Rotation: Failing to regularly rotate API keys and tokens increases the window of exposure.
• Insufficient Monitoring: Not having visibility into the activity of third-party integrations.

Understanding 4th-Party and Supply Chain Risks

This supply chain attack introduces a concept that security teams are increasingly worried about: 4th-party risk. Most organizations are familiar with 3rd-party risk—the risk posed by a direct vendor like Salesloft. However, 4th-party risk is the risk introduced by your vendor’s vendors. In this case, the Drift application was a 3rd party, but the attackers compromised it through a 4th party: GitHub.

The breach of Salesloft’s GitHub account is what enabled the subsequent attack on the Drift application and its customers. Your company may not have a direct relationship with GitHub, but your security is still dependent on how well your vendor (Salesloft) secures its assets on that platform.

The Salesloft Drift breach revealed that your security perimeter doesn’t end with your direct vendors. It extends to their entire supply chain. This makes it incredibly difficult to manage risk, as you have very little visibility or control over the security practices of these 4th-party entities.

Response and Recovery by Organizations

The response to the breach was swift and multifaceted. Once the threat was identified, Salesloft and Salesforce took the immediate step of disabling all Drift integrations to cut off the attacker’s access. Following this, security teams at affected companies launched their own incident response and remediation efforts.

Organizations like Cloudflare, PagerDuty, and SpyCloud publicly disclosed their impact and outlined their recovery plans. Based on shared threat intelligence, these efforts focused on containing the threat, understanding the scope of the data exposure, and protecting customers from further harm. The collaborative response was crucial in managing the fallout from this widespread incident.

Immediate Actions Taken by Cloudflare, SpyCloud, and Others

Leading companies impacted by the breach took decisive action to contain the threat. For example, Cloudflare launched a full security incident response, bringing together experts from security, IT, and legal teams. They immediately disconnected all third-party integrations from their Salesforce instance, not just Drift.

Similarly, PagerDuty deactivated the integration between Salesforce and Drift and began reviewing affected support case data. SpyCloud also confirmed its impact and began containment measures. The Google Threat Intelligence Group played a key role by providing crucial indicators of compromise that helped security teams hunt for malicious activity in their environments.

Immediate actions taken by these organizations included:

• Disconnecting the Compromised Integration: All Drift connections were disabled to cut off attacker access.
• Rotating Credentials: Companies revoked and rotated API keys and secrets for all third-party applications connected to Salesforce.
• Conducting Forensic Analysis: Security teams analyzed logs to understand the attacker’s activities and the extent of data exfiltration.
• Notifying Customers: Impacted customers were informed about the breach and advised on steps to take, such as rotating any credentials shared in support tickets.

Long-Term Remediation and Security Enhancements

Beyond the immediate crisis, affected organizations are now focusing on long-term remediation and security enhancements to prevent similar incidents. A key lesson is the need for more rigorous management of third-party integrations. This isn’t a one-time fix but a continuous process of vigilance.

Security teams are implementing stricter policies for all integrated applications. This includes establishing regular schedules to rotate credentials, such as API keys and tokens, to reduce the window of exposure if a secret is compromised. Cloudflare, for instance, has implemented a new process to rotate secrets for its services weekly.

Furthermore, companies are reassessing the permissions granted to third-party apps. The goal is to enforce the principle of least privilege, ensuring applications only have the minimum level of access required for their function. This long-term remediation work is essential for building a more resilient SaaS security posture.

Essential Steps to Strengthen Integration Security

Strengthening your integration security requires a proactive and multi-layered approach. You can’t just set up an integration and forget about it. Assuming that any third-party app could be compromised is the first step toward a more secure posture.

Start by auditing all your existing integrations. Do you know every application that is connected to your critical systems, like Salesforce or Google Workspace? For each one, you should scrutinize the permissions it has. OAuth tokens should not be granted with overly permissive scopes like “full access.” Enforce the principle of least privilege to ensure apps can only do what is necessary.

Here are some essential steps you should take:

• Implement Frequent Credential Rotation: Establish a regular schedule to rotate credentials, including all API keys and authentication tokens.
• Enforce Least Privilege: Review and restrict the permissions (scopes) of all connected apps to the minimum necessary.
• Enhance Monitoring: Deploy tools to monitor the activity of third-party integrations for anomalies, like large data exports or logins from unusual locations.
• Define IP Restrictions: Where possible, restrict access for connected apps to only trusted IP ranges.

Conclusion

The Salesloft Drift breach serves as a crucial reminder of the vulnerabilities inherent in SaaS integrations and the importance of proactive security measures. As we unpack the lessons learned from this incident, it’s clear that awareness and responsiveness are essential in mitigating risks associated with third-party services. Organizations must prioritize regular security audits, employee training, and the adoption of robust security protocols to safeguard their data and systems. By staying informed and taking the necessary steps to enhance security, companies can better protect themselves against potential breaches. If you have further questions or need assistance in fortifying your SaaS security, don’t hesitate to get in touch!

Frequently Asked Questions

How can companies detect similar SaaS breaches early?

Early detection of a SaaS breach requires enhanced monitoring and proactive threat intelligence. Security teams should closely watch for unusual activity related to third-party integrations, such as large data exports or logins from unfamiliar IPs. Monitoring the usage of authentication tokens is a critical part of discovering a security issue before it escalates.

What security measures should be prioritized post-breach?

Post Salesloft Drift Breach, the top remediation priority is to contain the threat and prevent further damage. Companies must immediately rotate credentials, including all compromised API keys and OAuth tokens. Following that, they should enforce the principle of least privilege on all integrations and conduct a thorough security audit to identify and fix vulnerabilities.

How does such a breach affect platforms like Google Workspace?

A breach like this can affect platforms such as Google Workspace if the compromised application had integration permissions. In this case, the stolen authentication tokens allowed the threat actor to gain unauthorized access to the emails of a small number of Google Workspace accounts, demonstrating how the blast radius can extend beyond the initial point of entry.

Zachary McGraw

Zak McGraw, Digital Marketing Manager at Vision Computer Solutions in the Detroit Metro Area, shares tips on MSP services, cybersecurity, and business tech.