Session CRT-20260621 — 21 June 2026 · Afternoon Edition

Timeline first: access began in early-to-mid August 2025, exfiltration ran through roughly August 18–20, and the latest public guidance says this was a broad data-theft campaign, not a Salesforce zero-day. UNC6395 / “Icarus” abused compromised OAuth tokens from the Salesloft Drift integration to impersonate the trusted app and query connected Salesforce orgs; Google says they also deleted query jobs, but logs remained available. That’s a classic SaaS supply-chain / token-abuse pattern, not novel platform exploitation. Confidence on the token-abuse mechanism is high; attribution to a broader criminal cluster and the “Icarus” naming is more moderate.

What’s most exposed: Salesforce objects and fields reachable through the connected app — Account, Contact, Case, Opportunity, plus support-case text where plaintext secrets can live. Defenders can actually hunt for the behaviors Google and Unit 42 called out: unusual SOQL/API bursts, custom user agents like Salesforce-Multi-Org-Fetcher/1.0, Salesforce-CLI/1.0, python-requests/2.32.4, Python/3.11 aiohttp/3.12.15, Tor/DigitalOcean/AWS source IPs, and evidence of deleted query jobs. The thin part is attribution beyond the campaign cluster: I’d stay at moderate confidence unless we get stronger infrastructure or operator linkage. MITRE-wise, this sits cleanly in token theft / valid accounts / cloud data exfiltration.

Look, for customers the 30-minute play is straightforward: revoke the Drift/Salesloft OAuth access and refresh tokens first, then disconnect the Salesloft/Drift integration from Salesforce, and only after that start forensics. Salesforce’s incident notice says they invalidated active Access and Refresh Tokens and removed Drift from the app; FINRA also says to disconnect Salesloft integrations and rotate potentially exposed credentials. That’s the emergency change sequence, not “nice to have” cleanup. The key logs to pull immediately are Salesforce login history, audit trail, API access logs, Event Monitoring/UniqueQuery events if enabled, and authentication activity for the Drift connected app; Google Cloud’s writeup also says to open a Salesforce support case to get the specific queries used by the actor. For exports, review Case records, contacts, accounts, opportunities, and any bulk API/CSV exports tied to the Drift connection user or service account. Sources: Salesforce notice, Google Cloud, Unit 42, FINRA. [https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1, https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift, https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances, https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack]

On exposure assessment: assume support case text is the highest-risk bucket because reporting tied this campaign to plaintext secrets like AWS keys, Snowflake tokens, VPN credentials, cloud credentials, and passwords embedded in cases. So the question is not just “was CRM data read?” but “did any of our cases, notes, attachments, or synced fields contain live secrets or credentials?” I’d score exposure by checking: 1) whether any exported Case/comment text contains secret patterns, 2) whether the same secrets are still valid in downstream systems, 3) whether the Drift-connected user had broad API permissions, and 4) whether there were large queries or unusual object enumeration against cases and related objects. If you find exposed secrets, rotate them as a separate emergency path from the Salesforce token revocation.
CRITICAL (do today): revoke Drift OAuth tokens, disable the integration, rotate any secrets found in support data, and snapshot logs/exports. HIGH (this week): hunt all Salesforce objects and exports for cases containing credentials, then review downstream access from any exposed secret. MEDIUM (schedule): harden case-handling so secrets never land in CRM text again.

Look, this is not a “24 billion unique victims” event. The data we have says the corpus is heavily duplicated, aggregated from at least 36 sources, and includes usernames, email addresses, plaintext passwords, and login URLs. That makes it a huge credential-abuse reservoir, not a clean victim count. The right defender takeaway is simple: treat it as a reuse-and-replay hunt problem, not a headline number problem.

For actionability: yes, some of it is actionable, but with caveats. The corpus contains plaintext passwords and session-related material from infostealer logs; that is enough to drive account takeover if you find a match against your users or services. But uniqueness is the hard part. You need normalization and dedupe across email, username, password hash, URL, and timestamp/source metadata before you trust counts. If you have source IOCs from the leak, use them to pivot on stealer families, exfil endpoints, and collection infrastructure; if you only have raw creds, the real signal is downstream abuse, not the dump itself.

Triage in this order: 1) flag creds for privileged, SSO, VPN, admin, and finance accounts; 2) identify plaintext password reuse across corp accounts and SaaS; 3) invalidate cookies/sessions where you can’t prove they’re clean; 4) force reset only where reuse or exposure is confirmed, otherwise you drown the helpdesk. For hunts, look for failed logins followed by success from new ASN/geo, “impossible travel,” new device/user-agent strings, token refreshes from unusual IPs, MFA fatigue, and session reuse after password change. If you want proof of replay, the kill chain is: stolen cookie/token → first-seen IP/device mismatch → successful auth without password prompt → subsequent sensitive action. That’s the smoking gun.