Forensic Behavioral Analysis: Finding Anomalies in Salesforce Logs

Following the primer on investigating Salesforce security incidents and how to correlate logs to reconstruct what happened, customers have asked for more proactive approaches to detect and prevent anomalous activities in their environments using Shield Event Monitoring. Efficient anomaly detection and response make organizations more resilient, reducing disruption, cost, and impact.

The increasing use of Salesforce in many organizations generates large quantities of logs to track performance, API transactions, user account activities, and more. These data streams can support security monitoring for both insider threats and external attacks. Detecting unusual or anomalous activities using these logs involves analyzing behavior over time of user accounts, including humans and non-human identities such as integration accounts and AI agents. Anomaly detection is most effective when behavior is consistent and predictable, which is often the case in Salesforce usage, taking seasonality into account. 

This blog post provides an overview of behavioral analysis for cybersecurity, and forensic purposes, concentrating on Real-time Event Monitoring (RTEM). Methods presented in this article can also be applied to non-realtime sources, including low-latency Event Log Objects (ELO), Event Log Files (ELF), and historical logs.

What is an anomaly? 

An anomaly is any activity of a user account that is sufficiently different from the historical activity of the same user account. The Threat Detection events that come out-of-the-box with Salesforce Event Monitoring are designed to detect anomalies using certain features that are broadly applicable to all customers, and are not tuned to any specific environment to reduce false positives. Creating customized detections for your Salesforce environment requires an understanding of what is usual, and types of deviations to look for.

Anomalies can occur when a malicious attacker or insider misuses a Salesforce user account. For example, unauthorized access to Salesforce data can result in various patterns, including:

• Rapid-fire access: More than usual requests or queries within a short timeframe 
• Access spikes: User account accesses a higher quantity of data than usual
• Unusual object access: Access to objects not usually used or not intended to be accessible
• Unfamiliar IP addresses: Logins from anonymizing services or a never seen before Autonomous System Number (ASN).
• Failed attempts followed by success: Multiple failed logins followed by successful data retrieval
• Rare or unseen behavior: Features and patterns not previously observed 

The following ListViewEvent logs show Emma Martin’s account being used to access more data than usual and objects never accessed before on March 2.

This change in behavior of Emma Martin’s account triggered multiple anomaly alerts, including access spikes, escalated access scope (from “My” to “All” list views), higher than usual requests per minute, and never-before-accessed objects. 

You can use Python to run remote SOQL queries of Salesforce event logs in the past 180 days, store results in an OrderedDict dictionary, and create anomaly detections for spikes, bursts, new access, and scope increases. For example, the code snippet below detects daily spikes in the volume of data accessed (RowsProcessed) by each user account in LiveViewEvent logs. For users with a sufficient (thick) baseline of historical activity, it calculates a Z-score to determine how far the daily row total deviates from the user account’s normal activity, alerting when the Z-score exceeds a defined threshold.

# Import Salesforce and data structure libraries
import numpy np
import pandas from pd
from collections import OrderedDict
from simple_salesforce import Salesforce
# Query event logs
sf = Salesforce([user configured domain and key])
listviewSoql = """
    SELECT EventDate, RowsProcessed, DeveloperName, Records, NumberOfColumns, Username, UserId
    FROM ListViewEvent
    WHERE EventDate > [startdate] AND EventDate < [enddate]
"""
listviewResults = sf.query_all(listviewSoql)
... [parse logs in OrderedDict, load into data frame, and compute per-user baseline statistics]
# Detect daily volume/row spikes
   daily = (
        df.groupby(["user_id", "date"])
        .agg(rows_processed=("rows_processed", "sum"),
             user_name=("user_name", "first"))
        .reset_index()
    )

    merged = daily.merge(baseline["row_stats"], on="user_id", how="left")

    # Thin-baseline path
    thin_mask = merged["baseline_days"] < MIN_BASELINE_DAYS
...
    # Z-score path
    thick = merged[~thin_mask].copy()
    thick["zscore"] = np.where(
        thick["std_rows"] > 0,
        (thick["rows_processed"] - thick["mean_rows"]) / thick["std_rows"],
        0.0,
    )
    hits = thick[thick["zscore"] >= SPIKE_ZSCORE_THRESHOLD].copy()
...

Running the logs from Emma Martin’s account through the Python anomaly detectors triggered multiple types of alerts. To reduce noise and alert fatigue, you can correlate and consolidate separate findings that represent the same underlying behavior anomaly, as shown in this table, combining risk scores into an overall value. For example, a weighted sum of these findings could be computed as (Row Spike x Weight1) + (Scope Increase x Weight2) + (View Burst x Weight3) + (New Access x Weight4). The weights can be tailored to the customer environment.

Similar methods can be applied to logs containing API Events and SOQL queries to detect anomalous spikes, bursts, new access, and scope increases.

Anomaly Visualization

Data visualization can be useful for proactive analysis to help identify rare or anomalous patterns that can inform the development of new detection rules, and for daily monitoring dashboards to quickly spot changes and evolving threats. For example, visualization of Event Monitoring data can help detect deviations from usual behavior, such as Report Export events. A red flag is raised when users export multiple reports they have never accessed before. This heatmap highlights first-time report downloads, revealing hotspots where users are accessing reports at higher volumes. It also shows seasonality— —for example, consistent weekly patterns for certain users, as well as increased report downloads in late August and early September ahead of Q4 and large events.

