OAuth token abuse across Salesforce, Google Workspace, and AWS

At a glance

What this is: This is an analysis of UNC6395’s expansion from Salesforce into Google Workspace and AWS, showing that active OAuth tokens and connected apps can extend a cloud intrusion across multiple services.

Why it matters: It matters because IAM teams must govern OAuth grants, app allowlists, and token revocation as one control plane across SaaS and cloud, not as isolated admin tasks.

Context

OAuth token abuse becomes a governance problem when a token granted to one connected app can be reused to reach other cloud services. In this case, the campaign moved from Salesforce into Google Workspace and AWS, which means the trust boundary was the OAuth grant itself, not any single application.

For IAM and NHI teams, the key issue is lifecycle control over delegated access. If tokens remain active after a suspected compromise, attackers can continue to move through email, storage, and SaaS integrations while MFA and perimeter controls do little to stop the abuse.

Astrix Security’s findings show that connected-app governance and token revocation are now operational requirements, not optional hardening steps. The starting position for many organisations is still fragile because OAuth grants are often inventoried poorly and reviewed only after an incident.

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. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.

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. Once the token exists, the identity provider may see the request as legitimate, so MFA is no longer part of the transaction.

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. If the only proof of access lives in chat logs or someone’s memory, the control is not working in practice, even if the team believes it is.

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.

Technical breakdown

How OAuth token abuse turns one connected app into many paths

OAuth tokens let a third-party application act on behalf of a user or tenant without re-entering credentials for every action. That makes them efficient for integrations, but also dangerous when the token itself is compromised. In this campaign, the same delegated access model that enabled Salesforce connectivity also gave the actor a route into Google Workspace and, by extension, a path toward AWS reconnaissance and secret hunting. The technical risk is not a single broken login. It is the persistence of trust after initial delegation, especially when tokens are not tied to tight scope, short lifetime, and active review.

Practical implication: treat OAuth grants as privileged access paths and inventory them with the same discipline you use for admin accounts.

Why MFA did not stop the campaign

MFA protects interactive login, but OAuth token abuse bypasses that control because the token already represents an authenticated and authorised session. Once an attacker holds a valid token, the platform sees a permitted client rather than a suspicious password challenge. That is why this campaign could continue even after MFA controls were in place. The failure mode is not weak user authentication at the front door. It is post-authentication abuse of a delegated identity that still has standing access to mailbox, CRM, and cloud resources.

Practical implication: monitor token issuance, token use, and connected-app behaviour, not only human authentication events.

Why connected-app sprawl widens the blast radius

Connected apps and API-linked services create an identity mesh across SaaS and cloud environments. If one grant is compromised, attackers can pivot into adjacent systems that inherit trust from the same integration fabric. Astrix Security’s analysis of suspicious AWS probing and Google Workspace email abuse shows that the campaign was not confined to a single platform. The deeper architectural issue is that many organisations separate SaaS app governance from cloud IAM, even though the attacker only needs one abused grant to reach multiple services.

Practical implication: govern SaaS-to-SaaS and SaaS-to-cloud integrations as part of one identity estate.

Threat narrative

Attacker objective: The attacker aimed to steal data and secrets across connected cloud services while preserving access through delegated OAuth trust.

1. Entry occurred through compromised Salesloft Drift OAuth tokens that were used to access Salesforce organisations during the initial UNC6395 activity.
2. Credential access and abuse followed as the actor harvested secrets and targeted AWS and Snowflake-related material within exfiltrated data.
3. Escalation and lateral movement then expanded into Google Workspace email exfiltration and AWS reconnaissance against publicly accessible S3 resources.
4. Impact was sustained cross-cloud access, with active tokens and chained delegated trust extending the campaign beyond the original Salesforce intrusion.

Breaches seen in the wild

• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

OAuth token revocation is a lifecycle control, not an incident cleanup task: Once a token is active, it can outlive the user action that created it and remain exploitable even after MFA and password resets. That means token lifecycle management belongs in the same operational queue as privileged account governance and offboarding. The practitioner conclusion is that revocation speed and scope are part of access control, not back-end hygiene.

Cloud identity fragmentation creates an identity blast radius: The campaign moved from one compromised integration into email exfiltration and AWS reconnaissance because many organisations manage SaaS grants, cloud roles, and secrets as separate problems. That separation turns a single compromised OAuth app into a wider cross-cloud exposure path. The practitioner implication is that blast radius is governed by how well the organisation sees and constrains delegated trust.

Secret harvesting after token abuse is the hidden second stage: The article shows that attackers did not stop at service access. They used that access to search for AWS and Snowflake secrets, which converts delegated identity compromise into deeper infrastructure reach. The practitioner conclusion is that exfiltrated data must be scanned for embedded credentials immediately, because the true loss often appears after the first access event.

Continuous discovery is now the control that makes every other control usable: Astrix Security’s findings on new indicators and active Google Workspace tokens underline a basic governance problem. If teams cannot continuously discover connected apps, tokens, and service identities, they cannot revoke what they cannot see. The practitioner takeaway is that NHI discovery has become a prerequisite for OAuth governance, not a companion process.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Delegated trust has become the blast radius multiplier: When an OAuth app can move from CRM into mail and cloud access, the organisation’s real exposure is the connected identity fabric, not the first compromised system. That is why access review programmes need to include third-party grants, token owners, and downstream scopes, not just employee accounts.

Identity blast radius: This is the point at which one compromised grant can extend into multiple services because integrations inherit each other’s trust. For practitioners, that means SaaS governance, cloud IAM, and secrets discovery need to be run as one programme rather than separate queues.

The campaign also shows why discovery quality matters before policy quality. If only 5.7% of organisations have full visibility into their service accounts, then revocation and recertification will always lag the attacker’s tempo, especially when abuse flows through OAuth tokens and application credentials.

For practitioners

• 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.
• Scan logs for token abuse and secret hunting Search event monitoring, CloudTrail, and Gmail audit data for anomalous queries, bulk exports, suspicious S3 access attempts, and credential-exposure patterns.
• Enforce least privilege on third-party apps Restrict each connected application to the minimum scope and organisational unit needed, then recertify those scopes on a defined lifecycle cadence.

Key takeaways

• OAuth token abuse can turn a single connected app into a cross-cloud access path that outlives the original compromise.
• The article shows active Google Workspace tokens, AWS reconnaissance, and 183 previously undisclosed Tor exit-node indicators, which points to a widened attack surface rather than a contained incident.
• The practical response is to inventory connected apps, revoke suspect tokens quickly, and treat delegated access as part of NHI governance, not as a separate SaaS admin task.

Key terms

• OAuth Token Abuse: The misuse of valid OAuth access or refresh tokens to gain unauthorized access without repeating the original login. In NHI terms, the token becomes the credential, so the real control problem is issuance, storage, scope, and revocation rather than passwords alone.
• Connected-App Governance: Connected-app governance is the discipline of controlling which third-party applications may access enterprise data and what they may do once connected. It includes ownership, approval, scope review, allowlisting, and revocation, because the integration itself becomes part of the identity perimeter.
• Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.