Most Salesforce data theft in 2025 involved no exploit at all, just a trusted app or a phished user running ordinary API queries that nobody was watching. The 2025 campaigns against Salesforce customers used connected apps, OAuth tokens and bulk queries, which look like normal integration traffic unless you collect the right events and know what normal looks like. This guide is for detection engineers and SaaS security teams who already own a Salesforce org and need to turn its logs into working detections. It covers which log sources exist and what each costs, the fields that matter, a detection catalogue mapped to MITRE ATT&CK, Transaction Security Policies, SIEM ingestion and the metrics that show coverage is real. For platform hardening (sharing model, profiles, connected app policies), see the Salesforce Security Guide; this page stays on the telemetry.
Key takeaways
- Know which logs you are actually paying for. Every org gets Setup Audit Trail and Login History, but API, report and file activity at useful retention needs Salesforce Shield or the Event Monitoring add-on.
- Use two speeds of telemetry. Event Log Files arrive hourly or daily and suit hunting and baselines; Real-Time Event Monitoring streams suit alerting and blocking.
- Integrations are the main blind spot. Detections built for human users miss a trusted connected app that suddenly reads every Case, which is what happened in the Salesloft Drift campaign.
- Watch query shape, not just volume. Small count-style queries followed by full-table extraction, from a new client or anonymising network, is the recurring 2025 pattern.
- Retention is a security decision. Setup Audit Trail keeps 180 days and Login History six months; copy everything to your SIEM or you lose the evidence before many investigations start.
The Salesforce log sources and what each one tells you
Salesforce has several overlapping telemetry sources. They differ in licensing, latency, retention and access method, so a detection programme starts by listing which ones the org has.
| Source | What it records | Access | Retention and licensing |
|---|---|---|---|
| Setup Audit Trail (SetupAuditTrail object) | Configuration changes: users and permissions, security and sharing, connected apps, Apex and development changes, including changes by delegated admins and by agents working through Setup | Setup page (20 most recent), CSV download, API | All orgs; download covers the last 180 days, after which records are deleted |
| Login History (LoginHistory object) | Interactive and OAuth logins, login type and subtype, source IP, status code, application | Setup page (up to 20,000 rows), CSV or GZIP download, API | All orgs; past six months |
| Event Log Files (EventLogFile object) | CSV files per event type (Salesforce says at least 50 types): logins, logouts, API calls, Apex executions, report exports and more | REST or SOAP API query, then blob download; Event Log File Browser | Enterprise, Unlimited and Performance editions get a small free set at one-day retention; Shield or the Event Monitoring add-on gives all types, hourly files and one year default retention |
| Real-Time Event Monitoring streams | Platform events such as LoginEventStream, ApiEventStream, ReportEventStream, ListViewEventStream and the threat detection events | Pub/Sub or streaming subscription from an external system | Shield or Event Monitoring add-on, plus the View Real-Time Event Monitoring Data permission |
| Real-Time Event Monitoring storage objects | Big objects such as LoginEvent, ApiEvent, ReportEvent, FileEventStore, PermissionSetEventStore and the anomaly stores | SOQL (async or standard) against the stored object | Shield or Event Monitoring add-on |
| Threat Detection events | ApiAnomalyEvent, ReportAnomalyEvent, CredentialStuffingEvent, SessionHijackingEvent, LoginAnomalyEvent, GuestUserAnomalyEvent | Stream and storage objects; Threat Detection app | Shield or Event Monitoring add-on; Salesforce states these do not count toward standard object storage limits |
The free Event Log File set on Enterprise, Unlimited and Performance editions, according to Salesforce Trailhead, is Apex Unexpected Exception, CORS Violation Record, CSP Violation, Hostname Redirects, Login, Logout and API Total Usage, each at one-day retention. API Total Usage is the one most teams overlook: it is the only free view of API call volume per user and client, so collect it daily even in orgs without Shield. Developer Edition and trial orgs keep log files for one day only.
Event Log Files: timing you must design around
- Daily files are generated during off-peak hours the day after the activity, so they are unavailable for at least a day.
- Hourly files (licensed orgs) usually contain an event three to six hours after it happens, sometimes later, and Salesforce warns they can be incomplete during instance refreshes, site switches or outages. Use hourly files for faster detection and reconcile against daily files for completeness.
- Collection: query EventLogFile by EventType, LogDate, Interval and Sequence (Interval and Sequence exist from API version 37.0), then retrieve the LogFile blob. Files over 100 MB need the blob download method rather than an inline read.
- Integrity: rows are read-only, but a user with sufficient permission can delete whole log files. Ship files out promptly and alert on deletions.
Fields that make or break a detection
Most useful detections join a small set of fields across sources. The Real-Time Event Monitoring objects are the richest; the names below are from the Salesforce Platform Events Developer Guide.
| Object | Field | Why it matters |
|---|---|---|
| LoginEvent | SourceIp, ForwardedForIp, Country, City | Anonymising networks and impossible travel; ForwardedForIp is the X-Forwarded-For value |
| LoginEvent | LoginType, LoginSubType, Application | Separates interactive logins from OAuth flows; the subtype shows which connected-app flow was used |
| LoginEvent | LoginKey, LoginHistoryId | Ties every later event in a session back to the login and to LoginHistory |
| LoginEvent | Status, PolicyOutcome | Failure reasons and whether a Transaction Security Policy fired |
| ApiEvent | Query, QueriedEntities, RowsProcessed | The SOQL text, the objects read and how many rows came back: the core of exfiltration detection |
| ApiEvent | Client, UserAgent | Unknown or new clients; Salesforce reports MCP servers as "agentic-api-service" |
| ApiEvent | ConnectedAppId | Which app made the call, but only populated when the call triggered OAuth authentication; it is null when an active token was reused, so do not rely on it alone |
| ApiEvent | SourceIp | Internal Salesforce traffic, for example from AppExchange packages, shows as "Salesforce.com IP" |
Two coverage gaps matter. ApiEvent records read-only calls (query, queryMore and count) through SOAP and Bulk APIs on the Enterprise and Partner WSDLs, and Salesforce states it does not capture Tooling API calls or calls from Salesforce mobile apps. Bulk result downloads appear in BulkApiResultEventStore, so collect both. LoginEvent also stops recording when login rates exceed Salesforce's limit, which is worth knowing before you build a credential stuffing detection on it alone; the dedicated CredentialStuffingEvent covers that case.
Detection catalogue mapped to ATT&CK
The detections below come from the techniques documented in the 2025 campaigns by Google Threat Intelligence Group and in Salesforce's own guidance, mapped to MITRE ATT&CK v20. Tune thresholds to your own baseline; the numbers you need are per user, per integration user and per connected app.
| Detection | Data source | Logic in outline | ATT&CK |
|---|---|---|---|
| New connected app authorised by a non-admin | Setup Audit Trail, LoginEvent (LoginSubType, Application) | First OAuth login for an application not on the approved list, or app install entries in Setup Audit Trail outside change windows | T1671 Cloud Application Integration |
| Login or OAuth flow from anonymising network | LoginEvent, LoginHistory | SourceIp in commercial VPN or Tor exit lists, especially for integration users or admins | T1078.004 Cloud Accounts |
| Integration token used from a new place | ApiEvent, LoginEvent | Integration user or ConnectedAppId seen from an IP range, country or UserAgent never seen for that app | T1550.001 Application Access Token |
| Reconnaissance then bulk extraction | ApiEvent, BulkApiResultEventStore | Several COUNT() queries across Account, Contact, Opportunity, User or Case, followed within hours by high RowsProcessed on the same objects | T1213 Data from Information Repositories |
| Secret hunting in support data | ApiEvent (Query) | SOQL against Case or attachments with text filters for words such as password, key or token; reading Case bodies at volume by an integration that normally writes only | T1213, T1530 |
| Mass report or list view export | ReportEvent, ListViewEvent, Report Export log file | Row counts far above the user's baseline, exports of reports outside the user's role | T1567 Exfiltration Over Web Service |
| Privilege added to self or integration | PermissionSetEventStore, Setup Audit Trail | Assignment of permission sets carrying View All Data, Modify All Data, API Enabled or Manage Connected Apps, especially by the same user who then runs queries | T1098 Account Manipulation |
| Vishing-driven MFA abuse | LoginEvent, LoginHistory, IdP logs | Repeated MFA challenges or a new device registration followed by an app authorisation during the same session | T1566.004 Spearphishing Voice, T1621 |
| Stolen session reuse | SessionHijackingEvent, LoginEvent | Salesforce threat detection alert, or one LoginKey seen from two distinct client fingerprints | T1550.001 |
| Log destruction | Setup Audit Trail, EventLogFile collection gaps | Deletion of event log files, changes to Event Monitoring settings or retention, missing hourly files for a period | Use a coverage alert; no single technique fits |
The query-shape detection is the most valuable one. In the vishing campaign Google tracked as UNC6040, operators ran small test queries before moving to full-table extraction, and in the Salesloft Drift campaign the actor ran count-style queries on core objects before bulk export. See the ShinyHunters Salesforce Data Theft Campaign 2025 and the Salesloft Drift Breach 2025. Neither required a Salesforce vulnerability, which is why identity and query telemetry, not vulnerability scanning, is the defence.
Real-Time Event Monitoring and Transaction Security Policies
Transaction Security is included with Real-Time Event Monitoring. A policy evaluates events against conditions built in the point-and-click Condition Builder or written in Apex, and on a match can take one of three actions: block the operation, require multi-factor authentication, or send notifications. Salesforce lists ApiEvent, ListViewEvent, LoginEvent, ReportEvent, FileEvent, PermissionSetEventStore and BulkApiResultEventStore among the event types policies can target, together with the anomaly and threat detection events. Stream-only events such as LogoutEventStream, UriEventStream and LightningUriEventStream are not policy targets.
Choosing between alert, MFA and block
| Scenario | Suggested action | Trade-off |
|---|---|---|
| Report export above a row threshold by a human user | Require MFA, notify security | Low friction for genuine work; stops a stolen session without a second factor |
| API query returning very large row counts on sensitive objects from a non-approved client | Block and notify | Risk of breaking an undocumented integration; run in notify-only mode first |
| Login from a country or network outside policy for admins | Block | Travelling admins need a documented exception path |
| Permission set grant of high-risk permissions | Notify | Blocking can stop legitimate change; pair with a change ticket check |
| Integration user activity | Notify, then block once baselined | Integrations cannot answer MFA, so MFA actions do not apply; block only after the baseline is stable |
Policies run inside Salesforce and therefore keep working when the SIEM is slow, but they only see one event at a time. Cross-source correlation (an Okta MFA reset followed by a Salesforce app authorisation) belongs in the SIEM. Use both.
Implementation: getting from licence to working detections
- Inventory what you have. Confirm edition, whether Shield or the Event Monitoring add-on is licensed, current Event Monitoring retention settings, and which streams are enabled. Record it in your log source register. See the SaaS Audit Log Retention and Licensing Guide.
- Create a dedicated collection identity. Use a single integration user with View Event Log Files, API Enabled and, for streams, View Real-Time Event Monitoring Data, restricted by login IP range to your collector. Do not use View All Data where the narrower permissions suffice. Treat it as a non-human identity with an owner and a rotation plan. See the Detection Engineering for Non-Human Identities Guide.
- Collect the free sources first. Pull Setup Audit Trail, Login History and the free daily Event Log Files (Login, Logout, API Total Usage) every day into the SIEM, so that even an unlicensed org has 12 months or more of history outside Salesforce.
- Add licensed sources by risk. Start with LoginEvent, ApiEvent, BulkApiResultEventStore, ReportEvent and PermissionSetEventStore, then file and list view events. Restrict object permissions on the storage objects: Salesforce notes they can contain sensitive data, including SOQL text.
- Baseline for two to four weeks. Per user and per integration: clients, IP ranges, objects queried, typical RowsProcessed, hours of activity. Integration baselines are usually tight and therefore give the cleanest detections.
- Deploy detections in notify mode. Run the catalogue above as SIEM alerts and Transaction Security Policies with notification only. Review every hit for two weeks and record false positive causes.
- Promote to enforcement. Move stable policies to MFA or block. Keep a documented rollback: name an on-call owner who can deactivate a policy in Setup if a business process breaks, and test that step in a sandbox first.
- Write the response runbook. Each alert links to steps: revoke the user's sessions and the connected app's OAuth tokens, block the app, preserve the relevant log files, and scope what data the identity could read. See the SaaS and OAuth App Governance Guide.
Small and large organisations
- Small org without Shield: collect Setup Audit Trail and Login History weekly at minimum, the free daily log files daily, and alert on new connected apps and logins from anonymising networks. That covers the entry point of both 2025 campaigns even without API query telemetry.
- Large or regulated org: license Event Monitoring, stream to the SIEM, run Transaction Security Policies on exports and API volume, and give each integration its own integration user so that ConnectedAppId and user baselines line up.
- Agentforce and MCP use: treat agent traffic as a separate client population. ApiEvent marks MCP server traffic as "agentic-api-service", which gives you a field to baseline on. See the Securing Salesforce Agentforce Guide.
Where identity fits
Every detection on this page ultimately asks one question: is this identity doing what it normally does? The hardest identities to answer that for are non-human: connected apps, integration users and the OAuth refresh tokens held by third parties such as chatbots and customer success platforms. In the Gainsight Salesforce Breach 2025, long-lived OAuth tokens held by a vendor gave access to customer CRM data, a pattern that only per-app baselining detects. Give each integration a named owner, a documented scope, its own integration user and an expected IP range, and the detection rules become simple. See the ITDR Guide.
Measuring coverage and effectiveness
- Source coverage: percentage of production orgs whose Setup Audit Trail, Login History and Event Log Files reach the SIEM daily. Target 100 percent.
- Collection freshness: median delay between event time and SIEM availability, tracked separately for hourly files and streams.
- Integration baseline coverage: percentage of connected apps with a recorded owner, expected IP range and expected objects.
- Detection test pass rate: share of catalogue detections that fire when exercised in a sandbox with a test integration each quarter.
- Time to revoke: time from alert to OAuth token revocation for a suspicious connected app.
- Retention: days of Salesforce telemetry available outside Salesforce, which should exceed your longest expected investigation lookback.
Framework mapping
| Framework | Reference | How this guide applies |
|---|---|---|
| NIST CSF 2.0 | PR.PS-04, DE.CM-03, DE.AE-02 | Generate and expose Salesforce logs; monitor personnel and integration activity; analyse adverse events |
| NIST SP 800-53 Rev. 5 | AU-2, AU-6, AU-11, AU-12, SI-4, AC-6 | Event selection, review, retention beyond native limits, generation, system monitoring, least privilege for collection and integration users |
| CIS Controls v8.1 | Control 8 (8.2, 8.9, 8.11) | Collect, centralise and review audit logs |
| ISO/IEC 27001:2022 Annex A | A.8.15 Logging, A.8.16 Monitoring activities | Logging and monitoring of a critical SaaS application |
| MITRE ATT&CK v20 | T1671, T1078.004, T1550.001, T1528, T1213, T1567, T1098 | Detection catalogue above |
Common failure patterns
- Relying on Salesforce for retention. Setup Audit Trail deletes after 180 days and Login History covers six months; an extortion demand that arrives months after a quiet theft, as happened with the ShinyHunters follow-on activity, finds the evidence gone.
- Detecting humans only. Rules keyed on interactive logins miss an OAuth token replayed by a third party, which needs no login page at all.
- Trusting ConnectedAppId alone. It is null when a call reuses an active token, so rules filtering on it silently miss activity. Correlate with the integration user and LoginKey.
- One shared integration user. Several apps behind one user make baselines meaningless and revocation disruptive.
- Policies left in notify mode for ever. Transaction Security Policies that never move to MFA or block give warnings after the data has gone.
- Over-privileged collector. A log collection user with View All Data and no IP restriction becomes the most valuable credential in the org.
Practitioner checklist
- Record edition, Event Monitoring licensing and retention settings for every production org.
- Ship Setup Audit Trail, Login History and all available Event Log Files to the SIEM daily.
- Collect LoginEvent, ApiEvent, BulkApiResultEventStore, ReportEvent and PermissionSetEventStore where licensed.
- Run the collector as a least-privilege, IP-restricted integration user with a named owner.
- Baseline every connected app and integration user: clients, IP ranges, objects and row counts.
- Alert on new connected apps, anonymising networks, count-then-bulk query patterns and high-risk permission grants.
- Move proven Transaction Security Policies from notify to MFA or block, with a documented rollback owner.
- Alert on log file deletion, retention changes and gaps in hourly collection.
- Test the detection catalogue quarterly in a sandbox and track time to token revocation.
Standards and references
- Salesforce: Real-Time Event Monitoring Objects (Platform Events Developer Guide)
- Salesforce: ApiEvent Object Reference
- Salesforce: Use Event Log Files (REST API Developer Guide)
- Salesforce Help: Monitor Setup Changes with Setup Audit Trail
- Salesforce Help: Monitor Login History
- Google Threat Intelligence Group: The Cost of a Call, From Voice Phishing to Data Extortion
- MITRE ATT&CK: Cloud Application Integration
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Salesforce Security Guide · Detection Engineering Guide · SIEM Guide · Google Workspace Audit Log Detection Guide