The Salesloft-Drift OAuth Breach: A 1-Hour Audit Every Indian SaaS Should Run on Their Connected Apps This Weekend

Between August 8 and August 18, 2025, attackers used stolen OAuth tokens from the Salesloft-Drift integration to bulk-export data from Salesforce instances at 700+ organisations — including Cloudflare, Zscaler, Palo Alto Networks, PagerDuty, and Tanium. Salesloft disclosed it on August 20. Customers got formal notification through Fastly Service Advisories from September 4 onwards (Google Cloud threat intel, driftbreach.com tracker). The pattern matters more than the specific vendor: it shows what an OAuth-token compromise looks like when it scales. Every Indian SaaS has a connected-app surface that is vulnerable to the same class of attack. This is the 1-hour audit to run on your stack this weekend. ## The 60-second answer Open your Google Workspace, Microsoft 365, Salesforce, Slack, and GitHub admin consoles. List every third-party app with active OAuth tokens. Revoke every token older than 90 days that nobody can name a business reason for. Rotate the rest. For the apps you keep, narrow the scopes to read-only where possible. We have walked five Indian SaaS teams through this since the Drift disclosure — every single one found 8-15 stale OAuth tokens nobody remembered granting. ## Why this matters now The Drift breach is interesting not because chatbots got compromised, but because the attackers used legitimate OAuth tokens. Every defence built around "block bad domains" or "block bad IPs" failed — the requests came from Salesloft's real infrastructure with valid tokens. As Cloudflare put it in their disclosure, "the use of trusted, valid tokens means standard EDR or perimeter detection is largely useless" (Cloudflare disclosure). The same class of attack works against any SaaS-to-SaaS integration. If your CRM is connected to your marketing tool, your finance tool, your support tool, and your AI chatbot — the attack surface is the union of all those vendors' security postures, not just your own. UNC6395 went specifically after support cases on Salesforce because that is where customer-shared secrets and credentials accumulate (Unit 42 threat brief). ## The 6 places to audit (in order) ## The 1-hour audit walkthrough This is the audit we run with a founder and one engineer in a single Saturday morning. Coffee, two browser tabs, a fresh Notion doc. Each step has a verification you can complete before moving on. ## The 5-line shell script that lists active GitHub OAuth tokens for your org

#!/usr/bin/env bash
  # Requires: gh CLI authenticated as an org admin
  ORG="${1:-your-org-name}"
  gh api "/orgs/${ORG}/installations" --paginate \
    --jq '.installations[] | "\(.app_slug)\t\(.target_type)\t\(.created_at)\t\(.updated_at)"' \
    | sort -t$'\t' -k4
  # Output: app_slug, target_type, installed_at, last_updated_at (tab-separated)
  # Anything with last_updated more than 90 days ago is a revocation candidate
  

Save as gh-oauth-audit.sh, run with ./gh-oauth-audit.sh your-org-name. Five-line audit, output sorted by last activity. The same pattern works for any SaaS with an admin API — Slack, Salesforce, Microsoft Graph all expose equivalents. ## What broke for the named victims (and what you can copy)

Victim	What got stolen	What they did right
Cloudflare	Salesforce case data including customer-shared secrets and tokens in support tickets	Disclosed quickly, rotated all secrets in support cases, published a transparent post-mortem
Zscaler	Customer contact information, business-related details, content from select Salesforce records	Notified affected customers individually, published technical details promptly
PagerDuty	Salesforce business contact data; no PD platform impact	Clear scoping in the disclosure — what was and was not affected
Palo Alto Networks	Limited Salesforce data; published Unit 42 detailed threat brief	Used the incident to publish indicators of compromise for the broader community
Tanium	Salesforce data exposure; disclosed within days	Issued a customer security advisory with concrete remediation steps

The lesson: even firms with mature security programs got hit. The defence is not "be perfect" — it is "minimise blast radius." The fewer scopes a connected app has, the less an attacker walks away with when the upstream vendor is compromised. ## The 5 contract clauses to add to every new OAuth integration When a sales team or marketing team next asks you to grant an OAuth integration, your security review should require five things:

• Vendor's most recent security questionnaire (SOC 2 Type II, ISO 27001, or both)
• Vendor's incident notification SLA — 24 hours or better; 48 hours is acceptable for non-critical apps
• Right to revoke OAuth tokens at any time without contractual penalty
• Specific list of OAuth scopes requested — challenge any "broad" scope and require justification
• Clause requiring vendor notification within 72 hours of any subcontractor breach affecting your data

