The recent security incident involving Salesloft has highlighted the importance of robust cybersecurity measures to counter supply chain attacks. This document provides an overview of what happened in the Salesloft supply chain attack targeting Salesforce, elaborates on what should we know about supply chain vulnerabilities, and outlines how Netskope SSPM can contribute in preventing such attacks from happening in the first place.

What is Salesloft?

Salesloft is a Revenue Orchestration Platform which supports the utilization of the Drift AI chat agent to integrate with corporate applications like Salesforce. The Salesloft Git repositories were the initial component compromised, where improperly stored secrets allowed the threat actor to gain access to the vendor infrastructure where they were able to pivot into the OAuth tokens used to integrate with Salesforce. This access was valuable because the integration required permissions to read sensitive data—such as customer records and credentials—from numerous downstream Salesforce customer instances, making the platform an attractive target for a supply chain attack.

How the Salesloft Attack Happened

The Salesloft security attack tracked as UNC6395 (a designation used by Mandiant/Google) was a multi-stage supply chain attack that leveraged unmonitored SaaS-to-SaaS integrations and exploited the trust between connected software. The attackers used Salesloft Drift to steal data from Salesforce.

The process for the attack:

1. Initial Access and Reconnaissance (March – June 2025)

Compromising GitHub: The attack began with the initial compromise of one of Salesloft's internal GitHub accounts.. The attackers downloaded content from multiple code repositories to analyze for embedded secrets and performed reconnaissance activities within the Salesloft and Drift application environments. They also added a guest user and established automated workflows to ensure long-term persistence.

Harvesting the Master Key: The attackers claim they harvested a hardcoded sensitive credential from the GitHub repository content. This key granted them privileged access to Salesloft’s own cloud infrastructure.

2. The Pivot to the Supply Chain (August 2025)

Access to Cloud Environment: Using the credential stolen from GitHub, UNC6395 gained unauthorized access to the Drift Amazon Web Services (AWS) environment.

Theft of Customer OAuth Tokens: Once inside the Drift environment, the attackers successfully stole OAuth access and refresh tokens that belonged to Drift's customers. These tokens are the "digital keys" that allow the Drift chat application to connect to and access data in the customers' integrated applications, such as Salesforce and Google Workspace.

3. Data Exfiltration and Credential Harvesting (August 8 – 18, 2025)

Bypassing MFA and Logging In: The stolen OAuth tokens were used to log in and make API calls to the victims’ environments (e.g., Salesforce). Crucially, these tokens bypass traditional authentication like passwords and Multi-Factor Authentication (MFA), seemingly making the malicious activity appear as legitimate, authorized access by the Drift application.

Bulk Data Exfiltration: The attackers then executed high-volume SOQL queries (Salesforce Object Query Language) and leveraged the Salesforce Bulk API to systematically export large datasets, focusing on standard Salesforce objects like Cases, Accounts, Contacts, and Opportunities.

The attack was eventually halted when Salesloft and Salesforce, upon discovering the activity, took action to revoke all active OAuth access and refresh tokens associated with the Drift application globally. However, by the time this corrective action was completed, the threat actor had successfully exfiltrated massive volumes of sensitive customer data and credentials.

The Reality of SaaS Supply Chain Attacks

The growth of SaaS has created an interconnected digital economy built on a foundation of trust. Organizations connect dozens, often multiple, of third-party applications—from marketing tools to HR platforms—to their core systems like CRM and email, trusting that these vendors maintain adequate security practices to protect both their own infrastructure and their customers' data. Supply chain attacks are not only a nuisance service providers need to defend against on behalf of their customers, but which can also exploit the trust these customers grant to their third-party vendors.

When an organization grants a third-party application access to its systems, it issues OAuth tokens or other kinds of API credentials that enable the integration to perform its intended functions. These tokens are scoped to provide access only to the specific data and capabilities needed by the vendor—such as reading contact records or syncing calendar events. However, when these tokens are stolen, attackers gain the same limited but legitimate access that was delegated to the vendor. The stolen credentials allow attackers to bypass authentication controls by masquerading as the trusted application itself, accessing whatever data the token permits—which, while limited, can still include sensitive customer information, financial records, or business intelligence.

The resulting data breach represents an inherited compromise, where the attacker's activity using stolen credentials can appear as legitimate access from a trusted application. The breach advisories mention the used IP addresses as indicators of compromise which administrators could use to distinguish malicious from legitimate activity. However, since the attackers also had access to Salesloft's AWS infrastructure, they theoretically could have routed their attacks through those same servers, making detection nearly impossible. This visibility challenge underscores a fundamental reality: your security posture is inherently dependent on the security practices of every vendor in your supply chain. When a trusted partner's credentials are compromised, distinguishing between authorized and malicious access becomes difficult without proper monitoring of third-party access patterns and token usage.

How Netskope SSPM Can Help

Netskope SaaS Security Posture Management (SSPM) helps organizations strengthen their Zero Trust principles to SaaS platforms like Salesforce, Google Workspace, Microsoft 365, and many more. SSPM enables you to discover integrations, review the permissions they have been granted, and identify those with too broad or sensitive access. It also supports real-time monitoring of configuration and compliance checks against industry standards and custom policies, helping to reduce misconfigurations and maintain a strong security posture. By surfacing potential risks and misconfigurations, SSPM empowers security teams to make informed decisions about third-party access and SaaS app settings, helping to keep sensitive data protected within your SaaS ecosystem.

