<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Common Okta System Log Queries for Attempted Account Takeover and Administrator Activity
Administration
Okta Identity Engine
Overview

The Okta System Log provides a detailed view of logged events that administrators can browse, search, or filter in the Admin Console. Administrators can also query and filter events programmatically via the System Log API and export or stream them to third-party security monitoring tools. Okta retains events for 90 days, making third-party monitoring tools useful when a longer retention duration is necessary.

Applies To
  • Okta Identity Engine (OIE)
  • Okta Classic Engine
  • System Log
Solution

What are the common System Log queries for attempted account takeover for user activity?

 

Okta maintains a comprehensive list of event types for use in detection or audit purposes.

Review the following table to identify common System Log events that security professionals use to detect attempted account takeovers.

 

EventEventTypeFurther context
Suspicious Activity reported by user.eventType eq "user.account.report_suspicious_activity_by_enduser"A user reports suspicious activity in response to an end user security notification.
ThreatInsight detection: access requests from IPs associated with malicious behavior.eventType eq "security.threat.detected"More info in the System Log events for Okta ThreatInsight documentation.
ThreatInsight detection: access requests from known malicious IPs targeting a specific org.eventType eq "security.attack.start"More info in the System Log events for Okta ThreatInsight documentation.
User rejected an MFA push request.eventType eq "user.mfa.okta_verify.deny_push"This event is logged when a user is prompted to accept a Push request but selects “No, it’s not me”.
User authentication via MFA.eventType eq "user.authentication.auth_via_mfa" AND outcome.result eq "FAILURE"Relevant in the context of repeated failures. In Okta Identity Engine, a password is considered a “factor”, so failed events will include incorrect passwords.
User Behavior Detections (Adaptive MFA).*eventType eq "user.session.start" AND debugContext.debugData.behaviors co "POSITIVE" OR eventType eq "policy.evaluate.sign_on" AND debugContext.debugData.behaviors co "POSITIVE"While typically used in policy enforcement, indications of a new device, network location, or impossible travel can also provide context during investigations. More info in the Behavior Detection System Log events documentation.
Risk Scoring Events (Adaptive MFA).**eventType eq "user.session.start" AND debugContext.debugData.risk co "HIGH" OR eventType eq "policy.evaluate_sign_on" AND debugContext.debugData.logOnlySecurityData co "HIGH"While typically used in policy enforcement, security admins can also filter on events with a High Risk score. More info in the Risk scoring documentation.
Self-service Password Reset attempted for a suspended user.eventType eq "user.account.reset_password" AND outcome.result eq "FAILURE" AND outcome.reason eq "User suspended"Only relevant in the context of known malicious activity.
User fails challenge during Self-Service Password Reset.

eventType eq "user.account.reset_password" AND outcome.result eq "FAILURE" and outcome.reason eq "User answered recovery question invalid"

Only relevant in the context of known malicious activity.
User account lockout.eventType eq "user.account.lock.limit"Only relevant in the context of known malicious activity.
User password reset (by an unauthenticated user).eventType eq "user.account.reset_password"Only relevant in the context of known malicious activity.
Single Sign-On to the application.eventType eq "user.authentication.sso"Useful for auditing what apps an actor gained access to. The target.alternateId field contains the name of the target app.

* This requires admins of orgs with Adaptive MFA to have first configured Behavior Detections.

** This requires admins of organizations with Adaptive MFA to have first-set risk scoring as a condition in an application or Okta sign-on policy rule.

 

 

What are the common System Log queries for administrator activity?

Review the following table to identify common System Log events initiated by an administrator or customer support personnel that are useful for audit purposes.

EventEventType
User grants support access for impersonation.eventType eq "user.session.impersonation.grant"
Impersonation (support) session initiated.eventType eq "user.session.impersonation.initiate"
User password reset sent to the user's email account from SuperUser.eventType eq "user.account.reset_password" AND actor.alternateId eq "system@okta.com" and transaction.id eq "unknown"
Temporary password sent to user email account from SuperUser.eventType eq "user.account.update_password" AND actor.alternateId eq "system@okta.com"
New (access) API created by admin.eventType eq "system.api_token.create"
Assignment of admin privileges to a new user or group.eventType eq "user.account.privilege.grant" OR eventType eq "group.privilege.grant"
New Custom Admin role created.eventType eq "iam.role.create"
Permissions added to a Custom Admin role.eventType eq "iam.role.permissions.add"
Access to the Okta Admin Console.eventType eq "user.session.access_admin_app"
Reset all factors for a user.eventType eq "user.mfa.factor.reset_all"
Factor activated or deactivated.eventType eq "user.mfa.factor.deactivate" OR eventType eq "user.mfa.factor.activate"
A user’s factor is suspended (or unsuspended).eventType eq "user.mfa.factor.suspend" OR eventType eq "user.mfa.factor.unsuspend"
 
 
 

Related References

Loading
Common Okta System Log Queries for Attempted Account Takeover and Administrator Activity