Most US-based SaaS vendors will accept these clauses without negotiation. The ones who push back are the ones you should be more cautious about granting access to. ## Common mistakes (each one hurts) Symptom: "The audit took 3 hours, not 1." Cause: more apps than expected, or admin had to track down disused vendor accounts. Fix: schedule the audit quarterly, not annually. The 1-hour figure assumes the previous audit was done. Symptom: "We revoked an app and broke a critical workflow." Cause: not enough comms before revoking. Fix: post a Slack message in #general 24 hours before revoking, list the apps you plan to disable, ask for objections. Symptom: "OAuth tokens granted by a former employee still active." Cause: offboarding process did not include OAuth audit. Fix: add "review and rotate OAuth grants by departing employee" to your offboarding checklist. Symptom: "We rotated tokens but downstream automation broke." Cause: secrets-management discipline. Fix: store token references, not literal tokens, in your automations. When you rotate, update the central store; the automation re-reads. Symptom: "We cannot find anyone who knows what app X does." Cause: nobody was assigned ownership when it was added. Fix: every OAuth grant going forward must have a named owner; auto-revoke after 30 days if no owner can be identified. ## When NOT to revoke If your audit turns up an app that is actively used by a small but critical workflow, do not revoke it just because the scope looks broad. Instead: open a 1-week ticket to migrate to a narrower-scoped alternative, or to ask the vendor for a more restricted token. Revoking first and asking later breaks the workflow and erodes the team's trust in the audit process. Similarly, do not rotate tokens during a launch window or on a Friday afternoon. Rotation should be a planned activity with a rollback path. ## A real example — a 28-person Pune SaaS A B2B SaaS in Pune (analytics for ops teams, ~600 paying customers) ran this audit on a Saturday morning in early September after the Drift disclosure made it to their LinkedIn feeds. What we found in 47 minutes: - 51 Google Workspace apps with active OAuth grants. 19 had no activity in 6+ months. Of those, 14 nobody could name. Revoked all 14 — nothing broke. - 4 Slack apps from canceled trials. Revoked. - 2 GitHub PATs from a former engineer who left in March. Revoked. Both had repo:write scope. - 1 Stripe restricted key with broader scopes than needed (created during a tax integration setup that was abandoned). Rotated and tightened scopes. - Their CRM integration with HubSpot was using "all-data" scope — narrowed to "contacts:read" + "deals:read" without breaking the dashboard that depended on it. Total time: 51 minutes. Total cost: zero, except 51 minutes of founder + engineer time. The CTO told us he had not realised "stale OAuth grant from former employee" was even a category of risk until the Drift news made him look. For background on the technical pattern, see our 2025 piece on the Salesforce-Gainsight breach SaaS-integration audit for India — which covers the same connected-app pattern in a different context. Together they form the cluster on third-party integration risk. ## The Reddit pulse The r/cybersecurity threads on the Drift breach through August and September 2025 surface three patterns: defenders complaining that their EDR caught nothing because the requests used valid tokens; CISOs at impacted firms asking each other for indicator-of-compromise lists; and a recurring complaint that connected-app inventory tooling does not exist for SMBs at a price point under ₹50k/year. The middle group is the one to watch — community-shared IOCs from Mandiant and Unit 42 are now the practical baseline for OAuth-token-attack hunting. The r/AskNetsec subreddit in early September had a recurring thread asking "how often should we audit OAuth grants?" — the consensus among practitioners was quarterly, with monthly preferred for orgs above 100 people. ## A founder note from our team Our founder Vivek Singh wrote about this class of risk a few months ago — the broader pattern of supply-chain compromise via OAuth tokens. The shortest version of his argument: every SaaS your customers connect into your product is a potential lateral-movement path, and every SaaS you connect into is a potential ingress path. The math compounds. For Indian SaaS specifically, the discipline is: minimise the number of integrations, narrow the scopes, audit every quarter, and revoke aggressively. The friction this creates with sales and marketing teams is real but manageable — and dramatically cheaper than being on the next Drift-style customer list. For the broader ecosystem context, our piece on the Knownsec leak hardening checklist covers a similar 1-week tactical sprint pattern that pairs well with this 1-hour audit. ## FAQ ### How often should we run this audit? Quarterly minimum for any SaaS over 20 people. Monthly for any SaaS handling regulated data (finance, health, education). Triggered re-audit any time a security advisory like the Drift one drops, OR an employee leaves, OR a vendor is replaced. ### What if we have no admin console for a vendor? Then you have a deeper problem than OAuth audit — you have an unmanaged shadow-IT vendor. List who in your org granted access. Then either (a) get admin access, (b) revoke the integration, or (c) document the exception with a named owner and an explicit acceptance of risk by the founder/CTO. ### Are we required by DPDP to do this? The DPDP Act (and the upcoming Rules) requires reasonable security safeguards. An OAuth-grant audit is part of the baseline. The Act does not specify "quarterly OAuth audit" — it specifies the outcome (data is safeguarded). The audit is the cheapest way to show you are meeting that outcome standard. ### What is the difference between OAuth tokens and API keys? OAuth tokens are issued by an OAuth flow with explicit user consent and limited scopes; they are typically scoped to a specific user's permissions. API keys are typically issued by an admin and have broader, often static, scopes. Both are credentials and both must be inventoried, rotated, and audited. The Drift attackers stole OAuth tokens, but the same defensive disciplines apply to API keys. ### Can we automate this audit? Partially. Tools like AppOmni, Obsidian Security, and Adaptive Shield offer SaaS Security Posture Management (SSPM) for connected apps. Annual costs typically start around ₹6-15 lakh for SMBs — beyond most early-stage budgets. The 1-hour manual audit is the practical alternative until you cross 100 employees or hold regulated data. ### What about consumer Google accounts on personal devices? If employees access company Google Workspace via personal devices, audit those too — at minimum require MDM enrolment for managed devices. OAuth grants made from a personal device are no less risky than those from a managed laptop. ### What did Salesloft and Drift do wrong, technically? Investigators believe attackers compromised Salesloft's GitHub environment between March and June 2025, then pivoted to Drift's AWS environment to exfiltrate OAuth tokens. The most-named root causes in third-party analyses are: secrets stored in GitHub Actions, lack of detection on AWS principal anomalies, and OAuth tokens that did not expire fast enough. Each of these is a defence you can replicate. ### What is the SaaS-vendor security questionnaire we should send going forward? Minimum 5 questions: (1) Latest SOC 2 Type II report, (2) Incident-notification SLA, (3) Subprocessor list and whether DPAs are signed with each, (4) OAuth scopes required and justification for any broad scope, (5) Internal access-control practices for production data. Most reputable vendors will respond within 5 working days. Unresponsive vendors are themselves a signal.