Hunting in Okta

Hunting in Okta

Okta is the front door to your entire SaaS kingdom. Every user, every app, every authentication event flows through it — which makes it one of the most critical systems to monitor for security threats and one of the most dangerous to ignore. LAPSUS$, Scattered Spider, and a long list of other threat actors have proven that attackers know this. Let's do some threat hunting (and detection engineering) to get a handle on what's happening in your Okta environment.

Throughout this document, we'll list audit log events of interest you can use as part of your hunting. There's a longer list at the bottom, but the ones called out in the main body are the ones we've found most useful in practice. Also, props to David French (@threatpunter) whose excellent Okta hunting research forms the backbone of much of this guide — go read it.

---

Thoughts on Okta

Okta is the front door

Okta isn't just another SaaS tool. It's the authentication layer sitting in front of most SaaS tools your organization uses. Compromise Okta and you don't just compromise one app — you compromise everything behind it. That's why it's a tier-one target for attackers and why it deserves tier-one monitoring.

Note we said "most". Many products either charge an SSO tax they you may have chosen not to pay or don't have SSO available at all. Further some products allow local AND SSO accounts. Just like a house, while Okta may be the front door, there are likely other doors (and windows) that may be in use for access.

Unlike GitHub (which logs who did what to which repository), Okta logs who authenticated as what, from where, to access what. The identity dimension is front and center in every event. This means your hunts are often about answering questions like: Is this really the person they claim to be? Are they acting consistently with their normal patterns? Did someone just get elevated access they shouldn't have?

The signal-to-noise challenge

Okta's System Log is rich. It's also enormous. A mid-sized company can generate tens of thousands of events per day just from normal authentication activity. Further, the information in the logs is dense. The debug section of each log can have very useful breadcrumbs when it comes to alerting and hunting; however these debug fields also contain a LOT of noise that isn't useful to.. well, probably anyone.

The solution isn't to look at everything. It's to know which events actually matter and build your hunts around them.

---

What's in Okta

Authentication events

Authentication is the core of what Okta does, and user.session.start is the most important event in the log. Every successful login produces one. Failures produce user.authentication.auth_via_mfa failures, lockout events, and more. When you're hunting, you're not just looking for failures — you're looking for patterns. Logins from unexpected geographies, at unusual hours, from anomalous user agents, or with session characteristics that don't match prior behavior.

user.session.start is your bread and butter. Everything interesting starts here.

MFA and factor management

MFA is your primary control against credential-based attacks. When it gets disabled, suspended, or removed, that's a critical signal — especially on privileged accounts. French highlights this in his research: keep a close eye on MFA factor changes on admin and sysadmin accounts, and look at what those accounts do in the window immediately surrounding those events.

Alert on user.mfa.attempt_bypass as a matter of policy — every single occurrence is worth triaging. There's essentially no legitimate reason for a bypass attempt that doesn't warrant a human looking at it.

Admin privileges and API tokens

Administrative accounts in Okta are crown-jewel targets. If an attacker gets admin access, they can create API tokens (system.api_token.create) as a persistence mechanism — an API token provides ongoing programmatic access that doesn't require interactive MFA and doesn't expire by default. French specifically calls this out as something to alert on: every API token creation should have a documented, approved justification.

Privilege escalation is equally important to watch. Look for user.account.privilege.grant and group membership changes (group.user_membership.add) that add users to admin-equivalent groups.

OAuth and application connections

Okta mediates OAuth connections between your users and third-party applications. Application assignments and integrations are a frequently overlooked attack surface. A malicious OAuth app granted access by a compromised admin can exfiltrate data indefinitely. Watch application.lifecycle.create, application.user_membership.add, and OAuth-related grant events.

Session hijacking signals

One of the more sophisticated techniques French covers is session cookie hijacking — attackers use tools like Evilginx2 to steal authenticated session cookies and replay them to bypass MFA entirely. The key hunting signal is looking for anomalies within a single session: specifically, multiple different ASN values or user agent strings associated with the same authenticationContext.externalSessionId. The value securityContext.asNumber is your friend here. Normal browser sessions don't bounce between ASNs. Hijacked sessions often do, because the attacker is replaying the cookie from a different network.

---

How and what to look for

Okta's native System Log interface at https://yourorg.okta.com/admin/reports/system-log is functional but designed for linear investigation. You can search with Okta's expression language, save reports, and export to a SIEM. If you're running a well-resourced SOC, you probably already have this feeding into Splunk, Elastic, or a similar platform.

USE TURNGATE

If you don't have a SIEM, or your SIEM queries feel like archaeology, Turngate gives you a much faster path to answers. Here's a hunt for all admin privilege change events in the last 30 days, pivoted to a single suspicious user, completed in under a minute:

We have a 45-day free trial. Give it a shot.

Seriously. The challenge with Okta hunting isn't finding the events — it's making sense of the volume and pivoting quickly from a suspicious signal to the full story of what happened. Turngate's heatmap lets you see anomalies at a glance across all users and event types. When something looks off, you can drill down to the individual actor, see all their surrounding activity, and validate or escalate — without writing a query.

