Salesforce and Drift token abuse exposes the NHI trust gap

At a glance

What this is: This is Aembit’s analysis of how stolen Salesforce OAuth tokens tied to Drift enabled impersonation, data theft, and credential exposure across connected SaaS environments.

Why it matters: It matters because the same trust and lifecycle weaknesses can affect NHI, autonomous, and human identity programmes whenever integrations hold more privilege than the business can see or govern.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Aembit's analysis of the Salesforce and Drift OAuth token breach

Context

Salesforce OAuth tokens are a non-human identity control point, not just an application detail. When a connected app is trusted broadly, it can read records, query objects, and move data across systems as if it were a legitimate business process rather than a bounded integration.

The primary failure here is not only token theft. It is the way enterprises often let CRM platforms accumulate credentials, secrets, and downstream trust that were never meant to live there, which turns routine SaaS integrations into a lateral-movement path for attackers.

That pattern is increasingly common in environments where integrations outgrow their original scope. Aembit’s analysis shows why identity governance for SaaS-to-SaaS connections now belongs in the same conversation as secret sprawl, workload identity, and access review discipline.

Key questions

Q: What breaks when a trusted SaaS integration is over-permissioned?

A: A trusted SaaS integration becomes an attacker’s shortcut when its OAuth token has broader access than the business process requires. Once compromised, the token can read records, harvest embedded secrets, and move laterally into other systems. The failure is not only theft of the token but the lack of scope discipline and lifecycle control around it.

Q: Why do OAuth tokens create more risk than simple application passwords?

A: OAuth tokens often carry delegated authority across multiple objects and APIs, so they can expose far more than a single login. They also tend to persist across workflows and vendors, which makes them harder to inventory and revoke quickly. That persistence turns a stolen token into a reusable trust path instead of a one-time secret.

Q: How do security teams know if secrets are being stored in the wrong place?

A: Look for credentials in records, attachments, ticket fields, code repositories, and integration logs. If a business platform can be queried by a connected app and the platform contains secrets, then the secrets are already part of the attack surface. The key signal is not storage location alone but whether those credentials are discoverable through ordinary application access.

Q: Who should own the risk when a SaaS integration is compromised?

A: Ownership should sit with the team that approved the integration and the business function that depends on it, not just with security operations. They must be able to answer who can revoke the token, how scope is reviewed, and when access expires. Without explicit ownership, connected-app risk becomes everyone’s problem and nobody’s responsibility.

Technical breakdown

How stolen OAuth tokens become trusted application access

OAuth tokens represent delegated authority, so a stolen token lets an attacker act as the connected application rather than as a noisy outsider. In this incident, the attacker used tokens tied to Drift to inherit Salesforce access and query objects at scale. The technical weakness is not just token theft, but the absence of strong binding between the token, the integration context, and the specific data access it was supposed to have.

Practical implication: treat connected-app tokens as high-value credentials and constrain them to narrow, observable scopes.

Why Salesforce became a credential repository

Many enterprises store API keys, service passwords, and cloud tokens inside SaaS records because it is convenient for workflows, support, and automation. That creates secret sprawl inside a platform that was designed for business data, not for custodial secret handling. Once those records are indexed and queryable through a trusted integration, a compromise of the integration becomes a compromise of the secrets sitting inside the CRM.

Practical implication: remove secrets from business applications and inventory where credentials are being hidden in records and attachments.

How long-lived integrations expand the blast radius

Long-lived OAuth relationships behave like standing non-human access. If connected applications are over-scoped and not continuously reviewed, a single stolen token can open a broad data path across SaaS platforms, including exposed records, linked systems, and identity-bearing metadata. Deleting query jobs after exfiltration can reduce obvious evidence, but it does not undo the trust relationship that made the access possible.

Practical implication: put lifecycle controls around connected applications, including periodic scope review and revocation triggers.

Threat narrative

Attacker objective: The attacker’s objective was to convert trusted SaaS integration access into reusable credentials and broader enterprise access, enabling theft beyond CRM data.

1. Entry occurred when UNC6395 obtained Salesforce OAuth tokens associated with Drift and a related email integration, giving it access through a legitimate trust path rather than direct exploitation.
2. Escalation followed when the attackers used that delegated access to query Salesforce objects systematically and harvest embedded credentials hidden inside business records.
3. Impact came when stolen secrets and exfiltrated data could be repurposed beyond Salesforce, creating a path into cloud infrastructure and connected accounts.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing SaaS integration trust is now a non-human identity problem, not an application convenience issue. The attacker did not need to break Salesforce directly because the integration itself had been granted legitimate authority. That means the real control failure sits in delegated access design, scope governance, and lifecycle revocation, not in perimeter defence. Practitioners should treat every connected application as an identity with a defined lifecycle, not as a durable technical dependency.

