Salesforce Log Analysis Guide: Investigating Data Exfiltration Using Event Logs

III. Step-by-Step Log Analysis Walkthrough

This section provides a systematic approach to investigating potential data exfiltration, focusing on correlating data across log types.

Step 1: Perform Initial Impact Assessment

Before diving into extensive log analysis, understanding the potential scope of impact can help to focus and prioritize the analysis.

Determine User Access and Permissions: Given the complex interplay of Profiles, Permission Sets/Groups, Sharing Rules, and Role Hierarchies, assessing a user's permissions can be challenging. Tools like Security Center or the Authenticated and Guest User Access Report and Monitoring Tool available on AppExchange offer a rapid and comprehensive overview of which objects and fields a user has permission to access, alter, and export, often highlighting sensitive fields.

Assess Privilege Levels: If the initial assessment reveals that a user had broad access to sensitive data and could make significant changes, a more in-depth analysis of specific accessed and altered data may be necessary. Conversely, adherence to the principle of least privilege helps limit the impact of any security incident.

Step 2: Identify Suspicious Login Activity

The investigation begins by identifying any unusual login patterns that might indicate a compromised account.

Objective: Detect logins from unexpected locations, times, or associated with unfamiliar applications.

Data Sources: Login Event Type (ELF) or LoginEvent (RTEM/ELO).

Analysis Steps:

1. Filter login events by User ID (or UserId) for the user(s) of interest.
2. Examine Login Time (or EventDate) for logins occurring outside of regular working hours or on holidays.
3. Review Client IP (or SourceIp) and Country Code (or Country) for logins originating from unexpected geographic locations (e.g., a user typically located in the US logging in from a country in Europe).
4. Look for patterns of LOGIN_STATUS that suggest automated attacks, such as multiple LOGIN_ERROR_INVALID_PASSWORD attempts followed by a LOGIN_NO_ERROR.

Correlation Tip: Extract the LOGIN_KEY (or LoginKey) and SESSION_KEY (or SessionKey) from any suspicious login events. These unique identifiers will be crucial for correlating subsequent activities back to this specific login session.

Example 1: Anomalous Login Location

Imagine your organization's security team identifies a user whose primary location is the U.S., but the Login Event Type (ELF) logs show multiple successful logins for this USER_ID (e.g., 005FL000004coZNQAY) from "DE" (Germany) on a particular date (e.g., 2025-06-11). This geographic anomaly, especially if it's inconsistent with the user's travel history or typical access patterns, warrants immediate investigation. The LOGIN_KEY and SESSION_KEY associated with these German logins should be noted for cross-referencing with other event types.

Step 3: Analyze API Activity for Data Exfiltration

After identifying suspicious logins, the next step is to investigate what actions were performed through API calls during those sessions. API activity is a common vector for data exfiltration.

Objective: Identify specific data queries, the objects involved, and the volume of data retrieved via API.

Data Sources: API Total Usage Event Type (ELF), ApiEvent (RTEM/ELO), REST API Event Type (ELF).

Analysis Steps:

1. Filter API events using the LOGIN_KEY (or LoginKey) and SESSION_KEY (or SessionKey) obtained from the suspicious login.
2. Specifically look for events associated with a third-party connected application by filtering on ConnectedAppId.
3. Examine the API_RESOURCE (ELF) or Operation (RTEM/ELO) fields for values indicating data retrieval, such as query, queryAll, or describeSObjects.
4. Review the Query field (RTEM/ELO) to see the exact SOQL queries executed, understanding what specific data was requested.
5. Check QueriedEntities (RTEM/ELO) to determine which Salesforce objects were targeted (e.g., Account, Contact, Opportunity, User).
6. The ROWS_PROCESSED (ELF) or RowsProcessed (RTEM/ELO) field is critical — a value greater than zero confirms that data records were returned to the client.
7. Cross-reference Client IP (or SourceIp) and User ID (or UserId) to ensure consistency with the suspicious login details.

Correlation Tip: The REQUEST_ID (ELF) or RequestIdentifier (RTEM/ELO) can link multiple API events that are part of a single transaction, helping to reconstruct a complete sequence of API calls.

Example 2: API Query and Data Exfiltration
Following the anomalous login from Example 1, further investigation using the identified LoginKey in ApiEvent (RTEM/ELO) logs might reveal an ApiEvent with a ConnectedAppId linked to a third-party application. The Operation could be "QueryAll," and the Query field might display "Select AccountNumber, Active__c FROM Account". The RowsProcessed field indicates that 16 records were returned. This directly confirms that specific account data was queried and likely exfiltrated. The detailed information in ApiEventStream (RTEM) even shows the IDs of the 16 downloaded records.

Step 4: Analyze Bulk API Activity for Large-Scale Data Extraction

Bulk API is often utilized by data loading tools for efficient handling of large data volumes. Investigating these events is crucial for identifying mass data exfiltration.

Objective: Pinpoint large-scale data extractions, identifying the specific objects and volumes.

Data Sources: Bulk API Event Type (ELF), Bulk API 2.0 Event Type (ELF), and BulkApiResultEvent (RTEM/ELO).

