Summary

In mid‑August 2025, the Google Threat Intelligence Group (GTIG) confirmed a large‑scale credential‑harvesting and data‑theft campaign targeting organizations through their Salesforce instances. Attackers systematically siphoned sensitive business data (Accounts, Cases, Users, Opportunities), actively searched for secrets like AWS keys and Snowflake tokens, and leveraged Tor exit nodes to obfuscate their operations.

The campaign, attributed to UNC6395, leveraged stolen OAuth tokens from the trusted third‑party application Salesloft Drift, pivoting across multiple integrations and exfiltrating sensitive corporate data. This supply‑chain attack didn’t target Salesforce directly.

Instead, attackers compromised the Drift chatbot and hijacked its authorized access to third-party victims by abusing long‑lived, overly permissive, and poorly scoped OAuth tokens, exactly the scenario we warned about in our Illicit Consent‑Granting post.

This breach is a textbook example of that scenario becoming reality. See: Illicit Consent‑Granting & App Backdooring – Obtaining persistence in Entra.

The breach unfolded in several layers:

1. Initial compromise of Drift OAuth tokens.
2. Mass querying of Salesforce objects (Account, Case, User, Opportunity).
3. Harvesting of embedded secrets (AWS keys, Snowflake tokens, VPN URLs).
4. Lateral expansion into Drift Email → Google Workspace accounts.

This post reconstructs the attack flow, maps the campaign against the MITRE ATT&CK framework, and outlines detection + defense measures enterprises must take immediately.

The incident highlights the danger of over-permissive SaaS integrations and the critical need to restrict OAuth access.

Why does this matter?

Salesforce is often the single source of truth for customer data: opportunities, revenue pipelines, support cases, and executive contact info. Compromise here is devastating. Worse, Salesforce often becomes a secret graveyard: API keys pasted into case notes, passwords sent between reps, Snowflake tokens shared for quick data pulls.

UNC6395 understood this perfectly. By querying Salesforce and systematically pulling records, the attackers weren’t just after names and emails — they were after the secret keys to the kingdom, access tokens. And by leveraging OAuth, they bypassed the usual controls: no phishing, no MFA prompts, no password brute‑forcing, no anomalous login attempt detection. Just a token.

An estimated 700 companies were affected, including major tech organizations such as Cloudflare, Zscaler, and Palo Alto Networks. While the initial focus was Salesforce, GTIG later warned that other platforms connected via Drift—including Google Workspace, Slack, AWS, Microsoft Azure, OpenAI, and Amazon S3—might also be compromised.

This is not the first time Salesforce environments have been targeted at scale. In August 2025, GTIG documented UNC6040 abusing vishing and malicious connected apps (e.g., modified Data Loader) to exfiltrate Salesforce data and later extort victims under the “ShinyHunters” name. The trend is clear: attackers don’t need to break Salesforce itself; they exploit the trust model around integrations and user permissions.

A few takeaways that stand out:

1. To our knowledge, no exploits were used at any point.

2. Attackers leveraged valid tokens that typically don’t create new login events in audit logs, evading many login‑based SOC detections.

3. Much of the activity came from reputable cloud infrastructure, making IP‑reputation‑based detections significantly harder.

4. How the breach was first detected remains unclear; given the attempted Gmail access via the Drift extension, it may have been surfaced by Google’s SOC—suggesting many victims lacked the means to detect it themselves.

5. Drift isn’t unique here: many OAuth 2.0 apps are over‑permissioned because available scopes aren’t fine‑grained enough.

Overall, this breach underscores a newer, stealthier class of SaaS‑to‑SaaS intrusions—harder to spot than traditional endpoint/CSP incidents and covered by far fewer SOC detection capabilities.

What is Drift, and what does it have access to

Drift is a conversational AI product that has extensive capabilities for Salesforce, including:

1. Create and update Leads in SFDC that originate in Drift
2. Create and update Contacts in SFDC that originate in Drift
3. Send chat activity from Drift to SFDC
4. Send meetings booked in Drift to SFDC

As a result, Drift requests extensive permissions in Salesforce. In particular, a Drift integration can do the following:

Given the extensive permissions, it is no wonder that Drift makes for a perfect target for an attacker

Attack Flow

High‑level sequence:

1. Compromise trusted third‑party (Drift) and harvest OAuth tokens.
2. Authenticate to Salesforce via valid tokens; enumerate and bulk‑query core objects.
3. Mine embedded secrets from exports; operationalize access to cloud/data platforms.
4. Pivot via Drift Email into scoped Google Workspace accounts; expand blast radius.

