Threat hunting in Okta logs
During the last year or so, I’ve been (on and off) really interested in attack and defense techniques related to Okta’s Single Sign-On (SSO) solution. Why? Because so many companies are putting their Identity & Access Management (IAM) in the cloud, not monitoring it, and if an attacker gets access to a user’s account, they have a “skeleton key” to access a ton of applications and data.
I revisited Okta logs recently to think about more security monitoring and threat detection use cases. The intention of this post is to share some threat hunting and security monitoring tips to help defensive practitioners protect their Okta environments from attack. Okta’s system log is well structured and contains a lot of detail about what’s going on in your environment, so it’s a great data source to go hunting in.
A note on security monitoring and threat detection
I’m sharing some tips on things that have helped me and may help you identify malicious behavior in your Okta logs, not a collection of boiler plate detections that may blow your SOC up with false positives. Every company’s network is different meaning that security monitoring and threat detection across organizations is challenging.
Some work will be required to develop your initial threat hunting queries for the logging platform you use, investigate leads, adjust your logic to filter false positives, and develop detections with (hopefully) high precision that alert you to malicious or notable behavior. Attackers change their behavior and innovate (usually when they face resistance). Defenders must do the same and put in the legwork to stay ahead of the game. I’m not a huge believer in “silver bullets” advertised for threat detection and response.
Tip 1: Okta session hijacking
Attackers can spin up a fake Okta sign-on page and socially engineer your users into logging into it with their username, password, and one-time password (OTP). Once a victim authenticates, the attacker can perform a man-in-the-middle (MITM) attack with a tool like evilginx2, stealing the user’s credentials, tokens, and session cookies. The attacker can use the collected artifacts to bypass multi-factor authentication (MFA) and hijack the user’s valid session.
For more information on how this attack technique is carried out, I’d recommend reading the following posts.
One of the ways to hunt for this technique is to look for multiple Autonomous System Number (ASN) values and multiple user agent values in a user’s Okta session.
In Okta’s system log, you’ll find the ASN value in field, securityContext.asNumber and the session ID value in, authenticationContext.externalSessionId. There will be some “normal” behavior to filter out related to push notifications and browser updates, but you should end up with a solid detection once this is complete.
Okta logs a risk level and risk factors under field debugContext.debugData.logOnlySecurityData.risk , but (in my experience) 10s of thousands of these events are logged daily and they aren’t that useful unless they’re correlated with other data sources. Further, high velocity travel-based detections are trivial for attackers to evade.
Tip 2: Administrator privileges assigned to non-admin user accounts
Alice in Sales or Bob in Accounting probably don’t need Okta administrator privileges. If your administrator accounts have a specific naming convention and/or if you pull employee information from a system like Active Directory or whatever your HR team uses, you can hunt for administrator privileges being assigned to non sysadmins.
Okta logs user.account.privilege.grant when administrator privileges are assigned to a user and group.privilege.grant when administrator privileges are assigned to a group.
This hunt/detection methodology is similar to how blue teams can alert on non-IT personnel executing PowerShell commands or scripts that are outside of the known good PowerShell activity that happens in their environment.
Bonus tip: Look for administrator accounts assigning administrator privileges to their own non-admin user account.
Tip 3: Non-admin users accessing the Okta admin console
Following on from tip #2, your list of non-Okta admin users should not be accessing the Okta admin console. Okta logs user.session.access_admin_app when someone logs into the admin console. Simple.
Tip 4: Correlating suspicious Okta logon events with other data sources
As I mentioned under tip #1, Okta logs lots of information regarding the risk level of events under debugContext.debugData.logOnlySecurityData.risk with information like New Geo-Location: POSITIVE, New Device: NEGATIVE, and reasons: Anomalous Device . The challenge is that so many of these events are logged, it’s hard to make them useful without correlating them with other data sources.
Try correlating Okta’s events that have a risk level of MEDIUM or HIGH with other data sources like Google Workspace. If more than one data source is reporting a logon event as suspicious, it is worth triaging the surrounding events to determine if something nefarious is at play.
Tip 5: MFA factors reset or deactivated for admin users
Okta logs the following events when when MFA factors are disabled, suspended, or removed on user accounts. Keep an eye on these things happening on your sysadmin accounts and what those accounts are doing around the time that these events are logged.
system.mfa.factor.deactivateuser.mfa.factor.deactivateuser.mfa.factor.reset_alluser.mfa.factor.suspend
Bonus tip: Okta logs MFA bypass attempts as user.mfa.attempt_bypass. It’s worth alerting on this and triaging these events as they occur.
Tip 6: Sign-on events from anonymization services
Attackers will hide behind services like Tor, Proton VPN, and NordVPN. You can ingest lists into your SIEM of server IP addresses associated with these services (and proxy services) and alert on users logging in (Okta event user.session.start) or performing other actions while connecting from one of these IP addresses.
Tip 7: Brute force push fatigue
If an attacker obtains an employee’s username and password, they may attempt to login to your organization’s Okta portal over and over again, which sends a push notification (approve/deny) to the employee each time. The user may deny the attempts for a while, but eventually become fatigued and approve one of them, granting the attacker access to your environment.
Look for a high volume of failed user.authentication.auth_via_mfa or OKTA_VERIFY_PUSH events followed by a successful push response or login (user.session.start) event.
Tip 8: New API tokens
If an attacker obtains access to an Okta account that has administrator privileges, they may attempt to create an API token as a persistence mechanism. Keep an eye out for newly created API tokens and ensure that the use case/justification for the token is logged per your internal processes: system.api_token.create
Tip 9: Rate limit warnings and violations
Okta rate limit warnings and violations are logged using the event types below. If one of your API rate limits are exceeded, this can leave parts of your environment in a degraded state. The root cause of these events should be investigated and remedied when they’re logged.
app.oauth2.client_id_rate_limit_warningapplication.integration.rate_limit_exceededsystem.client.concurrency_rate_limit.notificationsystem.operation.rate_limit.*system.org.rate_limit.*
Tip 10: Okta ThreatInsight alerts and suspicious activity reports
This isn’t exactly threat hunting, but if a security vendor is logging something and labeling it as suspicious/malicious, I usually want to know about it for situational awareness. Okta ThreatInsight can be enabled in the admin console to provide protection against credential-based attacks such as password spraying and credential stuffing.
Keep an eye on security.threat.detected events, which include the description of the threat that was detected (and prevented if ThreatInsight is in block mode). The debugContext.debugData field contains information about what resources the threat actor interacted with and the client field contains information about where the requests came from.
Additionally, ensure someone is triaging the events that are logged when user’s report suspicious activity on their Okta account (user.account.report_suspicious_activity_by_enduser). These reports can help your security team quickly identify compromised Okta user accounts. Ensure that this feature is turned on and that someone is looking at the alerts. Likely false positives can be filtered based on the historical logon behavior of users.
Exploring and learning new data sources for threat hunting
When I’m learning a new data source and thinking about ways it can be used for threat hunting and investigations, I usually start by exploring the various fields that are available in the logs, the most common and rare values that are logged in those fields, and monitoring my own account. I think monitoring your own accounts and hosts is a great way to get a feel for what normal looks like. I’d recommend keeping an eye on what your own accounts and hosts are doing and what actions are being performed against them by other users and systems.
Wrap up
Okta’s system log is well structured and contains a great level of detail about what’s going on in your IAM environment. I think it’s a highly useful data source for threat hunting and can be correlated with other data sources to produce detections with high precision. I hope other security teams find these threat hunting tips useful. Feel free to reach out to discuss any of these tips in more detail.
Useful resources
- Okta’s system log event types
- Dorothy: A tool to help security teams test their monitoring and detection capabilities for their Okta environment
- Splunk’s detection rules
- Elastic’s detection rules
