Salesforce Org Compromise Playbook: Respond to Data Theft From Your Salesforce Org

Most Salesforce data theft does not exploit Salesforce at all: an attacker gets a user to approve a malicious connected app, or steals an integration's OAuth tokens, and then exports CRM data through the API as a legitimate client. The 2025 campaigns showed both routes at scale, with phone-based social engineering leading staff to authorise a modified Data Loader, and stolen tokens from third-party integrations opening hundreds of customer orgs. Because the attacker uses valid access, the response is about finding and revoking OAuth grants, measuring what was exported from logs that may only be kept briefly, and handling extortion that can arrive months later. This playbook covers how the incident shows up, triage, containment in priority order, eradication, recovery, evidence, notification and extortion handling. It is for Salesforce administrators, security operations teams and incident responders. Hardening is covered in the Salesforce Security Guide and detection engineering in the Salesforce Event Monitoring Detection Guide; this page is the response.

Key takeaways

• Block the app, then revoke the tokens. Salesforce says blocking a connected app ends its active sessions immediately and prevents future connections; per-user token revocation alone lets a still-trusted app reconnect.
• Collect logs in the first hour. Login History, Setup Audit Trail and any Event Log Files have fixed retention, and free log file types are kept for a very short time, so evidence disappears while you are still scoping.
• Assume the export was searched for secrets. In the Salesloft Drift campaign the actor searched stolen Salesforce records for AWS keys, passwords and Snowflake tokens, so rotate any credential stored in cases, notes or custom fields.
• Treat the phone call as the initial access. Google's threat intelligence team found the vishing campaign also reused harvested credentials against Okta and Microsoft 365, so scope beyond Salesforce.
• Prepare for extortion later. Google tracked extortion demands sometimes arriving months after the intrusion, with a 72 hour payment deadline, so the incident is not closed when access is cut.

How the incident shows up

The persistence technique is T1671 Cloud Application Integration: the connected app is a durable API identity that survives the victim's password reset. Exfiltration falls under T1567 Exfiltration Over Web Service.

Triage questions

1. Which route was it? User-authorised malicious app, stolen tokens from a legitimate integration, a compromised user or integration user credential, or a combination.
2. Which connected apps hold active tokens, and which are installed versus uninstalled? Since early September 2025 Salesforce blocks uninstalled connected apps for most users, but users who had already authorised an app keep access, so existing grants still matter.
3. Which users authorised the suspicious app, and what permissions do they hold? API Enabled, View All Data, Modify All Data, Customize Application and Manage Connected Apps decide how much an app could read.
4. What logs do we hold? Without Shield or the Event Monitoring add-on, API query detail is limited; confirm what was licensed during the incident window.
5. Which objects and how many records were read? Accounts, contacts, cases, opportunities and users are the usual targets.
6. Do records contain secrets or regulated data? Cases and notes often hold credentials, API keys or personal data that change both the containment and the notification picture.
7. Did the same actor reach other platforms? Check the identity provider and email for the users involved.

Containment priorities

1. Block malicious apps. In Setup, open Connected Apps OAuth Usage, find the app and block it. Salesforce states blocking ends the app's active sessions immediately and prevents future connections.
2. Revoke tokens for compromised integrations. For a legitimate integration whose tokens were stolen, revoke its tokens from the OAuth Connected Apps Usage page or from each user's detail page under OAuth Connected Apps, and coordinate with the vendor. Salesforce did this platform-wide for the Drift application on 20 August 2025 and for Gainsight-published apps on 19 November 2025.
3. Reset affected users. Freeze or deactivate users who authorised the malicious app or whose credentials were phished, reset passwords, and end their sessions. Reset the identity provider credentials and MFA for the same people.
4. Tighten app authorisation now. Restrict Approve Uninstalled Connected Apps and Use Any API Client to a small admin group, set trusted apps' Permitted Users to Admin approved users are pre-authorized, and review who holds Customize Application and Manage Connected Apps.
5. Restrict network access. Apply login IP ranges on profiles and trusted IP ranges, and IP relaxation settings on connected app policies, to block or challenge logins from unexpected networks, as both Salesforce and Google recommend.
6. Remove bulk export rights temporarily. Remove API Enabled and Data Loader access from users who do not need them during the incident.
7. Rotate secrets found in CRM data. Search cases, notes and custom fields for credentials and rotate them; see the Leaked Credential Response Playbook.

Eradication

• Configuration changes: review Setup Audit Trail for connected app installs, permission set assignments, profile and sharing changes, new users and changed login IP ranges during the window, and reverse each unapproved change.
• Refresh token policy: move integrations off the default Refresh token is valid until revoked to Expire refresh token if not used for n or Expire refresh token after n. Salesforce notes the policy is only evaluated when a refresh token is used, so it does not end a session that is already active.
• Integration users: confirm each integration runs as a dedicated integration user with minimum permissions; see How to review Salesforce connected apps and integration users.
• Other platforms: where credentials were phished, investigate the identity provider and email tenant for the same users and the same source addresses.
• Allowlist: install the apps you trust and block everything else, so new uninstalled apps cannot be authorised by ordinary users.

