OAuth token abuse across Salesforce, Google Workspace, and AWS

At a glance

What this is: Astrix Security reports that UNC6395 expanded a Salesloft Drift OAuth-token campaign into Google Workspace and AWS activity, exposing how chained third-party access can move laterally across cloud services.

Why it matters: IAM teams need to treat OAuth grants, connected apps, and harvested secrets as one governance surface because compromise in one cloud can quickly become cross-platform NHI abuse.

By the numbers:

• Astrix Security identified 183 previously undisclosed IP-based indicators of compromise in the expanded campaign.
• During the August 8 to 18, 2025 campaign window, UNC6395 leveraged compromised OAuth tokens to infiltrate Salesforce organizations.

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

Context

OAuth token abuse is a non-human identity problem because the token, not the person, becomes the operative identity across SaaS and cloud services. In this campaign, a compromised third-party integration let an attacker move from one trusted app relationship into multiple environments, including Salesforce, Google Workspace, AWS, and Snowflake.

The governance gap is not limited to token theft. Once a connected application can read mail, query data, or reach cloud resources, the organisation has to manage consent scope, revocation, logging, and downstream secret exposure as one access lifecycle.

Key questions

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. Then review connected-app scopes, audit pre-revocation activity, and search downstream logs for secret exposure or secondary access. The important question is whether the delegated identity still has any live path into mail, storage, or cloud APIs.

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. If the token is stolen, the attacker can use the app’s existing authority to access data, query APIs, or harvest secrets across platforms. That is a governance problem, not only an authentication problem, because one consent decision can create a cross-cloud blast radius.

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. A breach often becomes more dangerous after exfiltration if the stolen material contains reusable identities. The right signal is not just volume of data taken, but whether that data includes active secrets that can pivot into other systems.

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.

Technical breakdown

How OAuth tokens become a cross-cloud access path

OAuth tokens inherit the permissions that were granted to the application at consent time. If the token is stolen or the app is abused, the attacker does not need to break the target platform’s core authentication controls. Instead, they operate inside an authorised delegation path and can query mail, pull data, or call APIs exactly as the app was allowed to do. In this case, the threat is amplified when the application bridges multiple services, because one compromised grant can expose several separate control planes at once.

Practical implication: inventory connected applications and verify the exact scopes each grant can reach.

Why harvested secrets turn exfiltration into broader cloud compromise

The campaign did not stop at data theft. Astrix describes systematic secret scanning within exfiltrated material, which turns stolen content into a discovery engine for AWS keys, Snowflake credentials, and other reusable access material. That matters because secrets found in documents, messages, or exports are often valid outside the system they were copied from. Once discovered, they can be used for reconnaissance, bucket probing, or lateral movement into adjacent environments.

Practical implication: scan exfiltrated datasets for secrets and treat downstream credential exposure as a separate incident.

Why Google Workspace OAuth abuse changes the containment problem

The Google Workspace component shows that OAuth compromise can persist after the original application is revoked in one environment. If a related integration remains active elsewhere, the attacker may still have a live path into mail or collaboration data. That creates a containment problem across administrative domains, not a single product problem. The technical question is no longer only whether tokens were stolen, but whether every grant tied to the same application family has been identified, blocked, and audited for use before revocation.

Practical implication: block the app across every tenant or workspace where it was authorised and review pre-revocation activity.

Threat narrative

Attacker objective: The attacker aimed to convert one compromised SaaS integration into reusable access across cloud services, exposing data and harvesting credentials for broader intrusion.

1. Entry began with compromised Salesloft Drift OAuth tokens that allowed UNC6395 to access Salesforce environments through an authorised app relationship.
2. Credential access followed when the actor exfiltrated data and scanned the resulting material for AWS and Snowflake secrets that could be reused elsewhere.
3. Escalation occurred as the actor expanded into Google Workspace email exfiltration and AWS reconnaissance against publicly accessible S3 buckets.
4. Impact came from chained OAuth abuse, harvested credentials, and broader cloud visibility that allowed the campaign to span multiple platforms without breaking the initial delegation model.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

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.

Secret harvesting turns exfiltration into identity reuse. The material stolen from one cloud often contains the keys to the next one, which is why secret scanning inside breached data is not optional background hygiene. The failure mode here is not simply data loss but credential re-entry into other systems through AWS and Snowflake access paths. The implication is that incident response must track secrets as live identities, not as static artifacts.