This breach didn’t target Salesforce directly. Instead, attackers compromised a trusted third-party integration, Salesloft’s Drift chatbot, and hijacked its authorized access to downstream systems. This is a supply-chain style compromise where OAuth trust relationships become the weakest link.

That’s exactly what makes this a devastating supply-chain attack: one vulnerable integration triggered a cascade across hundreds of organizations.

One vulnerable integration triggered a cascade across hundreds of organizations — a classic supply‑chain failure of OAuth trust relationships.

A similar supply‑chain heist (Bybit, Feb 2025)

A comparable attack in February 2025 led to one of the largest crypto heists: ~400,000 ETH were stolen from Bybit after attackers compromised its trusted provider Safe{Wallet} by infiltrating a developer environment with stolen AWS session tokens. UI manipulation tricked signers into approving a malicious transaction that redirected funds to attacker wallets. The pattern: trusted third‑party → stolen tokens → authorized abuse.

Tools in the attacker’s toolbox

• Stolen OAuth tokens
• Standard Salesforce SOQL queries
• Tor for anonymity
• Automated fetchers (User‑Agents like Salesforce-Multi-Org-Fetcher/1.0, python-requests/2.32.4)

MITRE ATT&CK Mapping

• T1528 – Steal Application Access Token
• T1078 – Valid Accounts
• T1530 – Data from Cloud Storage
• T1552 – Unsecured Credentials

Attack Lifecycle

Phase 1: Initial Access

Attackers obtained valid OAuth tokens from Drift. From Salesforce’s perspective, these were trusted, legitimate sessions—no exploits against Salesforce or Google required.

While early hypotheses pointed to phishing/social engineering, subsequent findings indicate a different root cause.

Mandiant’s investigation has since clarified that between March and June 2025, the threat actor accessed Salesloft’s GitHub account, where they downloaded repositories, added a guest user, and established workflows. This activity led to Drift’s AWS environment being accessed, which ultimately gave the attackers OAuth tokens for Drift customers’ integrations. So, this was how the Drift OAuth tokens were compromised.

Bottom line: the breach didn’t begin with Salesforce or Drift OAuth tokens — it began months earlier in GitHub, cascading into Drift OAuth abuse.

Phase 2: Salesforce Access & Data Harvesting

With tokens in hand, attackers started to perform recon in the environment. Based on the Cloudflare write-up on the incident, we know that the attackers would perform the following actions:

1. Send a GET request for a list of objects in the Salesforce tenant: /services/data/v58.0/sobjects/
2. Send a GET request for metadata information for case objects in the Salesforce tenant: /services/data/v58.0/sobjects/Case/describe/
3. A series of systematic SOQL queries:

SELECT COUNT() FROM Account;
SELECT COUNT() FROM Opportunity;
SELECT COUNT() FROM User;
SELECT COUNT() FROM Case;

4. They pulled full User tables, complete with emails, names, phone numbers, and login timestamps:

SELECT Id, Username, Email, FirstName, LastName, Name, Title, CompanyName, Department, Division, Phone, MobilePhone, IsActive,
       LastLoginDate, CreatedDate, LastModifiedDate, TimeZoneSidKey, LocaleSidKey, LanguageLocaleKey, EmailEncodingKey
FROM User
WHERE IsActive = true
ORDER BY LastLoginDate DESC NULLS LAST
LIMIT 20;

Phase 3: Secret Mining & Covering Tricks

After exfiltrating bulk Salesforce data, UNC6395 hunted for embedded credentials and tokens to extend the compromise beyond Salesforce.

Likely techniques:

• Regex scrapers for known credential formats.
• TruffleHog / Gitleaks‑style scans for entropy‑heavy strings, AWS patterns, API key regexes.

Common patterns:

AKIA[0-9A-Z]{16}                  # AWS Access Key
snowflakecomputing\.com           # Snowflake domain references
(password|secret|key)\s*[:=]      # Generic key-value credential markers

Once stolen, these secrets enable:

• Cloud Compromise – AWS keys let attackers spin up EC2 instances, exfiltrate S3 buckets, or pivot into the broader cloud estate.
• Data Warehouse Breaches – Snowflake tokens allow queries into sensitive analytics data.

Critically, attackers routinely weaponize cloud infrastructure itself once they gain valid access. For example, IP address 44.215.108.109, traced back to Amazon AWS (AS14618), but was flagged only by two vendors as “Malicious” or “Suspicious,”.

This show how attackers routinely expand their real estate:

