.jpg)
Background
The recent Salesforce–Drift campaigns are yet another example of SaaS “supply-chain” lateral movement. While detection and awareness of these operations have improved in recent years, many organizations still lack full visibility into their SaaS technology stack.
Beyond the various actors and intrusion sets associated with theCom (including groups such as ShinyHunters, Scattered Spider, and Sp1d3rHunters), many others continue to exploit SaaS applications for data collection, lateral movement, and persistence.
Leveraging SaaS platforms has become common across numerous intrusions: compromising GitLab and GitHub accounts, stealing and abusing Slack tokens, misusing Workday accounts, co-opting infrastructure-as-a-service tools, and pillaging platforms that store sensitive operational data.
While the SalesDrift intrusions have drawn significant attention and placed Salesforce in the spotlight, it’s far from a new target. As early as spring 2025, rumors were circulating about a tangled web of cybercriminal actors (Scattered, some may say; Shiny, others might) quietly compromising Salesforce environments. In fact, members of theCom have been experimenting with Salesforce persistence techniques for years.
One of the most striking methods involves abusing Salesforce’s support for multiple identity providers. By standing up a phantom Identity Provider, attackers can maintain persistent access, bypassing centralized identity management entirely while their rogue provider continues authenticating in the background.
In a previous blog, we examined the GitHub Audit Log and the many ways to identify compromised GitHub organizations, accounts, and the activity performed within them.
This entry focuses on the forensic evidence left behind in Salesforce, a platform so extensible and feature-rich that it often falls outside traditional forensic playbooks. With near-limitless customization, Salesforce enables organizations to create custom objects for storing a vast range of sensitive data, data that can easily escape standard incident response workflows.
In this post, we’ll break down the available telemetry sources within Salesforce, how they can be used to investigate compromise and persistence, and what security teams should understand about the limits and timing of that data.
Analyzing Salesforce Activity
Available Telemetry in Salesforce
Salesforce provides several sources of telemetry that can be leveraged for security monitoring and investigation, including:
- Login History – captures user login activity and authentication details.
- Setup Audit Trail – records administrative and configuration changes made within the Salesforce environment.
- Event Monitoring – logs nearly every access, modification, update, and deletion event across the platform.
- Field History Tracking – extends field-level change history retention from the standard 18 months to indefinite.
- Object Records – include metadata showing when each record was created, modified, and by whom.
Salesforce bundles features and services into seven different editions. The various editions have access to different levels of information. The Developer edition is noted as having access to Event Monitoring and Field History tracking, however in our testing these features were not accessible.
*Available according to Salesforce documentation, but could not be found in our testing.
Login History
Login History is included in all Salesforce editions and contains several useful fields, including SourceIp, Browser, Application, LoginTime, and LoginUrl, which capture details about when, where, and how a user logged in.
In Salesforce’s LoginHistory records, each user is identified only by an internal UserId GUID (e.g., 0055g00000A8vYZAAZ). Because this ID isn’t human-readable or consistent with external identity systems, it can make analysis more difficult. To correlate login activity with real users, analysts need to query the User table and join it to the LoginHistory records, this reveals key details like the user’s email address, username, and role.
Within Abstract Security we pull the User data into our Identity Model, enabling enrichment of Salesforce LoginHistory events and any object modifications with the appropriate UserName from the User table.
Login History Timing and Retention
Salesforce retains Login History events for six months within the platform (Salesforce documentation). Most login events are generated in near real time, typically within a few seconds of the user’s login.
In rare cases, however, Login History records may be delayed, sometimes by several hours after the original login event occurred. Analysts should account for this delay when correlating authentication activity across data sources.
Login Forensics
Salesforce Enterprise, Unlimited, and Developer editions can optionally include Login Forensics. This feature extends Login History retention for up to 10 years and adds Suspicious Activity Detection for authentication and authorization events (Salesforce documentation).
Setup Audit Trail
The Setup Audit Trail records configuration changes made within Salesforce. These can include administrative actions such as adding new users, modifying the identity provider, or enabling session security policies. It also tracks interface-level changes, like updates to page layouts. In short, nearly any change made through the Setup menu is captured by the Setup Audit Trail.
Setup Audit Trail events contain a limited set of fields, primarily the event Id, the Action performed, the CreatedDate of the modification, and the user who made the change (identified by their UserId or DelegatedUser).
The Setup Audit Trail captures events such as password changes, updates to authentication providers, and other administrative modifications. A full list of tracked actions is available in the Salesforce documentation.
Setup Audit Trail entries are typically recorded in near real time. However, as with other Salesforce object histories, event creation can occasionally be delayed, sometimes by up to 24 hours. These records are retained for up to 180 days within the platform.
Event Monitoring
Event Monitoring is available to subscribers of Salesforce’s Enterprise, Unlimited, and Developer editions, and can be purchased as an add-on for other subscription tiers. It records nearly all object-level activity performed by users—including creations, modifications, executions, and data retrievals—providing some of the richest telemetry available within Salesforce.
This data is particularly valuable for:
- Detecting anomalous data retrievals that may indicate reconnaissance or exfiltration of sensitive information.
- Reconstructing user activity timelines to understand what actions were taken, by whom, and what data was exposed.
There are almost 50 distinct event types available through Event Monitoring, covering actions such as API calls, report executions, and login activity. A complete list is available in Salesforce’s documentation. Each event type can have a slightly different schema, but most include core fields such as Timestamp, EventType, and UserId_Derived.
While individual events are generated in near real time, the log file delivery process varies by subscription:
- Developer Edition – log files retained for 1 day
Enterprise Edition – log files retained for 30 days - Essentials, Starter, ProSuite, and Professional Editions – not available
According to Salesforce’s Event Log File API documentation,
“An event generates log data in real time. However, daily log files are generated during non-peak hours the day after an event takes place. Therefore, daily log file data is unavailable for at least one day after an event. For hourly log files, depending on event delivery and final processing time, expect an event to take 3–6 hours from the time of the event to become available in the log file.”
In practical terms, Event Monitoring offers near-real-time insight for active investigations but introduces delays in finalized log file delivery, meaning analysts must account for this lag when performing time-sensitive correlation or detection.
Threat Detection
Salesforce Enterprise, Performance, and Unlimited editions can optionally include Threat Detection (Salesforce documentation).
Most Threat Detection alerts focus on identifying anomalous user behavior—for example, when a user opens significantly more reports, views, or objects than normal. Additional capabilities, such as detecting session hijacking, rely on internal Salesforce telemetry that isn’t available through standard event logs.
Threat Detection events are published through the Event Monitoring API and are typically delivered in near real time.
Object forensics and Field History Tracking
Beyond Event Monitoring data, Salesforce Objects themselves contain valuable metadata that can be used to build a forensic timeline of record creations and modifications.
By default, Salesforce retains 18 months of object history. When Field History Tracking is enabled, that history is preserved indefinitely, allowing analysts to trace changes long after standard retention windows would have expired.
Summary
Salesforce exposes a wealth of telemetry that can help analysts investigate intrusions, trace suspicious user activity, and understand how data moves across the environment. While Enterprise and Unlimited editions offer the most granular visibility, even baseline Salesforce editions contain valuable signals for identifying unauthorized access or configuration changes.
At Abstract Security, we’ve built native integrations to automatically collect and normalize telemetry from Salesforce, along with GitHub, GitLab, Cloudflare, and hundreds of other SaaS platforms. Our pipeline ensures every event is captured and preserved in real time, giving defenders complete visibility across their SaaS ecosystem without the risk of data loss or fragmentation.