TL;DR: Attackers used stolen OAuth tokens from a trusted third-party integration to query Salesforce at scale, harvest embedded secrets, and pivot into connected systems, according to SlashID’s analysis of the UNC6395 campaign and Google Threat Intelligence Group reporting. The breach shows that OAuth trust boundaries, not just login controls, now define the real attack surface for identity teams.
NHIMG editorial — based on content published by SlashID: LLMjacking and OAuth token theft in Salesforce-connected environments
By the numbers:
- Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
Questions worth separating out
Q: What breaks when third-party OAuth integrations are over-scoped?
A: Over-scoped integrations turn delegated access into an attacker-controlled session with too much reach.
Q: Why do SaaS-to-SaaS compromises create such a large blast radius?
A: Because a single trusted integration often connects multiple business systems, one stolen token can inherit access across several services.
Q: How do security teams know when OAuth access is operating outside its intended boundary?
A: Watch for bulk object enumeration, unusual query shapes, repeated exports, and token use from cloud infrastructure or Tor exit nodes that do not match normal integration behaviour.
Practitioner guidance
- Re-scope every third-party OAuth grant Inventory SaaS integrations, identify over-broad delegated permissions, and remove any scope that is not required for the integration’s exact job.
- Treat tokens as privileged credentials Set shorter token lifetimes, rotate refresh tokens, and alert on token reuse from unfamiliar infrastructure.
- Block secrets from business systems Prevent AWS keys, Snowflake tokens, passwords, and VPN URLs from being stored in Salesforce records, case notes, or exports.
What's in the full article
SlashID's full research covers the operational detail this post intentionally leaves for the source:
- The full attack sequence from GitHub compromise to Drift token theft, including how the token source was exposed.
- Concrete SOQL query patterns and EventLogFile hunting logic for spotting bulk Salesforce enumeration.
- The exact user-agent strings and IP patterns observed during the campaign, useful for detection engineering.
- Step-by-step response actions for revoking tokens, disabling integrations, and validating containment across connected systems.
👉 Read SlashID's analysis of the Salesforce OAuth token theft campaign →
Salesforce OAuth token theft: what over-scoped integrations change?
Explore further
Standing OAuth trust was designed for stable delegation, not silent post-compromise reuse. This campaign worked because the integration’s delegated access remained valid after the trust boundary changed. The practical lesson is that consent, not authentication alone, is the durable control plane for SaaS-to-SaaS identity risk.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase, according to the Guide to the Secret Sprawl Challenge.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
A question worth separating out:
Q: Who is accountable when a third-party integration is used to steal business data?
A: Accountability is shared, but the enterprise still owns the trust decision. Security, IAM, and application owners must review consent scopes, token lifetimes, and vendor offboarding because delegated access is part of the company’s identity perimeter. If a platform can retain access after the relationship changes, the governance failure remains internal.
👉 Read our full editorial: Salesforce OAuth token theft shows the cost of over-scoped integrations