• AWS keys or cloud accounts can be abused to spawn disposable EC2 instances.
• Those instances then act as staging servers for exfiltration or further attacks.
• Because the traffic originates from “legitimate” AWS IPs, it often evades enterprise IP reputation blocks.

This example highlights the downstream impact of the Salesforce – Drift compromise: attackers weren’t just stealing data; they were turning secrets into infrastructure to sustain operations.

Phase 4: Expansion & Fallout — Drift Email → Google Workspace

UNC6395 didn’t stop at Salesforce. They realized that OAuth trust relationships through Drift could extend into other ecosystems — and the Drift Email integration was the next pivot.

• Aug 9, 2025: Using compromised Drift OAuth tokens tied to Drift Email, attackers gained scoped access to a subset of Google Workspace accounts integrated with Drift (not domain‑wide; only explicitly connected accounts).
• Aug 28, 2025: Google revoked affected OAuth tokens and disabled the Drift Email integration, cutting off this pivot.

(Bonus) Covering Tracks: Deleting Jobs… but Leaving Footprints

Attackers deleted query jobs after exfiltration to make it harder for incident responders to quickly see “large export jobs” or unusual query activity. To a casual admin, it would appear as if nothing abnormal was scheduled.

Even though the job objects were removed, the underlying event logs persisted. Salesforce logs record the fact that queries were run, including timestamps, User-Agent strings, and IP addresses. So while first-response visibility was degraded, forensic teams with log access could still reconstruct attacker activity.

What This Tells Us About UNC6395?

1. They’re operationally mature: not smash-and-grab amateurs.
2. They assumed many orgs don’t actively parse or monitor Salesforce logs in real time.
3. Their tactic was “slow down the defenders, not stop them entirely.”

What this tells us about UNC6395

• Operationally mature—far from smash‑and‑grab.
• They assume many orgs don’t parse Salesforce logs in real time.
• Their tactic: slow down defenders rather than stop visibility entirely.

Locking the doors — lesson learned

Unlike passwords, tokens are invisible to users and bypass MFA. Without strict monitoring and short lifespans, they become a silent backdoor into cloud systems.

Response Actions

Immediate Response (Google)

• Revoke all Drift OAuth tokens
• Rotate all Salesforce API keys, AWS keys, Snowflake tokens
• Disable Drift integration

Response (Salesloft + Mandiant)

• Took Drift offline and rotated credentials.
• Hardened the Salesloft environment against observed TTPs.
• Verified Drift–Salesloft segmentation to ensure no lateral compromise.
• Conducted forensic QA to confirm containment.

Long‑Term Hardening

• Reduce session lifespans for OAuth tokens.
• Treat OAuth tokens like privileged accounts; monitor and protect them accordingly.
• Rotate refresh tokens regularly; prefer short‑lived tokens with tight scopes.

Detection in Practice: Spotting Unusual SOQL Queries

Attackers relied on mass SOQL to exfiltrate at scale. Normal integrations fetch dozens/hundreds of records—not tens of thousands.

SELECT EventType, CreatedDate, UserId, RowsProcessed, RowsReturned, ClientIp, USER_AGENT
FROM EventLogFile
WHERE EventType = 'API'
AND RowsReturned > 10000
AND CreatedDate = LAST_N_DAYS:7

Defender actions:

• Monitor Salesforce EventLogFile for abnormal query volumes, unusually broad SELECT queries, and high‑rate API access.
• Alert on atypical User‑Agents and authentication from Tor/AWS IP ranges.
• Correlate spikes in queries with token issuance/refresh events from Drift.

Indicators of Compromise (IOCs)

Malicious / Suspicious User‑Agents

• Salesforce-Multi-Org-Fetcher/1.0
• Salesforce-CLI/1.0
• python-requests/2.32.4
• Python/3.11 aiohttp/3.12.15

Observed IPs

• 44.215.108.109 (AWS)
• 208.68.36.90 (DigitalOcean)
• Multiple Tor exit nodes (e.g., 185.220.x.x, 192.42.x.x)

Conclusion

OAuth trust relationships can become the weakest link in cloud ecosystems. UNC6395 exploited Drift’s access to quietly drain Salesforce data and weaponize embedded secrets, then pivot into connected platforms.

Do now:

• Revoke/rotate tokens and keys; disable unnecessary integrations.
• Shorten token lifetimes; tighten scopes; treat tokens as high‑privilege credentials.
• Continuously monitor Salesforce logs for bulk queries, unusual User‑Agents, and suspicious IPs.

Identity is the new perimeter.