Okta Successful Single Factor Authentication


Description

The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment.

Query · spl

`okta`  action=success src_user_type = User eventType = user.authentication.verify OR eventType = user.authentication.auth_via_mfa
  | stats dc(eventType) values(eventType) as eventType values(target{}.displayName) as targets values(debugContext.debugData.url) min(_time) as firstTime max(_time) as lastTime values(authentication_method)
    BY src_ip user action
       dest
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`
  | search targets !="Okta Verify"
  | `okta_successful_single_factor_authentication_filter`

Implementation guide

This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).

Known false positives

  • Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary.

Analyst notes

Known false positives: Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary.

Raw source Okta Successful Single Factor Authentication · SPL
Esc
Published by splunk/security_content ↗, licensed under Apache 2.0 ↗. Reproduced here unmodified.
name: Okta Successful Single Factor Authentication
id: 98f6ad4f-4325-4096-9d69-45dc8e638e82
version: 11
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment.
data_source:
    - Okta
search: |-
    `okta`  action=success src_user_type = User eventType = user.authentication.verify OR eventType = user.authentication.auth_via_mfa
      | stats dc(eventType) values(eventType) as eventType values(target{}.displayName) as targets values(debugContext.debugData.url) min(_time) as firstTime max(_time) as lastTime values(authentication_method)
        BY src_ip user action
           dest
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | search targets !="Okta Verify"
      | `okta_successful_single_factor_authentication_filter`
how_to_implement: This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary.
references:
    - https://sec.okta.com/everythingisyes
    - https://attack.mitre.org/techniques/T1078/004/
drilldown_searches:
    - name: View the detection results for - "$user$"
      search: '%original_detection_search% | search  user = "$user$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$user$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$user$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: A user [$user$] has successfully logged in to Okta Dashboard with single factor authentication from IP Address - [$src_ip$].
analytic_story:
    - Okta Account Takeover
asset_type: Okta Tenant
mitre_attack_id:
    - T1078.004
    - T1586.003
    - T1621
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_single_factor_auth/okta_single_factor_auth.log
          source: okta_log
          sourcetype: OktaIM2:log
      test_type: unit

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.