Cross-cloud OAuth abuse exposes a chained trust deficit. The campaign worked because one trusted integration could be used as a bridge into multiple environments without a fresh governance decision at each step. That means revocation, monitoring, and application allowlisting cannot be managed in silos if the same app family touches several platforms. Practitioners should rethink connected-app governance as a single cross-domain control plane.

Identity blast radius grows when third-party grants outlive the original security decision. The original consent was made for a bounded business purpose, but the access became a moving target once tokens were stolen and reused elsewhere. The breach shows how quickly a narrow delegated relationship can turn into a broad exposure window across cloud estates. Teams need to map which identities can touch which systems after consent, not just at consent time.

Compromised OAuth tokens are effectively non-human identities with delegated authority. That makes them subject to the same lifecycle expectations as service accounts and API keys, including revocation, scoping, logging, and periodic validation. The issue is not whether the token was issued by a legitimate service, but whether its current reach still matches the intended business use. Practitioners should govern them like privileged machine identities, not like incidental app settings.

From our research:

• 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.
• For a broader lifecycle view, Top 10 NHI Issues helps teams map consent, visibility, and revocation gaps before the next delegated access chain is exploited.

What this signals

Identity blast radius is now the right organising concept for connected-app governance. When one OAuth grant can reach CRM, email, storage, and cloud APIs, the real control question is how far a compromised identity can travel before governance detects it. That is why connected-app review should be treated as a high-risk access programme, not an application-admin task.

More organisations are funding NHI controls, but maturity still lags behind attacker reuse patterns. According to The State of Non-Human Identity Security, 1 in 4 organisations are already investing in dedicated NHI security capabilities, and another 60% plan to do so within twelve months. The gap is that investment does not automatically produce revocation discipline, secret discovery, or full OAuth visibility.

Chained OAuth abuse is a strong fit for the Top 10 NHI Issues lens. Visibility gaps, over-privileged access, and weak rotation all appear in this campaign’s pattern of token theft, secret harvesting, and cross-cloud movement. Teams should use Top 10 NHI Issues to prioritise which controls to close first, especially where third-party grants bridge multiple environments.

For practitioners

• 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. Focus on Google Workspace, Salesforce, and any other SaaS tenant that shared the integration.
• 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. Treat every discovered secret as a separate identity that needs containment.
• 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. Remove stale integrations that can still reach mail, storage, or cloud APIs.
• Correlate CloudTrail and SaaS audit logs around the campaign window Look for S3 bucket probes, anomalous bulk exports, and accesses originating from the suspicious AWS account ID or Tor exit-node IPs tied to the campaign. Use the same timeline across all platforms to spot lateral movement.

Key takeaways

• This campaign shows that compromised OAuth grants can become a cross-cloud access path, not just a single-application incident.
• The scale matters because exfiltrated data can contain the next set of credentials, turning theft into reuse across AWS, Google Workspace, and SaaS platforms.
• The control that would have reduced the blast radius is lifecycle governance for connected apps, including scope review, revocation, and secret scanning.

Key terms

• OAuth token: An OAuth token is a delegated credential that lets an application act on a user’s or service’s behalf without re-authentication. In NHI governance, it must be treated like a live machine identity because its scope, lifetime, and revocation state determine how far an attacker can move if it is stolen.
• Connected app: A connected app is a third-party application that has been granted access to a platform such as Salesforce or Google Workspace. It is not just an integration setting. It is a governance object whose consent scope, logging, and offboarding determine whether the app becomes a controlled dependency or a lateral-movement path.
• Secret harvesting: Secret harvesting is the process of searching stolen data for reusable credentials such as API keys, tokens, and certificates. In practice, it turns a data breach into identity compromise because the attacker can pivot from copied content into live access in other systems, often before the organisation finishes its first containment step.
• Identity blast radius: Identity blast radius is the amount of access an identity can reach if it is abused, stolen, or mis-scoped. For non-human identities, the metric is defined by delegation chains, app permissions, and downstream secrets, not by a person’s account history or login frequency.

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.

👉 Astrix Security's full post covers the expanded attack surface, IoCs, and containment guidance for the UNC6395 campaign.

Deepen your knowledge

OAuth token governance across SaaS and cloud services is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is dealing with connected-app sprawl, it is a practical next step.