Join our Newsletter — 33% off our NHI Course

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

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 20739
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.

Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “Critical Update: Astrix Research Team Discovers UNC6395 OAuth Compromise Spanning Salesforce, Google Workspace, and AWS”.

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 OAuth tokens bypass MFA in real attacks?

A: OAuth tokens bypass MFA because the attacker reuses a valid authorization artifact after it has already been issued.

Q: How do you know if disconnected app governance is actually working?

A: Look for complete application inventory, documented ownership, timely revocation after departure, and audit-ready evidence for each critical account.

Practitioner guidance

  • Review and block high-risk OAuth grants Identify connected applications with broad mailbox, CRM, or cloud permissions and block any grant that cannot be justified by current business use.
  • Revoke and rotate suspect tokens first Treat compromised OAuth tokens as standing credentials and revoke them before performing broader account remediation or user reauthentication.
  • Audit SaaS-to-cloud integration paths Map which connected apps can reach Google Workspace, Salesforce, AWS, and other adjacent services so one compromise cannot cross unchecked between them.

Bottom line: OAuth token abuse can turn a single connected app into a cross-cloud access path that outlives the original compromise.

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: 21545
 

Delegated access, not the application boundary, is the real trust boundary: This campaign shows that connected-app governance now defines exposure more clearly than the underlying SaaS platform. When an OAuth grant can be reused across Salesforce, Google Workspace, and AWS-adjacent activity, the security question shifts from app hardening to delegated identity control. The practitioner takeaway is that integration inventory and grant review are now frontline controls.

A few things that frame the scale:

  • Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

A question worth separating out:

Q: What should teams do when OAuth abuse reaches email and cloud storage?

A: Contain the affected grants first, then review logs for bulk export, mailbox access, and storage reconnaissance before broader cleanup begins. The objective is to stop the delegated identity path that the attacker is using, while preserving evidence for scope assessment and downstream secret rotation.

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


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.