Mitiga at RSAC 2025: Visit our booth, attend speaking sessions, and schedule a meeting with us!

The following article describes best-practices for threat hunting in Okta. For those who wish to hunt for malicious activities associated with the recent Okta breach, we advise focusing on the following events in Okta System Log:

As the Okta breach event is still unfolding, it is unclear how far this breach may propagate and what influence it has on Okta customers. It is, however, extremely likely that any such potential abuse will leave traces in Okta logs (as well as other logs of potentially compromised systems). But Okta logs are not easy to investigate, so you need to know where to start your research.

Once more into the breach...  

In this blog post, we start with an overview of Okta Logs, identify the relevant fields, and provide pro tips for you to review.

Okta log fields and events  

Okta Logs can be accessed using two methods. The first one is to use the Okta Admin Console, which enables an administrator to view the logs of the system, but they can sometimes be abridged, and thus, several fields may be missing. The other method is to use a collector to transfer the logs into a log repository and analysis platform, such as Splunk, which will provide more verbose logs.  

Mitiga’s research team compiled an initial list of log fields and log events that you should be looking at to detect abnormal activity quickly. The following table is constantly updated as our research and threat hunts continue.

Important Okta log fields and events to monitor

Things you may not know about Okta

What is not captured in Okta logs?

While the table represents the set of events to keep an eye on, there are some events that go beyond logging. The following list contains an analysis conducted on items that are either not logged by default log configuration or cannot be clearly identified.

  • API Tokens. These tokens may enable threat actors to perform actions with the same privileges as the user who created them. Since only administrators can create those API tokens, the privileges can be high. Currently, logs do not provide enough information to distinguish between actions performed using API Tokens or the users themselves. The elevated/admin privileges in combination with a lack of transparency over their usage may create a high risk of unauthorized activity.
  • Okta Admin console. The console provides overall control over the Okta instance. While write access (edit) to the console is logged, read access (read) is not logged at all. That oversight may enable threat actors to gain access to sensitive information without being detected.

Actions triggered by Okta

It is important to remember that Okta itself generates a number of back-end operations and transactions. While the majority of its tasks are maintenance, certain events could be of use.  

Several system events can be easily detected with the username system@okta.com and the user type SystemPrincipal. However, several events are just system reactions to user behavior (such as changing passwords, for example).

Events, which are logged under the user system@okta.com and the user-agent null, are predominantly maintenance tasks. However, there could potentially be interesting activities, such as import actions (for example, importing groups of users from external sources).

Authentication servers, SSO applications

One of the most important parts of Okta activity is processing authentication events. Upon review of logs, we noted interesting facts regarding user connectivity. Namely, the same user can be associated with multiple IP addresses from multiple different countries. After further investigation, we found that in several cases, when a user authenticates using a service, the event of authentication originates from a different IP address.

This is generally true for SSO logins to applications offered in the client’s portal. For example, logging into Google Workspace (also known as Google G-Suite ) via the Okta console triggers an app.auth.sso event from a distant IP address, which could be Google Workspace IP address.

Token granting users

We encountered several users, which serve a specific purpose in the Okta environment. They maintain the same routine:

  1. Receiving a successful authentication from the user
  1. Granting the user two types of tokens:
  • ID token
  • Access token

Each time this pattern repeats, there are multiple IP addresses that these token-granters originate from. These token-granters have neither targetAlternateId nor user_name.  

Significance and origin of the IP address remains under further investigation.

token granting usersh

Jamf & Okta Phenomenon

During an active Okta session on an endpoint that also has an active Jamf, there are “keep-alives” that are sent from the user’s computer.

The keep-alives are a couple of events each time, as shown in the picture:

Jamf & Okta Phenomenon

On several of the users, we noticed different IP addresses from different countries. If there is an active Okta session and Jamf and the IP address of the computer is changed (using a VPN), a keep-alive is sent from the new IP address. The significance and the origin of the IP address remains under further investigation.  

It should be noted that in situations where a company also has Jamf, it can be used to mark the dominant IP address of the user’s PC. This way, if two computers are working simultaneously from two different IP addresses, this “keep-alive” behavior can help assist incident responders find suspicious IPs performing possible malicious activities.

What to do now?

We are currently at the beginning of the incident, so there are many issues that are not yet known, and investigation efforts are ongoing. Additional information will be posted as soon as it is available.  

We recommend reading Or Mattatia’s “10 Recommendations for Your Organization to Increase Readiness Following the Okta Breach ” to understand the first steps that you should consider taking when dealing with this incident. Also, stay tuned for the latest updates regarding the Okta incident.  

If you are currently being impacted by the Okta breach or are seeking guidance on what to look for, please reach out to our emergency services:  

  • United States: +1 (888) 598-4654
  • United Kingdom: +44 (20) 3974 1616
  • Israel: +972-3-978-6654
  • Singapore: +65-3138-3094
  • Email: emergency@mitiga.io

Or fill out our emergency incident response contact form. We're here to help if you need us (but we hope you don't.)

This post was originally published on March 22, 2022 and updated to reflect new information.

Read the blog: 10 Recommendations for Your Organization to Increase Readiness Following the Okta Breach

LAST UPDATED:

January 23, 2025

Don't miss these stories:

Make Cloud Attacks Yesterday’s Problem with Mitiga at RSA Conference 2025

Visit Mitiga at booth number N-4618 at RSA Conference 2025 to learn about cloud detection and response.

Uncovering Hidden Threats: Hunting Non-Human Identities in GitHub

In the last few days, two compromised GitHub Actions are actively leaking credentials, and a large-scale OAuth phishing campaign is exploiting developer trust.

Can vulnerabilities in on-prem resources reach my cloud environment?

What risk does this Zoho password manager vulnerability present, and could this on-prem vulnerability impact cloud environments as well?

Log4Shell - identify vulnerable external-facing workloads in AWS

Cloud-based systems should be thoroughly searched for the new Log4j vulnerability (CVE-2021-44228). But this is a daunting task, since you need to search each and every compute instance, from the biggest EC2 instance to the smallest Lambda function. This is where Mitiga can help.

How Transit Gateway VPC Flow Logs Help Incident & Response Readiness

In this blog, we will focus on the security and forensic aspects of Transit Gateway VPC flow logs and expand the way they can be used by organizations to respond to cloud incidents.

Uber Cybersecurity Incident: Which Logs Do IR Teams Need to Focus On?

On September the 16th, Uber announced they experienced a major breach in their organization in which malicious actor was able to log in and take over multiple services and internal tools used at Uber. What are some of the logs that IR teams should be focusing on in their investigation?