Credential sprawl inside business platforms creates an identity blast radius that most IAM programmes do not measure. Salesforce was used as a de facto secrets repository, which means compromise of one integration could expose cloud credentials, service passwords, and downstream access paths. That is a governance failure in both storage discipline and discoverability. The practitioner implication is that secrets location is now part of identity risk, not a separate hygiene concern.

OAuth token abuse shows why least privilege must extend to machine-to-machine trust chains. Broad connected-app permissions make exfiltration efficient once an attacker gets in through a trusted token. In NHI terms, the control gap is excessive privilege combined with weak accountability for who owns the integration after deployment. Security teams need to classify connected apps by business criticality and monitor them as actively as privileged human access.

Identity programmes that stop at human accounts miss the system-of-systems layer where SaaS, NHI, and cloud access now intersect. This incident is a reminder that human IAM controls can be clean on paper while non-human delegation quietly expands risk. The field needs a more explicit model for delegated SaaS identity, because that is where modern data theft increasingly begins. Practitioners should fold connected-app governance into their core identity operating model.

Trust relationships outlive the people and products that created them unless lifecycle ownership is explicit. Once a token or connected app is provisioned, nobody should assume it remains safe because it is familiar. The governance question is who can revoke it, when scope should be reviewed, and what evidence proves it still deserves access. The practitioner conclusion is simple: assign ownership to every integration as if it were a privileged identity.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to NHI Mgmt Group research.
• That is why the Ultimate Guide to NHIs , Why NHI Security Matters Now remains a useful baseline for teams reassessing connected-app trust and secret exposure.

What this signals

Credential sprawl debt: when business platforms become unofficial secret stores, identity teams inherit a risk surface they cannot see through standard IAM reporting. With Only 5.7% of organisations have full visibility into their service accounts, connected-app governance needs to be treated as an operational control, not a side project.

The immediate programme signal is that OAuth governance, secrets discovery, and integration ownership must converge. Teams should expect more attacks that begin with legitimate delegated access and end with cloud credential reuse, especially where SaaS platforms sit between users and infrastructure. That makes the boundary between IAM, PAM, and NHI management much thinner than many operating models assume.

Readers should also expect vendor and platform reviews to ask harder questions about token scope, revocation paths, and auditability. The next phase of NHI governance is not simply more inventory. It is proving that each integration still deserves the trust it was originally given, with evidence that ownership, scope, and expiry are current.

For practitioners

• Audit connected applications for standing OAuth privilege Inventory every SaaS-to-SaaS integration, identify the scopes each token can use, and map that access to a named owner and business purpose. Revoke or down-scope anything that cannot be justified in writing.
• Remove secrets from queryable business records Search CRM objects, notes, attachments, and custom fields for API keys, service passwords, and cloud tokens. Move those credentials into a controlled secrets system and block future storage in application records.
• Review OAuth lifecycle controls after every integration change Tie connected-app review to deployment, vendor changes, and scope expansion. If the integration changes ownership or purpose, force a re-approval and revoke the old token before the change is considered complete.
• Monitor query behavior on privileged integrations Alert on large object scans, unusual export patterns, and deletion of query jobs after execution. Behavioural monitoring matters because attackers often use valid tokens and try to clean up visible traces afterward.

Key takeaways

• A trusted SaaS integration can become an attacker’s identity foothold when OAuth scopes are too broad and lifecycle control is weak.
• Credential exposure inside Salesforce-style records turns a CRM compromise into a much wider cloud access problem.
• The most effective limit on this class of incident is tighter scope, better secret hygiene, and explicit ownership for every connected application.

Key terms

• Connected application: A connected application is an external service granted access to a platform through delegated authentication and API scopes. In identity terms, it behaves like a non-human identity with its own privileges, lifecycle, and revocation requirements, even when the business sees it as only an integration.
• OAuth token: An OAuth token is a bearer credential that represents delegated access without exposing a user password. In practice, it can authorize a machine or application to read data, call APIs, and move across systems, which makes token scope, storage, and revocation central to NHI governance.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, records, logs, config files, and SaaS platforms. It increases identity risk because secrets become discoverable in places that were never designed for credential custody, and compromise in one system can expose access far beyond it.
• Delegated access: Delegated access is permission granted to one identity to act on behalf of another identity or business process. For non-human identities, it creates trust chains that must be governed explicitly, because the delegated actor can outlive the original need, purpose, or owner if lifecycle controls are weak.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit covering the Salesforce and Drift OAuth token compromise: Salesforce data-theft attacks and NHI exposure through delegated access. Read the original.