A classic insider threat involves an employee taking large amounts of data shortly before leaving to work for a competitor. This “leaver” pattern often appears as increases to data or objects never previously accessed. 

This heatmap shows users accessing objects for the first time, with a potential “leaver” red flag on the right. The earlier period shows more hotspots due to less historical data and some repeated patterns,  suggesting seasonality. Over time, activity stabilizes, with most users accessing the same objects. 

However, a red hotspot stands out where a user deviates significantly from this pattern, indicating potential risk and warranting further explanation. In contrast, the large area of blue reflects stable, predictable activity from most users during the later time period. When a user suddenly accesses a high number of previously unseen objects, it raises a red flag and can generate automated alerts of anomalous activity. Just a few users have a hotspot in July and August.

Detecting rare or never seen before features can be applied to specific fields, such as user agent. For example, when Emme Martin normally accessed Salesforce, her user agent started with “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7).” When her account was misused by malicious actors, the user agent was different, and had never been seen before. This type of deviation can indicate access from a different device and help confirm potential account compromise. 

User Categorization

In the security incident scenario, an obvious sign of suspicious activity was the change of behavior from Emma Martin as a normal user to someone exhibiting higher and broader information access. Using activity logs to automatically classify users based on their behavior — distinguishing between “Normal users,” “Power Users,” “Admins,” and “Integration accounts” — helps detect account compromise and misuse, while enabling more targeted alerting by user type.

Contextualizing user classes:

• Normal Users: Active during business hours; rarely active on weekends.
• Power Users: Higher volume of data consumption than standard normal users.
• System Admins: High levels of ongoing activity, often including weekends.
• Integration Accounts: Predictable, steady stream of activity 24/7.

These charts analyzing events from an operational Salesforce system show that different user types access certain objects more than others and make specific API calls more than others, supporting development of user categorization models.

Data-oriented behavior categorization	Activity-oriented behavior categorization

Time Series Analysis and Cross-log Correlation

Not every spike in activity is a threat. Smart detection models factor in seasonality to reduce false positives. Certain patterns only emerge over months or years. For example, we expect an increase in data activity at the end of every quarter and a significant decrease over weekends. Analyzing long-term logs allows for robust baselining that accounts for “seasonality,” such as end-of-quarter spikes or decreased activity over weekends.

Recent advances in time series analysis can also help improve anomaly detection by better accounting for patterns that repeat over time. Newer machine learning models like Moirai, built by the Salesforce Research team, can recognize temporal patterns at multiple  frequencies (e.g. weekly, monthly, annually) and distinguish expected cyclical behavior from true deviations. 

Because it uses a transformer-based architecture, Moirai can handle multiple data signals simultaneously—such as list views, data exports, and API calls—allowing it to identify correlations across activities that may not be visible in a single data source. Performing cross-log correlation can also provide a stronger signal for anomaly detection methods, such as increases in rows processed across multiple logs. For example, looking at scope increase across ListView, Report, and API logs for a user account accessing objects outside of usual behavior patterns, provides a stronger anomaly than one behavior in isolation.

Another benefit is that Moirai is available pre-trained and ready to use, similar to other out-of-the-box foundational models. This allows teams to treat it as another powerful tool in the toolbox, getting started quickly without the massive resource investment of training a model from scratch.

Making Effective Use of Anomaly Detection

Anomaly detection is a powerful way to find “digital needles” in a massive haystack of event logs, but it must be applied strategically. 

Cost Benefit Analysis: Consider whether statistical anomaly detection will produce meaningful results or unnecessary noise. A simple cost benefit analysis can help determine whether a statistical approach is worth the investment, especially when factoring in the effort required to investigate false positives. 

False Positive Tolerance: More sensitive anomaly detection with higher false positive rates may be justified when the cost of missing a malicious attack is high. For example, confirmed ListView anomalies that enable you to terminate a session and prevent data from being exfiltrated is a high value, high-impact outcome. A missed data breach can cost millions, whereas investigating a false positive alert costs relatively little.

Actionable Anomalies: It’s also important to have a clear plan for how anomaly detection is used. Define the specific security risk each detection is meant to address and the path to resolution when it triggers. If an anomaly alert isn’t actionable, it’s an obstacle. If you can’t differentiate between someone stealing information and an employee exporting data as part of their job, then alerts on such activities will be too ambiguous to be useful. Opting, when possible, for simpler and explainable models will make it easier to investigate anomaly alerts and identify false positives compared to overly complex, difficult to understand models. 

Continuous Improvement: You should also identify likely false positives to determine whether they can be reduced. For example, if seasonal patterns in user behavior aren’t accounted for, teams may spend excessive time investigating expected activity.  

The ultimate measure of success for your anomaly detection is the ability to enable an efficient and effective response to genuine threats. As you implement anomaly detection and the threat landscape changes, regularly test your assumptions to ensure they are still valid and deliver valuable results.

Salesforce Event Monitoring is the critical foundation for forensic behavioral analysis and anomaly detection. To dive deeper into the specific log files, event types, and real-time monitoring and response capabilities discussed in this post, explore the Salesforce Log Analysis Guide.