Join our Newsletter — 33% off our NHI Course

Salesforce and Drift token abuse: what IAM teams missed

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 21730
Topic starter  

TL;DR: UNC6395 stole Salesforce OAuth tokens tied to Drift, used them to impersonate a trusted integration, and exfiltrated data and embedded credentials from Salesforce records, according to Aembit and Google Threat Intelligence Group and Mandiant. The incident shows that long-lived tokens and secrets sprawl turn SaaS platforms into identity infrastructure without the governance to match.

Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “When Salesforce Becomes a De Facto Credential Repository: Lessons from the Drift OAuth Breach”.

Key questions

Q: What breaks when OAuth tokens are compromised in connected SaaS environments?

A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA.

Q: Why do SaaS platforms create hidden credential risk?

A: Because business teams often store API keys, passwords, and cloud tokens inside records, notes, or support fields that were never designed as secrets vaults.

Q: How should security teams govern third-party access when integrations create new trust boundaries?

A: Security teams should treat every third-party integration as a distinct trust boundary with its own access model, review cycle, and rollback plan.

Practitioner guidance

  • Review connected application scopes Inventory every Salesforce-connected integration, then reduce OAuth scopes to the minimum required for operation.
  • Search for embedded credentials Scan Salesforce objects, notes, and workflow records for API keys, passwords, and tokens, then remove or rotate anything that should never have been stored there.
  • Build a machine-identity inventory Track each OAuth token, service account, and third-party integration as a governed non-human identity with named ownership, revocation criteria, and review cadence.

Bottom line: Stolen OAuth tokens can let attackers impersonate trusted integrations and bypass the normal user login story entirely.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 5 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21566
 

Token trust is the real control plane in SaaS-to-SaaS identity. This incident was not a failure of user authentication but a failure of delegated machine trust. Once an OAuth token is issued, the platform often treats the caller as inherently legitimate even when the token is stolen or repurposed. The implication is that identity governance for SaaS has to shift from account-centric controls to token-centric trust boundaries.

A few things that frame the scale:

A question worth separating out:

Q: What should security teams do after embedded credentials are found in SaaS records?

A: Revoke and rotate the exposed secrets, then assume any downstream system that trusted those credentials may also be at risk. After that, review the surrounding integration scope, access logs, and connected applications to determine whether the original SaaS compromise has created a broader identity chain that needs to be broken.

👉 Read our full editorial: Salesforce and Drift token abuse exposes the NHI trust gap


This post was modified 5 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.