Notifications
Clear all
Topic starter
11/08/2026 3:23 pm
TL;DR: UNC6040 and UNC6395 are abusing OAuth phishing, overprivileged integrations, and harvested secrets to move from SaaS compromise into data theft and lateral access across connected environments, according to Bishop Fox. The pattern shows that SaaS governance now depends on least privilege, IP restrictions, and visibility into where tokens and credentials actually live.
NHIMG editorial — based on content published by Bishop Fox: LLMjacking and SaaS integration abuse patterns affecting connected applications
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when SaaS integrations are granted broad OAuth scopes and shared profiles?
A: Broad OAuth scopes and shared integration profiles turn a single compromise into multi-application access.
Q: Why do distributed SaaS environments create NHI risk?
A: Because SaaS automation relies on machine-like access paths such as OAuth grants, API keys, and service accounts.
Q: What do security teams get wrong about least privilege in SaaS and cloud environments?
A: Teams often treat least privilege as a role design exercise when the real problem is entitlement drift across multiple identities.
Practitioner guidance
- Inventory SaaS integration accounts and delegated grants Build a live register of every OAuth app, service account, API key, and cross-app grant in scope.
- Reduce integration privilege to explicit business scope Remove broad object access, shared profiles, and unused API permissions from SaaS integrations.
- Monitor for secret reuse across SaaS and cloud Search for tokens and credentials that appear in multiple applications, logs, or automation paths.
What's in the full article
Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for identifying risky SaaS integrations and the permissions they inherited over time
- Specific detection ideas for spotting interactive attacker activity, token reuse, and SaaS-originated cloud access
- Practical examples of IP restriction, access scoping, and monitoring controls for customer-owned SaaS configurations
- The live fireside chat format with Brian Soby and Christie Terrill for direct practitioner questions
👉 Read Bishop Fox's analysis of SaaS integration abuse and secret harvesting →
SaaS integration abuse and secret harvesting: are controls keeping up?
Explore further
11/08/2026 3:33 pm
Integration accounts are now high-value NHIs, not low-risk plumbing. The article shows that SaaS integrations can become the attacker’s durable access layer once OAuth grants, API keys, or service tokens are captured. That means these accounts need the same lifecycle ownership, scope review, and revocation discipline applied to any other privileged machine identity. Treating them as background configuration leaves the real trust boundary ungoverned.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a SaaS integration exposes customer data?
A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.
👉 Read our full editorial: SaaS integration abuse is exposing secrets across connected apps
