Incident Analysis

Salesloft Drift OAuth Breach: 700+ Salesforce Tenants Compromised

UNC6395 stole Salesloft Drift OAuth tokens to exfiltrate Salesforce data from more than 700 organisations including Cloudflare, Zscaler, and Palo Alto Networks in August 2025.

Nayan Dey
Senior Security Engineer
6 min read

On August 26, 2025, Google's Threat Intelligence Group (Mandiant) published an emergency advisory naming a cluster it tracks as UNC6395 as responsible for "widespread data theft" against Salesforce customer instances accessed through the Salesloft Drift third-party integration. The campaign ran from at least August 8 through August 18, 2025. Salesloft revoked all active Drift access and refresh tokens on August 20, and Salesforce pulled the Drift application from its AppExchange the same week. Confirmed victim notifications now exceed 700 organisations, including Cloudflare, Google's own Workspace business, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium, and Zscaler. The breach is not interesting because it owned a famous Salesforce tenant; it is interesting because it owned an OAuth identity that a thousand tenants had silently delegated to.

Who is UNC6395 and how did they get the tokens?

Mandiant first associated the cluster (also tracked as GRUB1) with credential-harvesting and OAuth-token abuse against AI-assistant integrations in mid-2025. Initial access to Salesloft itself has not been publicly confirmed, but Google's threat intel team and Salesloft's joint statement on September 7 attribute the original theft to compromised credentials in the Salesloft engineering environment. The attacker exfiltrated long-lived OAuth refresh tokens issued by Salesforce to the Drift integration. Drift, a conversational marketing tool acquired by Salesloft in February 2024, holds a Connected App in customer Salesforce orgs with api, refresh_token, offline_access, and frequently full OAuth scopes. With a refresh token in hand and the Drift consumer key/secret, UNC6395 could mint short-lived bearer tokens against the customer's login.salesforce.com endpoint indefinitely until the integration was disabled.

What did the attackers do inside Salesforce?

Telemetry from Cloudflare's own breach disclosure (September 2, 2025) shows the actor ran SOQL queries against Case, Account, Contact, and User objects, then exported results as bulk API jobs. Unit 42 observed the actor specifically grepping support-case text for strings like AKIA, password, secret, xoxb-, BEGIN PRIVATE KEY, and snowflakecomputing.com — classic infostealer post-processing. The campaign's objective was second-order: harvest secrets that customers had pasted into support tickets, then pivot into AWS, Snowflake, VPN gateways, and other tenants. PagerDuty, Tanium, and Zscaler each confirmed that no production systems were compromised, only Salesforce-resident metadata. Cloudflare disclosed that 104 of its own API tokens were exposed inside customer-pasted ticket text and rotated all of them within 72 hours.

How long was the window and why wasn't it caught sooner?

The earliest indicator-of-compromise date Mandiant published is August 8, 2025. Salesloft was notified by Google's TAG on August 20. That gives a 12-day acquisition window during which the actor scraped data from organisations one by one — Mandiant noted the API calls came from a small set of Tor exit nodes and DigitalOcean droplets and were paced at roughly two requests per second per tenant to avoid Salesforce's anomaly detection. Salesforce Event Monitoring (a paid add-on most customers do not enable) would have shown unusual bulk-API volume from the Drift connected app, but Drift legitimately makes high-volume calls, so the deviation was inside noise. The fundamental gap is that OAuth refresh tokens in Salesforce default to never expiring; the platform's "Refresh Token Policy" can be set to "Refresh token is valid until revoked" with no time-bound. Most Connected Apps shipped by ISVs use that default.

What about the Drift email integration and Google Workspace?

On August 28, 2025, Mandiant updated its blog post to confirm the actor also abused Drift Email's Google Workspace integration to read messages in a "very small number" of mailboxes. Google revoked the Drift Email tokens and reset the integration. This is the cascade that worries SaaS defenders: one stolen ISV credential pair compromised two tier-1 SaaS platforms simultaneously because both used the same OAuth trust anchor.

# Salesforce Connected App hardening baseline for high-risk integrations
ConnectedApp:
  oauthConfig:
    isAdminApproved: true                 # admin-pre-approved only, no end-user consent
    refreshTokenPolicy: expire_after_24h  # NOT "valid until revoked"
    ipRanges:                             # restrict to vendor egress
      - startIpAddress: 52.x.x.0
        endIpAddress: 52.x.x.255
    requireSecretForRefreshTokenFlow: true
    requireSecretForWebServerFlow: true
  permissionSets:
    - Drift_Read_Only_Limited              # never grant 'Modify All Data' or 'full'
  customAttributes:
    require_mfa: "true"

What did existing controls miss?

Five honest failure modes. First, no out-of-band attestation of vendor OAuth scopes; security teams approved Drift years ago and never re-reviewed the scope drift after the Salesloft acquisition added new capabilities. Second, no detection on bulk SOQL exports from third-party connected apps. Third, no DLP on support-ticket text — engineers and customers paste secrets into Case.Description all day. Fourth, Connected App secrets stored statically inside ISV infrastructure, not in HSM-backed enclaves. Fifth, no enforcement of Connected App IP ranges, so a stolen refresh token works from any egress. CISA's October 2 advisory (AA25-275A) calls these out specifically and points to NIST SP 800-204D for SaaS-to-SaaS guidance.

What should defenders do this quarter?

Treat every Connected App as you would treat a service account. Disable user-initiated consent in Salesforce (OAuthAllowUserAdminAuthInit off, admin-approval required). Set refresh token lifetime to 24-48 hours for any app that does not absolutely need offline access. Inventory every ISV that touches Salesforce, Workspace, Microsoft 365, ServiceNow, GitHub, and Snowflake, and require the vendor to attest to where they store your tokens (HSM? encrypted-at-rest only? plaintext in a config?). Deploy DLP rules on Salesforce Cases that strip xoxb-, AKIA, JWT, and BEGIN ... PRIVATE KEY patterns before save. Subscribe to Salesforce's new Threat Detection beta (rolled out September 2025) which flags Bulk API anomalies per Connected App. And rotate any secret that may have transited a support ticket between August 1-20, 2025 — even if you are not on Mandiant's victim list, downstream copies of those tickets may have been resold.

How Safeguard Helps

Safeguard's SaaS-to-SaaS supply chain map enumerates every Connected App, OAuth scope, and refresh-token age across Salesforce, Workspace, Microsoft 365, Snowflake, GitHub, and ServiceNow, so security teams can see at a glance which ISVs hold full scope and which have unrotated tokens. Griffin AI cross-references each integration against incident feeds (Mandiant, Unit 42, CISA KEV) and raises a finding the moment a vendor like Salesloft is implicated in active exploitation, with a one-click revoke-and-rotate workflow. TPRM scoring tracks each ISV's SOC 2, OAuth hardening posture, and time-to-disclose, downgrading vendors that ship long-lived refresh tokens or store secrets outside an HSM. Policy gates block deployments that introduce new Connected Apps with full, refresh_token, or offline_access scope unless the integration is admin-approved, IP-restricted, and tied to a short-lived refresh policy — preventing the next Drift-class incident from being discovered after the fact.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.