Okta has its own documentation on System Log events including detailed field descriptions. Turngate surfaces human-readable summaries of these events so you don't need to memorize what policy.rule.update vs policy.evaluate_sign_on actually means in practice.

---

Audit events of interest

Here's a practical reference list for building your hunts and detections. Organized by threat category.

Credential attacks and initial access

Brute Force & Credential Stuffing:

• user.session.start — baseline for all login activity; hunt for high failure rates by source IP

• user.authentication.auth_via_mfa — MFA challenge events; look for volumetric failures (MFA fatigue)

• security.threat.detected — Okta ThreatInsight has flagged this as a high-confidence threat (see French's tip on ThreatInsight); alert on every occurrence

• user.account.report_suspicious_activity_by_enduser — the user themselves is telling you something is wrong; never ignore these

VPN & Anonymization Services:

• user.session.start from Tor exit nodes, ProtonVPN, NordVPN, or known datacenter IP ranges — French specifically recommends ingesting IP lists for these services into your SIEM and alerting on login events from them

• user.authentication.sso with unusual securityContext.asOrg values (datacenter ASNs rather than ISP/consumer ASNs)

MFA attacks and bypass

MFA Degradation:

• user.mfa.factor.deactivate — MFA factor disabled on an account (🚨 for admin accounts)

• user.mfa.factor.suspend — MFA factor suspended

• user.mfa.factor.reset_all — all MFA factors reset on an account

• user.mfa.attempt_bypass — explicit bypass attempt; alert on every occurrence (French calls this out specifically)

MFA Fatigue / Push Bombing:

• Spike of user.authentication.auth_via_mfa failures followed by a successful user.session.start — look for the pattern of repeated push failures resolving to a successful login, which may indicate a fatigued user finally approving a fraudulent push

Session hijacking and token theft

Session Anomalies:

• Multiple securityContext.asNumber values within a single authenticationContext.externalSessionId — core signal for session cookie hijacking as described by French

• Multiple client.userAgent values within the same session

• user.session.impersonation.initiate / user.session.impersonation.grant — admin is impersonating a user; verify this is authorized

API Token Abuse:

• system.api_token.create — new API token created; every token needs a documented purpose (French recommends alerting on all of these)

• system.api_token.revoke — token revoked (possible cleanup after use)

Privilege escalation and persistence

Admin Account Changes:

• user.account.privilege.grant — privilege granted to a user account

• group.user_membership.add — user added to a group; especially dangerous for groups tied to admin apps

• group.user_membership.remove — user removed from a group (covering tracks or removing competitors)

Policy Weakening:

• policy.rule.update — a policy rule has been modified; verify with the admin team

• policy.rule.deactivate — a policy rule has been deactivated

• policy.lifecycle.update — sign-on or MFA policy updated

• policy.evaluate_sign_on with DENY outcomes suddenly disappearing (attacker may have relaxed a policy)

Application & Integration Changes:

• application.lifecycle.create — new application added to Okta; review OAuth scopes and who approved it

• application.lifecycle.activate — previously inactive application enabled

• application.user_membership.add — user assigned to an application (especially sensitive apps)

• application.lifecycle.update — application configuration changed

Defense evasion

Log and Audit Tampering:

• system.log_streaming.create / system.log_streaming.update — changes to audit log streaming; verify these are authorized

• Any admin activity occurring in a tight window around user.mfa.factor.deactivate (attacker may be working quickly to establish persistence before defenders notice)

Rate Limit Abuse:

• system.org.rate_limit.warning — approaching a rate limit; could indicate automated attack activity

• system.org.rate_limit.violation — rate limit exceeded; investigate the source immediately

---

Suspicious patterns to detect

Velocity-based anomalies

• MFA fatigue chain: spike of user.authentication.auth_via_mfa failures → short pause → successful user.session.start (classic push bombing pattern)

• Impossible travel: user.session.start from geographically distant locations within an impossible timeframe

• Credential stuffing: high volume of failed user.session.start events from a single IP or narrow IP range against multiple accounts

• Bulk admin changes: multiple user.account.privilege.grant or group.user_membership.add events in rapid succession

Correlation chains

• user.mfa.factor.deactivate → user.session.start from new location → system.api_token.create (account takeover + persistence)

• policy.rule.deactivate → user.session.start from VPN/Tor IP → application.user_membership.add (policy weakening before lateral movement)

• user.account.privilege.grant → system.api_token.create → group.user_membership.add on other accounts (privilege escalation + persistence chain)

• Multiple ASN values within same session externalSessionId → system.api_token.create (session hijack into token persistence)

• user.account.report_suspicious_activity_by_enduser → no user.mfa.factor.reset_all in response window (victim reported it but remediation hasn't happened)

Cross-source correlation

French's most underrated tip: correlate Okta events with other data sources. If Okta rates a login as MEDIUM or HIGH risk and Google Workspace (or whatever downstream app is involved) is simultaneously logging anomalous activity for the same user, that's a much higher-confidence signal than either source alone. The sum is greater than its parts. Build cross-source correlation rules for your highest-risk users (executives, admins, finance) first.

---

This guide draws heavily on research by David French (@threatpunter). His original post is required reading for anyone building Okta detections. We've extended his hunting tips with additional context, event references, and guidance on using Turngate to operationalize them.