Analysis Steps:

1. Filter Bulk API events by USER_ID and CLIENT_IP that align with any suspicious activity identified in previous steps.
2. Look for OPERATION_TYPE values of "query" or "queryAll," which are indicative of data extraction.
3. Examine ENTITY_TYPE to see which objects were accessed in bulk (e.g., "Contact," "Account," "Opportunity").
4. For Bulk API 2.0 Event Type (ELF), pay close attention to the RECORDS_PROCESSED field — high values here are a strong indicator of large-scale data exfiltration.
5. Take note of the JOB_ID / JOB_STATUS field values to identify Bulk API Jobs and whether or not they have completed. If the job has not expired or been deleted, you can view the job details in your Org under Bulk Data Load Jobs.

Correlation Tip: Use the LOGIN_KEY (or LoginKey) and SESSION_KEY (or SessionKey) to connect Bulk API operations to the overall user session, and REQUEST_ID to track individual bulk transactions.

Example 3: Large-Scale Data Extraction via Bulk API

A security team investigates a user who recently resigned. By querying Bulk API 2.0 Event Type (ELF) logs, they discover several "query" operations for ENTITY_TYPE "Contact" and "Account." These activities originate from an unfamiliar CLIENT_IP and occurred during off-hours, aligning with the departing user's USER_ID. The RECORDS_PROCESSED field for these events shows an extraction of over 2000 records in a single operation. This combination of unusual IP, off-hours access, and high volume indicates potential unauthorized large-scale data exfiltration.

Step 5: Investigate Specific Queries

Data in Salesforce is often interrogated using Salesforce Object Query Language (SOQL). Understanding the information in a given SOQL query is critical to determining what data was targeted and how.

Data Sources: Unique Query Event Type (ELF), ApiEvent (RTEM/ELO), BulkApiResultEvent (RTEM/ELO).

Analysis Steps:

1. Review QUERY_IDENTIFIER for the exact SOQL queries executed. Sensitive objects queried often include entities such as Cases, Accounts, Users, Contacts, or Opportunities.
2. Review the Query field (RTEM/ELO) to see the SOQL queries executed by the ApiEvent to understand what specific data was requested.
3. Review BulkApiResultEventStore (RTEM/ELO) logs to determine if any data may have been downloaded.

IV. Conclusion

Systematic analysis of Salesforce logs, coupled with correlation across different event types using common identifiers like login keys and request IDs, can form an important part of effectively investigating security incidents and determining the scope of any data exfiltration. By meticulously examining anomalous login patterns, reviewing API queries, and scrutinizing bulk data operations, organizations can reconstruct event timelines and understand the full impact.

Next Step Suggestion: To enhance your organization's defensive capabilities, establish a routine monitoring strategy for these critical event types. By understanding normal baseline activities in your environment, you can more easily identify deviations, enabling early detection and problem prevention rather than solely reacting to incidents.

---

Understanding SOQL Queries

What is SOQL? How do I interpret a SOQL Query?

Salesforce Object Query Language (SOQL) is Salesforce's proprietary query language, similar to SQL, used to search your organization's Salesforce data for specific information. It allows you to select specific fields from Salesforce objects and filter records based on various conditions.

Imagine your Salesforce data is like a massive library with many different filing cabinets. You might have a cabinet for Accounts (companies you work with), another for Contacts (people at those companies), and one for Opportunities (your potential deals). SOQL is simply a very structured way of writing a request slip to the librarian (Salesforce) to find specific information for you.

**SELECT: What Information You Want**
This is the first part of your request. Here, you tell the librarian exactly which pieces of information you want from each file.
Example: SELECT Name, Industry
Simple English: "When you find the files I want, please write down only the Name and the Industry from each one."

**FROM: Where to Look**
Example: FROM Account
Simple English: "Look for these files only in the Account filing cabinet."

**WHERE: How to Filter**
Example: WHERE Industry = 'Technology'
Simple English: "Please only pull files that have a label that says 'Industry' with the word 'Technology' on it."

**ORDER BY: How to Sort the Results**
Example: ORDER BY Name ASC
Simple English: "After you find everything, please sort the results alphabetically by the company's Name."

**LIMIT: How Many to Get**
Example: LIMIT 10
Simple English: "Even if you find hundreds of matching files, please stop after the first 10 and just bring me those."

Putting It All Together:
SELECT Name, Industry FROM Account WHERE Industry = 'Technology' ORDER BY Name ASC LIMIT 10

"Please go to the Account cabinet (FROM). Look for all the files where the Industry is 'Technology' (WHERE). From those files, write down just the Name and Industry (SELECT). Finally, sort that list alphabetically by Name (ORDER BY) and only give me the first 10 you find (LIMIT)."

Important Rules:

- You cannot ask for everything using SELECT * — you must list the specific fields you want.
- SOQL is read-only — you can only use it to read information, not change or delete records.
- The maximum number of results you can return in a single request is 2,000. If more records match, the platform re-runs the query in subsequent requests and iterates through until complete.