Recovery

1. Restore business integrations one at a time after the vendor confirms its own clean-up, with new tokens and a time-bound refresh token policy.
2. Turn on the controls that would have caught it: Transaction Security Policies to alert on or block large report exports and downloads, and Event Monitoring collection into the SIEM, as Salesforce and Google both recommend.
3. Register a Security Contact. Salesforce says Signature and Premier customers should register one so Salesforce can reach them during a security event; others should keep a current System Admin on record.
4. Train the help desk and users that IT support never asks for a connection code or MFA code. See the Help Desk Social Engineering Incident Playbook.
5. Measure: number of connected apps with no owner (target zero), share of integrations with a time-bound refresh token policy, users holding API Enabled, time from new connected app authorisation to security review, and days of API log history held outside Salesforce.

Small and large orgs

An org without Shield or the Event Monitoring add-on cannot see query text, so scoping relies on Login History, Setup Audit Trail and the free daily API Total Usage log, which shows API call volume per user and client. If that file was not collected daily, record the evidence gap honestly in the incident report and size notification on what the compromised app could read rather than on what it provably read. Large orgs with many integrations face the reverse problem: dozens of connected apps share the same integration patterns, so the decision to block has to weigh business outage against continued exposure. Agree in advance which integrations can be blocked by the security team without a change board, and which need the business owner on the call, so that the first hour is not spent finding approvers. In both cases, ask Salesforce Support whether it holds platform-side records for the window that you no longer have.

Evidence to preserve

Querying Event Log Files needs the View Event Log Files and API Enabled permissions, so give the responder account those rights in advance rather than during the incident.

Notification triggers

• Personal data: CRM data is mostly personal data about customers and contacts. GDPR Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals; processors must tell controllers without undue delay. See the Breach Notification Laws by Country Guide.
• US listed companies: a material incident triggers a Form 8-K Item 1.05 filing, generally due four business days after the materiality determination.
• Business customers: if the org holds data you process for clients, contracts usually set their own notice periods.
• Extortion handling: do not engage alone. Involve counsel and law enforcement, preserve the messages, verify claims against your own export logs before responding, and assume publication is possible. Follow the Extortion Email Playbook and, if your data appears on a leak site, the Leak Site Listing Response Playbook.

Lessons from incidents

• A phone call can install an API identity. In the ShinyHunters Salesforce Data Theft Campaign, callers posing as IT support had staff enter a connection code that approved a modified Data Loader, which then bulk-exported data. Restricting who can authorise apps would have stopped the step that mattered.
• Integration tokens are keys to many tenants. The Salesloft Drift Breach used tokens stored in the vendor's environment, and Salesforce and Salesloft revoked all active access and refresh tokens for the Drift app on 20 August 2025. Know every integration and how to revoke it before a vendor tells you to.
• Old tokens stay valid unless policy says otherwise. In the Gainsight Salesforce Breach, the attacker held 285 tokens, some issued as far back as 2017. A time-bound refresh token policy limits how long any stolen token works.

Practitioner checklist

• Keep an inventory of connected apps with owners, scopes, install status and refresh token policy.
• Restrict Approve Uninstalled Connected Apps, Use Any API Client, Customize Application and Manage Connected Apps to a small admin group.
• Set login IP ranges for profiles and connected apps that do not need open access.
• Export Login History, Setup Audit Trail and Event Log Files daily to the SIEM.
• Pre-grant the responder account View Event Log Files and API Enabled.
• Write and rehearse the block-then-revoke sequence for a malicious app and for a compromised vendor integration.
• Search CRM records for stored credentials and remove them before an attacker does.
• Register a Security Contact with Salesforce and keep vendor security contacts current.
• Prepare an extortion response decision path with counsel before you need it.

Standards and references

• Salesforce Help: Manage OAuth access policies for a connected app
• Salesforce Admins: Get ready for changes to connected app usage restrictions
• Salesforce: Protect against social engineering
• Salesforce Developers: Real-Time Event Monitoring objects
• Salesforce Developers: EventLogFile object
• Google Threat Intelligence Group: UNC6040 voice phishing and data extortion targeting Salesforce
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
• GDPR: Article 33 Notification of a personal data breach to the supervisory authority

Related NHI Mgmt Group resources: Salesforce Security Guide · Salesforce Event Monitoring Detection Guide · How to review Salesforce connected apps and integration users · OAuth Token Theft Incident Playbook · Vendor SaaS Breach Response Playbook