Salesforce provides a dedicated Threat Detection module that uses statistical and machine learning techniques to detect anomalous or risky activity within your Salesforce organization. To strengthen the security posture of your instance, it makes sense to integrate these events into your existing alerting and SIEM pipeline.

Salesforce environments are high-value targets for attackers because they contain:

• Sensitive customer and financial data.
• A rich ecosystem of third-party add-ons, which expands the attack surface.

This article explains how to ingest Salesforce Threat Detection data into your SIEM and build meaningful detections on top of it.

Note that some events are only available in newer versions of the Salesforce API, as shown below so make sure your tenant supports it.

Currently the threat detection module supports a number of six objects:

Getting the data in

To collect Salesforce Threat Detection data into Splunk, use the Splunk_TA_salesforce add-on and configure new inputs for each object.

Steps:

1. Authenticate under Configuration using your preferred authentication type.
2. Create a new input of type Salesforce Object
3. Under Object, specify the appropriate event store (eg SessionHijackingEventStore) and select the fields you want to collect.

Once configured, Salesforce will send new events to Splunk, where they will be stored under a sourcetype matching the pattern: sfdc: (eg sfdc:sessionhijackingeventstore).

You can also pull historical objects to obtain baseline data and test your detections, if available in your tenant.

This addon uses uses SOQL (Salesforce Object Query Language) queries that are sent via Salesforce’s REST API endpoints.

Based on the values filled in the addon’s config, the SQQL query may look something like:

SELECT CurrentIp, CurrentPlatform, CurrentScreen FROM sessionhijackingeventstore WHERE LastModifiedDate>2025-01-01T00:00:00.000z AND LastModifiedDate<=2025-10-12T00:00:00.000z ORDER BY LastModifiedDate ASC

SessionHijackingEventStore

This detection identifies cases where a session cookie is stolen (for example via stealer malware) and reused by a malicious actor.

Salesforce models this by comparing session attributes (IP address, user agent, OS fingerprint, plugins, screen resolution) between legitimate and suspicious sessions.

index=salesforce sourcetype="sfdc:sessionhijackingeventstore"
| search Score > 0.9 ```replace with a reasonable threshold for your environment```
| table CurrentIp, CurrentPlatform, CurrentScreen, CurrentUserAgent, CurrentWindow, EvaluationTime, EventDate, EventIdentifier, LastReferencedDate, LastViewedDate, LoginKey, PolicyId, PolicyOutcome, PreviousIp, PreviousPlatform, PreviousScreen, PreviousUserAgent, PreviousWindow, Score, SecurityEventData, SessionHijackingEventNumber, SessionKey, SourceIp, Summary, UserId, Username

Detection tip: Treat any event where current vs. previous session fingerprints diverge as high risk. Prioritize cases with a new CurrentIp/ASN or CurrentUserAgent that differs from PreviousIp/PreviousUserAgent, and chain by LoginKey to see what the attacker did next (profile changes, establihing persistence)

API Anomaly

This detection monitors unusual API activity patterns. API tokens are often mishandled, so detecting abnormal usage can reveal compromised automation or integration accounts.

Salesforce evaluates metrics like operation type, number of rows processed, queried entities, and source IP to calculate an anomaly Score between 0 and 1.

index=salesforce sourcetype="sfdc:apianomalyeventstore"
| search Score>0.9 ```replace with a reasonable threshold for your environment```
| table ApiAnomalyEventNumber, EvaluationTime, EventDate, EventIdentifier, LastReferencedDate, LastViewedDate, LoginKey, Operation, PolicyId, PolicyOutcome, QueriedEntities, RequestIdentifier, RowsProcessed, Score, SecurityEventData, SessionKey, SourceIp, Summary, Uri, UserAgent, UserId, Username

Detection tip: Look for sudden spikes in RowsProcessed or bulk export operations performed by service accounts, a common data exfiltration tactic.

ReportAnomalyEventStore

This event detects anomalies in how users generate Salesforce reports. It considers features such as the number of rows, filters, time of day/week, and browser characteristics.

index=salesforce sourcetype="sfdc:reportanomalyeventstore"
| search Score > 0.9 ```replace with a reasonable threshold for your environment```
| table EvaluationTime, EventDate, EventIdentifier, LastReferencedDate, LastViewedDate, LoginKey, PolicyId, PolicyOutcome, Report, ReportAnomalyEventNumber, Score, SecurityEventData, SessionKey, SourceIp, Summary, UserId, Username

Detection tip: Expand the SecurityEventData JSON array to extract additional features for context (such as filters used or export attempts). Monitor for users generating unusually large or unfiltered reports.

CredentialStuffingEventStore

This object detects automated login attempts using credentials from known data breaches. An event is triggered when Salesforce identifies successful logins associated with a credential stuffing pattern.

index=salesforce sourcetype="sfdc:credentialstuffingeventstore"
| search Score > 0.9 ```replace with a reasonable threshold for your environment```
| table AcceptLanguage, CredentialStuffingEventNumber, EvaluationTime, EventDate, EventIdentifier, LastReferencedDate, LastViewedDate, LoginKey, LoginType, LoginUrl, PolicyId, PolicyOutcome, Score, SessionKey, SourceIp, Summary, UserAgent, UserId, Username

Detection tip: Since every record in CredentialStuffingEventStore represents a successful login during a credential stuffing attack, focus on correlating these events with subsequent user activity.

GuestUserAnomalyEventStore

Guest users access Salesforce without authentication. This object identifies when guest users query or interact with unexpected data entities, which could indicate data exposure or abuse.

index=salesforce sourcetype="sfdc:guestuseranomalyeventstore"
| search Score > 0.9 ```replace with a reasonable threshold for your environment```
| table EvaluationTime, EventDate, EventIdentifier, GuestUserAnomalyEventNumber, LastReferencedDate, LastViewedDate, LoginKey, PolicyId, PolicyOutcome, RequestedEntities, Score, SecurityEventData, SessionKey, SoqlCommands, SourceIp, Summary, TotalControllerEvents, UserAgent, UserId, Username, UserType

Detection tip: Watch for guest users accessing custom objects or SOQL commands referencing sensitive fields.

Enhanced Transaction Security Policies and Event Generation

Salesforce’s Threat Detection framework operates independently of Enhanced Transaction Security (ETS), but the two complement each other. In ETS you can define custom, real-time policies that can block or notify when risky behavior occurs.

These policies enrich Threat Detection events with additional context through the PolicyId, PolicyOutcome, and SecurityEventData fields. When no ETS policies are configured, Salesforce still generates default Threat Detection events based on its built-in ML models, but no enforcement actions occur and the policy fields remain empty. In this state, events act as observations only, providing visibility without active response.

References

Salesforce Threat Detection Module Help

SessionHijackingEventStore Object

ReportAnomalyEventStore Object

ApiAnomalyEventStore Object

CredentialStuffingEventStore Object

GuestUserAnomalyEventStore Object