Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

OAuth token abuse across cloud apps: what IAM teams need to know


(@astrix)
Estimable Member
Joined: 1 year ago
Posts: 78
Topic starter  

TL;DR: UNC6395 expanded beyond the original Salesforce intrusion to Google Workspace and AWS activity, with 183 new Tor exit-node indicators and continued use of active Google Workspace OAuth tokens, showing how chained third-party access can extend a campaign across cloud services, according to Astrix Security research. Credential revocation, app allowlisting, and connected-app review now sit at the center of NHI governance.

NHIMG editorial — based on content published by Astrix Security covering the UNC6395 OAuth token campaign: LLMjacking and cross-cloud abuse through compromised NHIs

By the numbers:

Questions worth separating out

Q: What should security teams do when an OAuth token used by a SaaS integration is compromised?

A: Treat the token as a privileged non-human identity and revoke it everywhere it is authorised, not just in the first affected system.

Q: Why do third-party OAuth grants create more risk than a single application login?

A: Because the grant can span multiple services and inherit broad permissions without repeated authentication checks.

Q: How do security teams know whether exfiltrated data contains credentials that can be reused elsewhere?

A: They need to scan exports, attachments, logs, and archived content for tokens, API keys, certificates, and cloud credentials.

Practitioner guidance

  • Revoke and re-authorise connected apps across every cloud tenant Find all Drift-related grants, block the app where it is still authorised, and confirm that no lingering OAuth consent survives in other workspaces or business units.
  • Scan breached exports for usable secrets before closing the incident Search email archives, CRM exports, logs, and downloaded files for AWS keys, Snowflake credentials, tokens, and certificates that may have been embedded in exfiltrated content.
  • Tighten connected-app allowlisting and scope review Verify that only approved applications remain authorised and that each one is limited to the minimum scopes needed for the business function.

What's in the full article

Astrix Security's full blog post covers the operational detail this post intentionally leaves for the source:

  • The full indicator-of-compromise set for the expanded UNC6395 activity, including the AWS account ID and Tor exit-node list.
  • The step-by-step Google Workspace blocking workflow for the Drift Email application.
  • The campaign-specific CloudTrail and Gmail audit log patterns that help distinguish benign access from malicious probing.
  • The collaboration details with GTIG that explain how the token abuse was validated across platforms.

👉 Read Astrix Security's analysis of the expanded UNC6395 OAuth token campaign →

OAuth token abuse across cloud apps: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 weeks ago
Posts: 1804
 

OAuth consent sprawl is now an access-control problem, not just an app-inventory problem. Once a third-party application can span CRM, mail, storage, and analytics, the grant itself becomes the security boundary. This campaign shows that a single delegated identity can fan out across several cloud control planes before anyone realises the scope. Practitioners should treat connected-app consent as a privileged access surface, not a convenience layer.

A few things that frame the scale:

  • 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
  • Our research also found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which matches the low maturity exposed by cross-cloud OAuth abuse.

A question worth separating out:

Q: Who is accountable when a compromised SaaS integration is used to move across multiple clouds?

A: Accountability sits with the teams that own connected-app governance, SaaS administration, and cloud identity controls, because the failure crosses system boundaries. A single platform team cannot see the whole path. Organisations should map responsibility for consent, revocation, logging, and secret response before the next integration is authorised.

👉 Read our full editorial: OAuth token abuse across Salesforce, Google Workspace, and AWS



   
ReplyQuote
Share: