TL;DR: The recently disclosed Salesforce data-theft attacks highlight two distinct non-human identity failures. First, Drift’s handling of OAuth tokens broke down, leading to credential compromise at scale. Second, Salesforce had become a warehouser of sensitive credentials even though it was never intended to function as a secrets custodian. These two weaknesses combined to create the conditions the threat group behind the attacks exploited.
Breaches that involve Salesforce are not just another entry in the cyber incident tally list.
When attackers compromise instances of the SaaS CRM giant, they are accessing the central functions of an enterprise. The widely deployed platform typically holds customer records, sales data, and a web of integrations that extend deep into the business operations for tens of thousands of worldwide customers.
That is what made the recent disclosure by Google and Mandiant so significant. The adversaries, identified as hacker group UNC6395, stole Salesforce OAuth tokens and used them to impersonate a trusted integration with Drift, a sales automation application that connects directly to Salesforce. With that access, they systematically queried Salesforce objects and exfiltrated data.
The attackers did not break into Salesforce directly. They relied on stolen Salesforce OAuth tokens provisioned through Drift, which allowed them to act as a legitimate application. That trust enabled large-scale data exports, including embedded credentials hidden in Salesforce records. By chaining together weak token management and poor credential hygiene, they converted access to a CRM system into access to cloud infrastructure. To minimize detection, they deleted the query jobs once complete, though log traces remained.
What they were after, however, went beyond contact lists and pipeline information. In many Salesforce instances, sensitive credentials such as AWS keys, Snowflake tokens, and service passwords end up stored within records. This effectively turned Salesforce into a de facto credential repository and gave attackers the opportunity to move far beyond CRM data. Once uncovered, these secrets can be leveraged to reach far beyond Salesforce itself to conduct other, potentially more damaging, attacks.
Still, it is tempting to treat this as a narrow incident affecting only those who installed Salesloft Drift. That would be a mistake. The real story is not Drift itself, but the structural reality of how enterprises extend trust.
New findings late Thursday from Google’s Threat Intelligence Group and Mandiant show that UNC6395’s activity was not confined to Salesforce. Attackers also abused OAuth tokens tied to the Drift Email integration, which in some cases exposed connected Google Workspace accounts. This reinforces that token abuse is not an isolated Salesforce-related incident but part of the broader challenge of how workloads and services exchange and honor OAuth tokens across platforms.
Connected applications receive broad permissions, and the tokens that represent them are often long-lived. Security teams often lack visibility into how these non-human identities are being used, or even how many of them exist. Human-focused identity protections do nothing to stop this type of misuse, although their principles can be extended to the non-human identity realm with workload IAM.
Recommended Immediate Actions
Salesforce and Salesloft have already revoked the affected tokens and removed Drift from the AppExchange, but organizations should not treat the matter as contained. The compromise underscores structural issues around non-human identity management and secrets sprawl.
Firstly, from an incident response perspective, organizations should:
- Rotate any API keys, tokens, and passwords that may have been stored in Salesforce objects, assuming exposure. (Here’s a helpful guide.)
- Conduct a thorough review of Salesforce Event Monitoring logs to identify suspicious query patterns, especially those linked to Drift or other integrations.
- Revisit connected application permissions and reduce them to the minimum scopes required for operation.
- Establish and maintain an inventory of non-human identities and their associated credentials, including OAuth tokens and service accounts, so that trust relationships are visible and accountable.
- Enforce IP restrictions and login ranges for connected applications to limit their operational surface area.
A Strategic Approach to Eliminating Credential Risk
This incident also highlights a structural weakness that quick remediation cannot fix. Long-lived tokens and accumulated secrets create fragile trust boundaries, and those boundaries will only become more strained as agentic AI and other autonomous services increase the number of non-human identities moving between SaaS platforms.
Integrations between SaaS platforms often rely on long-lived tokens passed back and forth with little oversight. What is missing is a way to mediate that trust – an identity-aware, policy-based proxy that can handle token exchanges securely, limit scope, and provide visibility across applications. In other contexts, such proxy models already exist. Extending that same approach to SaaS-to-SaaS connections may be one of the few ways to prevent a single compromised token from cascading into a wider breach.
The lesson is not to manage secrets more aggressively, but to manage access directly. Tokens live too long, secrets sprawl into platforms not designed to hold them, and third-party integrations receive more trust than they should. Until organizations apply the same rigor to non-human identities as they do to human accounts incidents like the Salesforce–Drift compromise will remain inevitable.
For more information how Aembit can help, visit aembit.io.I
