Investigator's Guide to SaaS Incident Response: Part One—Okta Log Fields

As organizations continue to shift to cloud-based or entirely cloud-native environments, incident responders now have the challenging task of researching and deciphering how each SaaS vendor can be both attacked and investigated. In this series, Mitiga incident responders share knowledge we’ve gained from our investigations and threat hunting to provide insight into the key log fields to use when investigating SaaS compromises.

For part one of this series, we will focus on Okta System Logs. The Okta System Log “records system events that are related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems.^1" While Okta System Logs give incident responders an opportunity for both forensic investigation and detection, there are various pitfalls and issues that they might also encounter. This blog will highlight those challenges, offer strategies to overcome them, and pseudocode to help you track sessions in Okta effectively. You can implement the pseudocode provided as an investigation function or use it as a query during an investigation.

Okta System Log Key Fields

The table below provides a list of important fields for tracking sessions, hunting, and investigating in Okta. As with many SaaS vendors, logs can change, new research may be conducted, and investigative techniques must adapt accordingly. Make sure to check back periodically for updates to this table and feel free to reach out to us if we can improve its content. 

While most of these fields are accurate and perform as expected, we have found that the debugContext.debugData.risk and debugContext.debugData.deviceFingerprint fields have inaccuracies and limitations that investigators and detection engineers should be aware of. Even if you are familiar with Okta logs, we recommend reviewing the notes on these two specific fields to understand the highlighted challenges.

‍

Session Tracking

In the event of a compromise to an Okta account, it's recommended to use the fields to track all actions performed by the threat actor in a session, covering both authenticated and pre-authentication stages, as well as actions initiated by the Okta system itself. 

1. authenticationContext.externalSessionId
2. transaction.id
3. debugContext.debugData.emailRequestId
4. debugContext.debugData.authnRequestId

To ensure a thorough investigation, it's also advised to identify all unique identifiers within these fields associated with confirmed malicious events and use them as pivot points for further analysis. It's important to recognize that transaction.id and debugContext.debugData.emailRequestId will always share identical values, whereas the debugContext.debugData.authnRequestId might only occasionally match.

Upon identifying any specific values assigned to these fields, we recommend employing the following filter logic for isolating malicious activity:

• Match malicious authenticationContext.externalSessionId values with authenticationContext.externalSessionId.
  • OR
• Match malicious values of transaction.id, debugContext.debugData.emailRequestId, and debugContext.debugData.authnRequestId to transaction.id, debugContext.debugData.emailRequestId, or debugContext.debugData.authnRequestId

Example pseudo code:

# Define lists of known malicious session and transaction/request IDs

malicious_sessions = ["idxXXXXXXXX"]
malicious _request_ids = [
    "f938cb7b727fe8XXXXXXXXXXXXXXXXXX",
    "16a39fde26f5f6XXXXXXXXXXXXXXXXXX",
    "3513cb19071ddcXXXXXXXXXXXXXXXXXX"
]

# Begin filtering process on Okta data
FOR EACH record IN okta_delta
    IF record's externalSessionId IS IN malicious_sessions
        OR record's transactionId IS IN malicious _request_ids
        OR record's emailRequestId IS IN malicious _request_ids
        OR record's authnRequestId IS IN malicious _request_ids
    THEN
        MARK record as malicious
    END IF
END FOR

Those who are fortunate may not be compromised and only need to review logs for detection engineering. However, during an investigation of a compromise, every piece of information is crucial in building a comprehensive picture. If there are issues with certain fields that you are unaware of, it can significantly sidetrack the investigation and impact the severity assessment of the incident.

We aim to continuously update this page as changes occur, providing the security community with thorough reference materials and insights necessary for confident investigations. We plan to cover other vendors and log sources in the upcoming months, ensuring you have the documentation needed to respond to threats effectively.