Topic starter
29/08/2025 11:56 am
TL;DR: Google Threat Intelligence Group said UNC6395 used stolen OAuth tokens from the Salesloft Drift app to access Salesforce orgs, export data, and hunt for AWS keys and Snowflake tokens, showing how trusted integrations can become credential-harvesting paths, according to Astrix Security. The incident reinforces that NHI governance must treat third-party tokens as durable attack surface, not just application plumbing.
Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “Lessons from the GTIG Advisory on the Salesforce OAuth Token Breach”.
Key questions
Q: Who is accountable when a SaaS integration token is stolen?
A: Accountability should be shared, but operational ownership must be explicit.
Q: Why do delegated NHI tokens create more risk than direct user login in SaaS?
A: Delegated tokens can outlive the login session that created them and often retain access until explicitly revoked.
Q: What do security teams get wrong about OAuth and connected apps?
A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust.
Practitioner guidance
- Inventory all OAuth-connected apps Build a complete list of third-party integrations connected to Salesforce and other business SaaS platforms, then identify which tokens can export data or read sensitive objects.
- Revoke and reissue standing tokens Remove tokens that are no longer required, shorten token lifetimes where possible, and define an emergency revocation path for compromised integrations.
- Scope integration permissions to minimum access Review each connected app for object-level and export permissions, then remove any access that is not required for the app's actual function.
Bottom line: The core risk is not the Salesforce platform itself but the delegated trust granted to a third-party OAuth token.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/10/2026 5:04 pm
Delegated OAuth access is part of the NHI attack surface, not a separate application convenience layer. The campaign shows that a third-party token can function as a durable identity with enough privilege to expose business data and search for secrets. That makes SaaS-to-SaaS connectivity a governance domain, not a simple integration feature. Practitioners should classify these tokens with the same seriousness they apply to service accounts and other non-human credentials.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations respond when a third-party Salesforce integration leaks secrets?
A: Contain the integration first by revoking the affected tokens, then check whether the exported or queried data contains reusable credentials such as cloud keys or API tokens. After containment, review whether the integration had broader object access than needed and whether similar connections exist elsewhere in the SaaS estate.
👉 Read our full editorial: Salesforce OAuth token abuse shows the NHI trust gap in integrations