Reviewing the Salesforce–Salesloft Drift OAuth Supply Chain Breach
In August 2025, Salesloft's Drift chatbot integration was exploited to gain access to hundreds Salesforce environments.
Between 9 and 17 August 2025, the intrusion cluster tracked as UNC6395 exploited stolen OAuth tokens from Salesloft’s Drift chatbot integration to gain access to hundreds of Salesforce environments. Over a ten-day period, the attackers systematically queried and exported large volumes of records from more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium, and Zscaler. The breach was confined to data stored in Salesforce, principally support case text, contacts, and account information, rather than Salesforce’s underlying platform.
The campaign’s focus is credential harvesting. Stolen records were combed for plaintext AWS keys, VPN credentials, Snowflake tokens, and other secrets that could enable follow-on compromises. The intrusion was conducted through Salesforce’s APIs, with the adversary using automated Salesforce Object Query Language (SOQL) queries, bulk exports, and custom user-agent strings to appear legitimate. They also deleted query job logs and routed traffic through Tor and cloud infrastructure to obscure their activity.
Salesloft detected the activity on 19 August and, in coordination with Salesforce, revoked all Drift OAuth tokens the next day, halting further access. The Drift integration was disabled platform-wide and removed from the AppExchange as a precaution, and affected customers were notified. While the immediate threat was contained, the stolen credentials and data remain a long-term risk. The incident underscores the danger of over-permissive SaaS integrations and the critical need to restrict OAuth access, avoid storing secrets in support cases, and monitor for anomalous API behavior.
This report examines the Salesforce–Salesloft OAuth supply chain breach to show how the attack unfolded and what lessons can be drawn. It starts with a timeline of events to illustrate the progression from access to containment, then reviews the scope of impact and the types of data exposed. The attacker’s tactics are mapped to the MITRE ATT&CK framework to highlight how familiar techniques were applied in a SaaS context. A profile of UNC6395 follows, outlining their known capabilities and intent. The report closes with indicators of compromise and key takeaways, highlighting the risks of over-permissive SaaS integrations and the need for stronger controls around OAuth tokens.
Incident Overview and Timeline
Between 9 and 17 August 2025, a stealthy supply-chain attack unfolded impacting numerous companies via a popular sales chatbot integration. Salesloft’s Drift AI Chat agent (used for website live chat and lead generation) was compromised by UNC6395, who stole the OAuth authentication tokens that Drift uses to connect to customers’ Salesforce Customer Relationship Management (CRM) systems.¹
OAuth tokens are digital keys that allow one service to act on behalf of a user or application without exposing usernames or passwords. In Salesforce, they let connected apps like Drift query data through APIs with the permissions granted during setup. If stolen, these tokens can be reused by an attacker to access data directly, bypassing login and MFA protections until the tokens are revoked.
Armed with these tokens, the attacker masqueraded as the trusted Drift app to access Salesforce data for hundreds of organizations without needing direct network intrusions or user credentials. Below is a timeline of key events in the attack and response. This reconstruction is primarily based on Cloudflare’s incident report, which provides one of the most detailed and well-structured timelines available, including the organization's own post-compromise remediation actions that illustrate the practical steps required to contain and recover from such an attack.2
9 Aug 2025: Reconnaissance begins. UNC6395 tests a Cloudflare-issued Salesforce token using Trufflehog as a user-agent, receiving a 404 response that confirmed the token was invalid. This was a targeted probe for drift-issued credentials, using a tool well known for secret scanning. It shows the actor was already focused and deliberate in their approach.
12 Aug 2025: Initial compromise. UNC6395 logs in with a stolen Salesloft/Drift credential from 44[.]215[.]108[.]109 and enumerates objects via /services/data/v58.0/sobjects/. The activity maps the boundaries of the dataset, a classic reconnaissance step in a SaaS context that likely aimed to reveal what could be exfiltrated before any larger operation.
13 Aug 2025: Schema pull and early collection. From the same IP, UNC6395 re-enumerates, retrieves /sobjects/Case/describe/, and queries across Case fields, pulling support-ticket content. By focusing on the Case schema, the actor was targeting unstructured text where sensitive information such as credentials often hides.
14 Aug 2025: Deep discovery. Again from 44[.]215[.]108[.]109, UNC6395 counts Accounts, Contacts, and Users, inspects CaseTeamMemberHistory, fingerprints the Organization object to verify a production context, and probes /limits to identify API constraints. This phase demonstrates caution and sophistication: by learning the API limits, the attacker ensured they could exfiltrate data without triggering alarms, a hallmark of stealth operations in cloud environments.
15–16 Aug 2025: A period of silence. No logins or activity are detected for nearly 48 hours, suggesting a camouflage posture. The actor may have been waiting to see if their activity had raised suspicion or allowing logs to age before moving on to the main operation.
16 Aug 2025: Pre-exfil “dry run.” UNC6395 returns and runs SELECT COUNT() FROM Case to confirm the size of the dataset. This was not a trivial step but a calculated check to calibrate Bulk API thresholds, showing the precision of a planned exfiltration rather than opportunistic data theft.
17 Aug 2025: Bulk exfiltration and cover-up. The actor shifts to 208[.]68[.]36[.]90, launches a Salesforce Bulk API 2.0 job at 11:11:56, and exfiltrates support-case text in roughly three minutes. At 11:15:42, they delete the Bulk job entry in an attempt to cover their tracks. Although this action concealed the main evidence, Cloudflare reconstructed the attack from residual logs, and no further activity was observed after this date. The operation was tightly executed, with rapid exfiltration and minimal footprint, and the choice to avoid attachments suggests an effort to bypass content scanning or Data Loss Prevention (DLP) controls.
20 Aug 2025: Vendor pre-notification action. Salesloft revokes all Drift-to-Salesforce connections across its customer base and posts a public notice. At this point Cloudflare had not yet been notified, highlighting the blind spot organizations face in the window between vendor containment and customer disclosure.
23 Aug 2025: Notification received. Salesforce and Salesloft formally notify Cloudflare of abnormal Drift-related activity, triggering Cloudflare’s incident response. This marks the start of a reactive phase where containment and investigation depend heavily on vendor intelligence sharing.
25 Aug 2025: Cloudflare escalates its response. The Drift account is disabled, client ID and secrets revoked, Salesloft software and extensions purged, and a wider review of third-party integrations is launched. Credentials are rotated as a precaution. Cloudflare also develops custom scanning tools using regex, entropy, and pattern matching to analyze exfiltrated Case text for secrets, confirming the exposure was limited to free-text and did not include files. This layered approach shows a mature process: contain the immediate threat, investigate at scale, and validate exposure with bespoke tooling.
26–29 Aug 2025: Hardening and scaled remediation. Cloudflare re-onboards third-party integrations with new secrets under stricter controls and rotates 104 API tokens that may have been exposed. The ability to coordinate such large-scale rotation quickly and cleanly demonstrates operational maturity and tight collaboration across teams.
2 Sep 2025: Customer notifications. Cloudflare informs all impacted customers via email and dashboard banners, providing details of the incident and recommended next steps. This transparent and proactive communication modelled how cloud providers can maintain trust after a significant breach.
Impact and Data Compromised
Scope of Impact: This incident had a broad impact across industries, affecting potentially hundreds of organizations globally (700+ by some estimates).3 Victims were limited to companies that had connected the Salesloft Drift application to their Salesforce environment. Notably, many impacted entities are tech and security firms, indicating how prevalent the Drift chatbot integration was in enterprise environments. For example, Cloudflare confirmed the breach allowed access to their Salesforce support data; Google acknowledged that some Google Workspace accounts integrated with Drift had email data accessed; security vendors like Proofpoint, Palo Alto Networks, Zscaler, Tanium, and SpyCloud were also among those affected.4
Data Accessed: The threat actor queried and stole data from several Salesforce objects in each victim tenant, focusing on those likely to yield credentials or sensitive business information. According to incident analyses, records from “Case”, “Contact”, “Account” and “Opportunity” were common targets.5 The compromised data included customer contact details , such as names, business emails, phone numbers and support case contents (text of communications between customers and support reps).6 For example, Zscaler reported that the attacker accessed “commonly available business contact details” of their customer contacts and plain-text support case metadata (case descriptions, status, owner, etc.), but no attachments or files.7 Cloudflare similarly noted that the intruder accessed only text fields of support tickets, not file attachments, in their Salesforce instance.
While the stolen CRM data by itself was sensitive, the most critical risk was that some of these records contained credentials or secrets. Many organizations occasionally include API keys, access tokens, passwords, or other security data in support cases or account notes. The attacker specifically searched the exported data for such high-value secrets, such as strings matching AWS Access Keys, Snowflake database tokens, VPN credentials, etc.. Any plaintext credentials found would allow the adversary to pivot into other systems. Cloudflare, for instance, discovered 104 of their own API tokens had been included in compromised support cases; they proactively rotated all of them to prevent misuse.8 Mandiant reported that UNC6395 was primarily interested in credential harvesting to facilitate follow-on breaches beyond the initial Salesforce data.
It’s important to note that core Salesforce account passwords or MFA secrets were not stolen, the attacker used OAuth tokens to access data via API, meaning they did not need to compromise any users’ credentials or Salesforce’s infrastructure. The integrity and availability of Salesforce services were unaffected; this was purely a data confidentiality breach via the integration. However, the second-order impact is high: by obtaining troves of contacts and credentials, the attackers could mount targeted phishing or network intrusions against both the victim organizations and their customers. Cloudflare warned that the incident was likely intended to “harvest credentials and customer information for future attacks”, and that affected orgs should be on alert for targeted threats leveraging the stolen data.9
In summary, the breach exposed a wealth of corporate data across numerous companies, mainly support case data and associated contact info, and potentially opened the door to far more damaging attacks if any extracted credentials are used by the adversary. The event highlights how even data that might seem mundane can contain “crown jewels” like passwords or API keys, underscoring the need for careful handling of secrets in SaaS platforms.
Attack Lifecycle and Tactics
The following outlines the attacker’s Tactics, Techniques, and Procedures (TTPs) as observed in the Salesforce–Salesloft Drift breach, mapped to the MITRE ATT&CK framework. This illustrates how the intrusion progressed from initial access via a trusted relationship to data exfiltration, along with defense evasion measures:
Table 1 - MITRE ATT&CK quick reference for the UNC6395 campaign.
- Initial Access – Trusted Relationship (T1199): The adversary gained entry to victim environments by exploiting the trust between Salesforce and a third-party application. By compromising Salesloft’s Drift chatbot platform (the vendor supply chain), they obtained valid OAuth tokens that granted access to the Salesforce instances of Drift’s customers. This technique abused an existing integration relationship, effectively using the vendor’s authorized access as a trojan horse into the client’s system. (Salesloft later confirmed the app’s connection was the weak point, not any Salesforce vulnerability.)
- Credential Access – Steal Application Access Token (T1528): The threat actor stole OAuth access and refresh tokens from Salesloft/Drift’s infrastructure. These tokens are essentially credentials that allowed the attacker to impersonate the Drift app for any customer organization. The exact method of theft is not public, but possibilities include exploiting the Drift service or its cloud storage to retrieve stored tokens. Once in possession of these tokens, UNC6395 effectively had persistent authenticated sessions into each associated Salesforce org without needing user passwords or breaking encryption.
- Credential Access – Unsecured Credentials (T1552): After exfiltrating the Salesforce records, UNC6395 searched within the stolen data dumps for credentials and other valuable secrets. This likely involved using scripts or regex-based tools to scan text for patterns like “AKIA” (AWS keys), password strings, or keywords such as “Password:”.10 By doing this, the attackers could isolate plaintext credentials inadvertently stored in cases or fields. Those credentials (for AWS, VPNs, databases, etc.) would then be extracted for later use.
- Execution – Command and Scripting Interpreter: Python (T1059.006): Using Python-based tooling, the attacker executed Salesforce API queries in an automated fashion.11 They leveraged Salesforce’s SOQL to run commands, thereby remotely executing data retrieval operations within the CRM environment. Observed custom user-agent strings, such as Salesforce-CLI/1.0 and Salesforce-Multi-Org-Fetcher/1.0, along with generic Python identifiers (requests, aiohttp), point to script-driven automation. This approach allowed stealthy, automated collection without triggering traditional endpoint security, since all actions occurred through normal Salesforce API channels.
- Discovery – Cloud Service Discovery (T1526): Once connected, the adversary performed discovery of data within Salesforce. They enumerated the environment’s structure and contents by querying standard objects. For example, they ran COUNT() queries to determine how many records existed in key objects, and likely listed user accounts and roles to understand the org’s size and potential high-value targets.12 This step aligns with identifying what data was available for collection and where any secrets might reside.
- Collection – Automated Collection (T1119): The actor then initiated mass data extraction. Through the compromised OAuth sessions, they systematically pulled down records in bulk from Salesforce objects of interest. This was done programmatically (high volume, high speed), indicating automation. The use of Python scripts with libraries such as aiohttp and requests (reflected in user-agent strings) allowed the attacker to efficiently page through record sets and download data without manual intervention. Each targeted organization's data was likely saved to attacker-controlled servers for processing, essentially treating Salesforce as an “information repository” to pillage.
- Collection – Data from Information Repositories (T1213): Specific focus was on extracting sensitive information stored in Salesforce. The attacker retrieved fields from Case objects, Contact/Account objects, and Opportunity objects. In doing so, they obtained not only personal data but also embedded secrets. For example, support case threads often include troubleshooting details and sometimes API keys or logs; the actor collected these en masse. This technique of mining a SaaS application’s database is analogous to dumping a file server or mailbox, except done via cloud APIs.
- Defense Evasion – Indicator Removal: File Deletion (T1070.004): The adversary took measures to cover their tracks within Salesforce’s logging. Unit 42 observed that the attacker deleted asynchronous job records that Salesforce generates when large query batches are run.13 These job logs (which record the execution of bulk data queries) were removed via additional API calls, as an anti-forensic technique to hinder detection. However, Salesforce’s higher-level Event Monitoring logs still retained evidence of the queries despite the job deletions.14
- Defense Evasion – Multi-hop Proxy (T1090.003): To avoid attribution and limit the effectiveness of IP-based defense, the attacker channeled their malicious traffic through anonymization nodes.15 UNC6395 also utilized cloud-based virtual private servers (VPS). By originating API requests from such infrastructure, the attacker made it difficult for defenders to distinguish malicious access from legitimate user traffic. This technique provided both operational security and ensured the attacker could rapidly shift to new nodes if any single IP got flagged.
- Exfiltration – Exfiltration Over Web Service (T1567.002): All data was exfiltrated via standard web service protocols. The nature of the attack meant that exfiltration was essentially data download via API, which blends in with normal application traffic. There was no need for custom C2 channels or malware beacons; the stolen data was directly delivered to the attacker through the cloud service. This corresponds to using an existing API as an exfiltration channel, which is stealthy and encrypted by default. The exfiltrated records were likely aggregated and then moved from the attacker’s intermediate servers to longer-term storage. Given the volume, this activity might have appeared as large data transfers from Salesforce to unusual networks, a red flag if monitored.
Overall: UNC6395’s tactics exhibit a full attack lifecycle in the cloud: initial access via third-party trust, credential theft, automated discovery and collection, and stealthy exfiltration, all executed without traditional malware. The success of these techniques highlights gaps in many organisations’ monitoring of SaaS integrations and the need to apply zero-trust principles to interconnected cloud services.
Threat Actor Overview: UNC6395
The campaign has been attributed to the intrusion cluster tracked by Google’s Threat Intelligence Group as UNC6395 (with “UNC” denoting an uncategorized group). These designations imply it is a distinct threat group not previously catalogued. As of late August 2025, no definitive nation-state or cybercrime affiliation has been confirmed; Google stated it had not determined the actor’s origins or motivations beyond the actions observed, assessing only that the activity was aimed at large-scale credential harvesting. However, AppOmni researchers have speculated that UNC6395 may be a Chinese-linked threat actor based on their analysis and targeting, though this assessment is not officially corroborated.16
UNC6395 has demonstrated advanced capabilities in cloud and SaaS exploitation. Their tactics, compromising a software supply chain (Salesloft), using OAuth tokens to pivot into cloud data, harvesting credentials, and attempting to conceal activity, are consistent with tradecraft typically associated with advanced persistent operations. For example, they built custom automation tools to extract data from many organizations in parallel. They also showed knowledge of Salesforce APIs and logging, enabling them to enumerate data efficiently and attempt to erase evidence by deleting query job records. This level of tradecraft points to an actor experienced in cloud platform attacks and data exfiltration, likely preparing in advance for such an operation.
The motivation behind UNC6395’s campaign appears to be information gathering for secondary intrusion operations. By amassing credentials and internal data from a wide range of companies, the actor could either monetize that access (if cybercriminal) or use it for espionage or sabotage (if state-affiliated). The systematic targeting of credentials and the “spray and harvest” approach of hitting hundreds of organizations suggests broad reconnaissance or staging. Such behavior could support a state-linked espionage effort to establish backdoors for later exploitation, or a financially driven model aimed at selling access or extorting companies. Without confirmed attribution, both scenarios remain plausible.
UNC6395 did not deploy malware, relying entirely on stolen OAuth tokens and standard APIs to achieve its objectives. The incident illustrates how adversaries can weaponize trusted SaaS integrations at scale, turning a single weak link into a breach affecting hundreds of organizations. This pattern suggests UNC6395 is likely to continue pursuing supply-chain vectors, underscoring the need for stronger controls around third-party integrations.
Conclusion
The Salesforce–Salesloft Drift breach of August 2025 demonstrates the growing risks in SaaS supply chains and cloud integrations. A single weak link, in this case, a third-party chatbot application with broad access, was exploited to bypass the security of hundreds of well-defended organizations. The incident was unprecedented in scale, affecting enterprises across sectors, and was executed with a high level of stealth and precision. In the aftermath, it has become clear that traditional security perimeters mean little in the cloud era if trusted connections are not equally secured.
This attack serves as a call to action for security teams: SaaS integrations and OAuth tokens must be treated as high-value credentials. Organizations should audit third-party app permissions, enforce controls like IP allowlisting for connected apps, and monitor for abnormal data access patterns. Basic security hygiene, such as never storing unencrypted secrets in support tickets or notes, can significantly limit damage from a breach like this.
While the immediate threat from UNC6395’s access has been contained through token revocation, the potential fallout persists. Companies whose data was stolen must assume that any credentials contained therein are compromised and take action. They should also be on guard against phishing or impersonation attempts, since contact info and context from support cases could be weaponized by attackers crafting social engineering lures.
In summary, the Salesforce–Salesloft breach highlights the importance of Zero Trust principles extending to SaaS ecosystems: trust no OAuth token by default, verify all third-party access continuously, and be prepared for the eventuality that a trusted integration can be suddenly turned against you. By learning from this incident and implementing tighter controls and monitoring, organizations can reduce the likelihood of being the “next in line” in such supply-chain attack sprees.
Indicators of Compromise
Multiple indicators have been identified that can help detect or hunt for this breach activity. These include distinctive HTTP user-agent strings used by the attacker’s tools and IP addresses from which the malicious API calls originated.17 Security teams can search logs for these IOCs to identify possible unauthorized access. Below we provide a summary of the known IOCs from public reports.
Malicious User-Agent Strings: The following custom or uncommon HTTP user-agents were observed in connection with UNC6395’s Salesforce data theft. These strings were used by the adversary’s automated scripts when interfacing with the Salesforce API:
Table 2 - Malicious or unusual HTTP user-agent strings observed in UNC6395 campaign.
While user-agent strings are high-signal artifacts, they can be spoofed. Reports indicate these identifiers were consistently observed across multiple victims, which makes them valuable for clustering related activity. However, they should not be relied upon as sole indicators.
Threat Actor IP Addresses: Analysis by Google/Mandiant uncovered numerous IP addresses tied to the malicious login and data access patterns. These include cloud hosting providers and many Tor network exit nodes. Organizations should review authentication and API access logs for connections from these IPs (keeping in mind that Tor exit IPs are shared infrastructure and may also appear due to other user traffic). Known attacker IP addresses include:
Table 3 - Network indicators linked to UNC6395 access.
Table Note: Many of the above IPs are part of the Tor anonymity network, which the attacker leveraged to hide their origin. Because Tor exit IPs rotate frequently and may be used by legitimate users, they have limited value as long-term IOCs. They should be used as corroborating signals when combined with distinctive user-agent strings or behavioral patterns. That said, any Salesforce login or data access from a Tor exit IP is highly unusual for most organizations and should be investigated.
Endnotes
- Matt Kapko, “Hundreds of Salesforce Customers Impacted by Attack Spree Linked to Third-Party AI Agent,” CyberScoop, accessed September 9, 2025, published August 26, 2025, https://cyberscoop.com/salesforce-salesloft-drift-attack-spree-google/. The Hacker News, “Salesloft Takes Drift Offline after OAuth Token Theft Hits Hundreds of Organizations,” The Hacker News, accessed September 9, 2025, published September 3, 2025, https://thehackernews.com/2025/09/salesloft-takes-drift-offline-after.html.
- “The Impact of the Salesloft Drift Breach on Cloudflare and Our Customers,” The Cloudflare Blog, accessed September 9, 2025, published September 2, 2025, https://blog.cloudflare.com/response-to-salesloft-drift-incident/.
- Google Threat and Mandiant, “Widespread Data Theft Targets Salesforce Instances via Salesloft Drift,” Google Cloud Blog, accessed September 9, 2025, published August 26, 2025, https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift.
- Google Threat and Mandiant, “Widespread Data Theft Targets Salesforce Instances via Salesloft Drift,” Google Cloud Blog, accessed September 9, 2025, published August 26, 2025. Sam Curry, “Salesloft Drift Supply Chain Incident: Key Details and Zscaler’s Response,” Zscaler Blog, accessed September 9, 2025, published August 30, 2025, https://www.zscaler.com/blogs/company-news/salesloft-drift-supply-chain-incident-key-details-and-zscaler-s-response.
- Sam Curry, “Salesloft Drift Supply Chain Incident: Key Details and Zscaler’s Response,” Zscaler Blog, accessed September 9, 2025, published August 30, 2025.
- “The Impact of the Salesloft Drift Breach on Cloudflare and Our Customers,” The Cloudflare Blog, accessed September 9, 2025, published September 2, 2025.
- Sam Curry, “Salesloft Drift Supply Chain Incident: Key Details and Zscaler’s Response,” Zscaler Blog, accessed September 9, 2025, published August 30, 2025.
- Matt Kapko, “Hundreds of Salesforce Customers Impacted by Attack Spree Linked to Third-Party AI Agent,” CyberScoop, accessed September 9, 2025, published August 26, 2025.
- “The Impact of the Salesloft Drift Breach on Cloudflare and Our Customers,” The Cloudflare Blog, accessed September 9, 2025, published September 2, 2025.
- Unit 42, “Threat Brief: Salesloft Drift Integration Used to Compromise Salesforce Instances,” Unit 42 Blog, accessed September 9, 2025, published September 2, 2025, https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/.
- “The Impact of the Salesloft Drift Breach on Cloudflare and Our Customers,” The Cloudflare Blog, accessed September 9, 2025, published September 2, 2025.
- Ibid.
- Unit 42, “Threat Brief: Salesloft Drift Integration Used to Compromise Salesforce Instances,” Unit 42 Blog, accessed September 9, 2025, published September 2, 2025.
- “The Impact of the Salesloft Drift Breach on Cloudflare and Our Customers,” The Cloudflare Blog, accessed September 9, 2025, published September 2, 2025.
- Unit 42, “Threat Brief: Salesloft Drift Integration Used to Compromise Salesforce Instances,” Unit 42 Blog, accessed September 9, 2025, published September 2, 2025.
- Chad Knipschild, “Salesloft Drift–Salesforce Breach (UNC6395): Why Salesforce OAuth Integrations Are a Growing Risk,” AppOmni Blog, accessed September 9, 2025, published August 26, 2025, https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/.
- Google Threat and Mandiant, “Widespread Data Theft Targets Salesforce Instances via Salesloft Drift,” Google Cloud Blog, accessed September 9, 2025, published August 26, 2025.
Discover More About Anomali
Get the latest news about cybersecurity, threat intelligence, and Anomali's Security and IT Operations platform.
Propel your mission with amplified visibility, analytics, and AI.
Learn how Anomali can help you cost-effectively improve your security posture.
