Detecting Okta Attacks: Admin Grants, Factor Resets and Impersonation

Attackers who target Okta tenants often start with the service desk, convincing staff to reset a privileged user’s authenticators, then use that session to assign administrator roles, change authentication policies and create persistence through API tokens or added identity providers. The Okta System Log records each step with stable event types, so a small query set covers the chain.

Signals at a Glance

Admin Grants and Factor Resets

Start with the events that change who can do what. These queries use standard Okta event types; confirm them against your own System Log before relying on them:

# Splunk SPL - Okta privilege grants and authenticator resets in the last day
index=okta sourcetype="OktaIM2:log" earliest=-1d
  (eventType="user.account.privilege.grant"
   OR eventType="group.privilege.grant"
   OR eventType="user.mfa.factor.reset_all"
   OR eventType="user.mfa.factor.deactivate"
   OR eventType="user.mfa.factor.update"
   OR eventType="system.api_token.create"
   OR eventType="user.session.impersonation.initiate")
| eval target=mvindex('target{}.alternateId', 0)
| table _time eventType actor.alternateId target client.ipAddress client.geographicalContext.country outcome.result
| sort - _time
# tune/validate: legitimate onboarding resets are common; join to a helpdesk ticket feed to separate them

• Alert on a factor reset or deactivation for any user holding an administrator role, regardless of who performed it.
• Flag a privilege grant made within minutes of the actor’s own authenticator being reset, which is the social-engineering chain.
• Require identity verification steps and out-of-band approval at the service desk for resets of privileged accounts.

Reset-to-Compromise Correlation

The most valuable detection joins the reset to what follows. A reset, then a successful sign-in from a network the user has never used, then an admin action within the hour, is the typical pattern:

# Splunk SPL - factor reset followed by a sign-in from a new country within two hours
index=okta sourcetype="OktaIM2:log" earliest=-1d
  (eventType="user.mfa.factor.reset_all" OR eventType="user.session.start")
| eval user=if(eventType="user.mfa.factor.reset_all", mvindex('target{}.alternateId',0), 'actor.alternateId')
| eval country='client.geographicalContext.country'
| sort 0 user _time
| streamstats current=f last(eventType) AS prev_event last(_time) AS prev_time by user
| where eventType="user.session.start" AND prev_event="user.mfa.factor.reset_all"
        AND (_time - prev_time) < 7200 AND 'outcome.result'="SUCCESS"
| table _time user country client.ipAddress client.userAgent.rawUserAgent

• Alert on API token creation outside your automation accounts, since a token survives password and MFA resets.
• Review sign-on policy and authentication policy rule updates against change records; weakened rules are a persistence step.
• Hunt for session starts from consumer VPN or residential proxy ranges for administrator accounts.