Salesloft: when a token opens too many doors
Table of Contents
On August 20, 2025, an incident originated in the Salesloft Drift integration was detected. Nearly twenty companies have been confirmed to be affected, including large technology companies with Salesforce environments and other associated services, the impact could have been much greater given the use of Salesforce environments and other associated services. This case showcases how a single vulnerable link in the supply chain can have an exponential impact on multiple companies globally.
OFFICIAL STATEMENTS FROM AFFECTED ORGANIZATIONS
Anatomy of the attack: hypothesis of what happened
- Initial compromise: Attackers compromised Salesloft’s GitHub repository between March and June 2025. The main hypotheses suggest that initial access was gained by obtaining credentials, using social engineering, or credentials exposed in previous leaks. Once inside, they downloaded source code from private repositories, added a guest user, and set up suspicious workflows that gave them visibility and possible persistence in the environment.
- Exploitation of Drift on AWS: Through this initial access, they conducted limited reconnaissance on the Salesloft environment and, more deeply, on the Drift infrastructure hosted on AWS, where they managed to obtain OAuth and refresh tokens associated with customers, which they then used to perform illegitimately access Salesforce instances and other services (Google Workspace, Snowflake, AWS).
- Exfiltration: Once inside Salesforce, they ran reconnaissance queries to map key objects and then used the Bulk API 2.0 to exfiltrate data on a large scale.
The compromised information included text fields in support cases, customer records, and sensitive credentials such as AWS keys, Snowflake tokens, and corporate passwords.
In addition, to hide their activity, the attackers deleted the export jobs after downloading them and did not exceed the Bulk API limits, making immediate detection and analysis difficult.
DIAGRAM OF THE SALESLOFT DRIFT INCIDENT ATTACK
Responsibility for the incident
Although the authorship of this incident has not been fully confirmed, the main candidate is an emerging actor that had not been observed in other campaigns. The malicious group is called UNC6395, also identified as GRUB1 by Cloudflare.
- Google Threat Intelligence Group (GTIG) was the first entity to identify UNC6395 as responsible for abusing Drift OAuth tokens to access Salesforce and Google Workspace environments.
- Cloudflare, a direct victim, designated the actor with the alias GRUB1, confirming that the technical information obtained matched Google’s findings.
- Obsidian Security also raises the possibility that UNC6395 may have collaborated with other groups such as ShinyHunters or Scattered Spider. However, there is no evidence to support this hypothesis.
- Tarlogic’s MxDR corroborates the above points, validating that the modus operandi used is similar but not identical to that used by these groups to date.
COMPARATIVE ANALYSIS OF SELECTED FINDINGS
| Shiny Hunters | Scattered Spider | Lapsu$ | UNC6395 | |
|---|---|---|---|---|
| Infrastructure overlaps (VPNs, phishing panels, fraudulent domains) | X | |||
| Coincidence in TTPs (social engineering, credential abuse -OAuth-) | X | X | X | X |
| History of similar previous campaigns | X | X | X | |
| Public claim of authorship attribution | ||||
| Technical evidence (IOCs) | X | |||
| Extortion model: dissemination on Telegram | X | X |
Direct impact and the domino effect
Beyond the confirmed victims, the incident reveals how a compromised third party can trigger a massive impact on the SaaS supply chain. The widespread use of Salesforce and its integration with multiple platforms (Slack, Google Workspace, CRM tools, marketing automation, etc.) multiplies the risk: a single point of compromise can spread to dozens or hundreds of organizations without them being immediately aware of it.
OAuth tokens acted as a backdoor by evading traditional authorization controls, revealing an uncontrolled scope where a single compromised integration potentially affected an unknown number of customers across interconnected ecosystems such as Salesforce, Slack, and Google Workspace. It should be noted that many of these solutions are considered critical functions in a multitude of organizations.
This case highlights the collateral impact of this type of incident, characterized by:
- Excessive reliance on SaaS integrations, where the strictest security controls are usually assumed.
- Insufficient visibility of the actions performed by the malicious actor, making it difficult for the victim to identify anomalous or malicious patterns.
- Risk’s persistence, as compromised tokens can maintain access even after the incident is discovered.
- Reputational and regulatory risk for companies in the chain that, even if they are not the initial victims, may find customer, partner, or employee data exposed.
Furthermore, it demonstrates how a seemingly minor integration can become a critical risk vector for the entire organization, amplifying its effect throughout the supply chain. In an interconnected ecosystem, a localized breach not only compromises the initial victim, but can spread like dominoes to customers, suppliers, and partners, undermining trust and exposing critical data beyond the organization’s perimeter.
Identified Indicators of Compromise
The research carried out by Tarlogic’s MxDR has yielded the following Indicators of Compromise to be compiled:
MALICIOUS USER-AGENT STRINGS
| › Salesforce-Multi-Org-Fetcher/1.0 | › Salesforce-CLI/1.0 | › python-requests /2.32.4 | › Python/3.11 aiohttp/3.12.15 |
MALICIOUS IP ADDRESSES
| › 208[.]68[.]36[.]90 (DigitalOcean) › 179[.]43[.]159[.]198 (TOR exit node) › 185[.]220[.]101[.]143 (TOR exit node) › 185[.]220[.]101[.]180 (TOR exit node) › 192[.]42[.]116[.]20 (TOR exit node) | › 44[.]215[.]108[.]109 (Amazon Web Services) › 185[.]130[.]47[.]58 (TOR exit node) › 185[.]220[.]101[.]164 (TOR exit node) › 185[.]220[.]101[.]185 (TOR exit node) › 194[.]15[.]36[.]117 (TOR exit node) | › 154[.]41[.]95[.]2 (TOR exit node) › 185[.]207[.]107[.]130 (TOR exit node) › 185[.]220[.]101[.]167 (TOR exit node) › 185[.]220[.]101[.]33 (TOR exit node) › 195[.]47[.]238[.]178 (TOR exit node) | › 176[.]65[.]149[.]100 (TOR exit node) › 185[.]220[.]101[.]133 (TOR exit node) › 185[.]220[.]101[.]169 (TOR exit node) › 192[.]42[.]116[.]179 (TOR exit node) › 195[.]47[.]238[.]83 (TOR exit node) |
What can companies do?
What follows are several suggestions:
- Check if the organization has been affected:
› Review third-party integrations that may have been affected, rotate credentials, and terminate all of them
› Review logs, especially between August 8 and 18, looking for the identified IOCs or other unusual behavior.
› Stay up to date on any third parties that may be affected. - Detection and preventive measures in response to the upward trend in attacks on the supply chain.
› Maintain up-to-date knowledge of the modus operandi being used in this type of attack
› Implement evaluation procedures for third-party integrations by conducting individual risk assessments and periodic audits to ensure the integrity of the supply chain.
› Have both automatic (i.e., block lists) and manual (Proactive Threat Hunting) detection, alerting, and remediation in place to search not only for IOCs but also for TTPs.
› Use secure techniques for sharing credentials of any kind (passwords, tokens, etc.) to prevent them from being stored in plain text, for example, support tickets hosted by third parties.
› Anticipate threats in the supply chain and improve visibility into external access and risks by using Business Digital Protection and Threat Intelligence Advisory services.
› Carefully assess the risks posed by chatbots, such as Drift, when implementing them.
› Perform penetration testing exercises in SaaS environments, aimed at detecting vulnerabilities, as well as insecure configurations and integrations.