Here's how you can leverage Netskope SSPM to enhance your Salesforce security posture .

To begin to use the capabilities of SaaS Security Posture Management (SSPM), make sure you have onboarded your Salesforce instance. If your Salesforce instance has not yet been added to your SSPM environment, please refer to the comprehensive guide available at https://docs.netskope.com/en/configure-salesforce-instance-for-next-generation-saas-security-posture-management. This documentation provides a step-by-step walkthrough to configure your Salesforce instance in SSPM.

Once your Salesforce instance is onboarded, select a policy for your Salesforce instance. Navigate to Policies→SaaS Security Posture Management, then filter by App Suite to Salesforce. A variety of policies will be presented, from which you may choose based on your requirements, or you may create a new policy.

Once your policies are enabled , a set of rules, designed to evaluate and enforce your SaaS app’s security posture will execute.

Once that is done you can gain an immediate understanding of your Salesforce security standing. Navigate to API-enabled Protection→Security posture SaaS→Apps. Within this section, you will find a detailed security score specifically for Salesforce, offering a quick overview of its current state. The rating is presented on a scale of 0-100, alongside the number of instances, failed findings, third-party applications, and users. The numbers shown offer quick shortcuts for filtering findings and apps of interest.

To assess the risk score of third-party applications to identify any unwanted or risky connections. Navigate to API-enabled Protection → Security posture SaaS → 3rd Party Apps. Here, filter by "Connected to" Salesforce to pinpoint any third-party applications related to that platform. Unwanted or excessively privileged third-party apps pose a significant security risk, as they could be used for access in data breaches, such as when Salesloft was used to leak sensitive information.

This view provides a risk score based on the permissions requested for each connected application, evaluating the potential risk a third party might pose. For every connected app, you can perform basic vetting workflows by right-click the three dots on the right to select a verification status from options such as "Review Pending", "Review in Progress", "Approved", "Needs to be Removed", "Risk Accepted", or "Re-review Pending." You can also add notes for future reference, helping to ensure no unwanted apps are present in your Salesforce instance and providing clear explanations for any suspicious-looking applications.

After you have a good idea of your connected apps, the next step into securing your salesforce instance against 3rd party attacks is to delve into specific findings. Findings are the results of rule checks indicating whether your configurations pass or fail security policies. A "failed finding" signifies the detection of a suspected misconfiguration or a potential configuration improvement. These misconfigurations might range from incorrectly set permissions to outdated security protocols and many others, all of which might impact the risk of unauthorized access or data breaches. Therefore, identifying and understanding failed findings is paramount to proactively strengthening your defenses. Netskope SaaS Security Posture Management (SSPM) offers a robust framework, incorporating a comprehensive suite of rules specifically designed for hardening the security of Salesforce environments along with the ability to modify and create your own detections.

To access and leverage these insights, users should navigate to API-enabled Protection→Security posture SaaS→Finding within the Netskope platform.

Once in this section, apply the "AppSuite" filter to Salesforce. To filter issues categorized as 3rd party apps select the filter of “3rd party apps” from the Domain.

One can also use other filters such as for Resource Type “ConnectedApp” to look for findings on 3rd party connected app resources on your connected salesforce instances which were onboarded in SSPM.

These findings represent the evaluations of rigorous rule checks against a model built from your unique Salesforce deployment, which systematically evaluate whether existing configurations within your systems adhere to established security policies and best practices. Essentially, each finding acts as a data point, revealing suspected compliance or non-compliance with your configured security policy. By systematically reviewing and remediating these prioritized findings especially related to the 3rd party apps, organizations can significantly enhance the security of their Salesforce applications, protecting sensitive data, maintaining compliance with regulatory requirements and cyber security attacks such as salesloft. For example, as enforcing IP address access controls was found to be one of the few working countermeasures against the attacks, one can use the rule “Connected App IP Relaxation and Continuous IP Enforcement” to look for any Salesforce Connected Apps which might not be protected by your organizations IP Address Control policies.

To mitigate a failed finding, clicking on the rule will provide a detailed description of the failed result, along with comprehensive, step-by-step instructions on how to rectify the issue.

Example: This rule verifies if connected applications are secured by a High Assurance session. It also outlines steps to address identified security misconfigurations and/or reinforce security controls, thereby strengthening defenses against third-party application attacks for a more secure environment.

Once the recommended remediation steps have been successfully applied and the identified issue is thoroughly addressed, it will lead this finding to turn from failure into a pass in SSPM after the next scan of your environment. This proactive approach will help you enhance the security of your SaaS environment, mitigating potential security misconfigurations and strengthening its resilience against threats.

Conclusion

The Salesloft incident underscores the need for organizations to prioritize security measures of their SaaS ecosystem, particularly against the backdrop of an increasing threat landscape from supply chain attacks. By leveraging solutions like Netskope SSPM, organizations can proactively identify and mitigate vulnerabilities in their SaaS application ecosystem, strengthening their overall security posture and resilience against sophisticated attacks.