Okta Multiple Failed MFA Requests For User

Status: production
Severity: low
Group by: _time, user
Author: Mauricio Velazco, Splunk
Source: github.com/splunk/security_content

The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems.

MITRE ATT&CK coverage

Tactic	Techniques
Credential Access	`T1621` Multi-Factor Authentication Request Generation

Rules detecting the same action

Other rules on this platform that filter on the same API call or operation.

First Occurrence of Okta User Session Started via Proxy (Elastic)
MFA Fatigue (OKTA) (Kusto)
Okta AiTM Phishing Attempt Blocked by FastPass (Panther)
Okta Fast Pass phishing Detection (Kusto)
Okta FastPass Phishing Detection (Sigma)
Okta FastPass Phishing Detection (Elastic)
Okta MFA Bruteforce Attack (YARA-L)
Okta Mismatch Between Source And Response For Verify Push Request (YARA-L)

Rule body splunk

name: Okta Multiple Failed MFA Requests For User
id: 826dbaae-a1e6-4c8c-b384-d16898956e73
version: 12
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: Anomaly
description: The following analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems.
data_source:
    - Okta
search: |-
    `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR
      | bucket _time span=5m
      | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) values(dest) as dest
        BY _time src_user
      | where count >= 10
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `okta_multiple_failed_mfa_requests_for_user_filter`
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity.
references:
    - https://attack.mitre.org/techniques/T1621/
drilldown_searches:
    - name: View the detection results for - "$src_user$"
      search: '%original_detection_search% | search  src_user = "$src_user$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$src_user$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$src_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: src_user
          type: user
          score: 20
          message: Multiple failed MFA requests for user $src_user$ from IP Address - $src_ip$
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Okta Account Takeover
    - Scattered Lapsus$ Hunters
asset_type: Okta Tenant
mitre_attack_id:
    - 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/T1621/okta_multiple_failed_mfa_requests/okta_multiple_failed_mfa_requests.log
          source: Okta
          sourcetype: OktaIM2:log
      test_type: unit

Stages and Predicates

Stage 1: `search`

`okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR

Stage 2: `bucket`

| bucket _time span=5m

Stage 3: `stats`

| stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) values(dest) as dest
    BY _time src_user

Stage 4: `where`

| where count >= 10

Stage 5: `search`

| `security_content_ctime(firstTime)`

Stage 6: `search`

| `security_content_ctime(lastTime)`

Stage 7: `search`

| `okta_multiple_failed_mfa_requests_for_user_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

Field	Kind	Values
`count`	ge	`10`
`debugContext.debugData.factor`	ne	`PASSWORD_AS_FACTOR`
`eventType`	eq	`user.authentication.auth_via_mfa`
`outcome.result`	eq	`FAILURE`
`sourcetype`	eq	`OktaIM2:log`

`j` / `k`	Scroll down / up
`d` / `u`	Half-page down / up
`gg` / `G`	Top / bottom
`h` / `l`	History back / forward
`f`	Follow link (`Shift` = new tab)
`/`	Focus search
`?`	Toggle this help
`↑` / `↓`	Navigate search results
`Enter`	Open highlighted result
`Esc`	Close results / dialog

`type:`	`events` / `rules` / `providers`
`vendor:`	`sigma` / `elastic` / `splunk` / `kusto` / `chronicle` (vendor name alone also works: `sigma:`, `kql:`, `secops:`…)
`tactic:`	TA-id, slug, or name: `credential_access`, `TA0006`
`technique:`	technique or sub-technique ID: `T1003`, `T1003.001` (alias `tech:`)
`severity:`	`critical` / `high` / `medium` / `low` / `informational` (alias `sev:`)
`risk_score`	Numeric comparison on the Elastic risk score (0 to 100): `risk_score>50`, `risk_score<=20`, `risk_score=99` (alias `risk`; Elastic rules only)
`stages:`	Rules with exactly N pipeline stages
`correlation:`	`single_event` / `sequence` / `alternatives` / `alternatives_cross_log` / `all_required` / `correlated`
`with:`	Co-occurrence event-id; stacks (`with:4624 with:4769`) to require all, while a comma list in one occurrence (`with:4624,4769`) is an either-or group. Implies multi-event
`like:`	Structural neighbors of a rule slug (equivalents + subsumption stricter / broader): `like:comsvcs_lsass_memory_dump-splunk-sysmon`
`groupby:`	Entity-grouping substring match against `group_by_keys`: `groupby:user`, `groupby:host`
`uses:`	Rules whose predicate tree touches the field (any kind, any value): `uses:CommandLine`
`excludes:`	Rules with top-level `not()` clauses on the field (FP whitelists): `excludes:ParentImage`
`field:` / `value:`	Predicate search; narrows rule cards to those with a matching leaf and drives the indicator tier. Unquoted = substring, wildcards allowed (`value:mimikatz`)
`indicator:`	Shorthand for `field:F value:V`: `indicator:Image=*\powershell.exe`
`kind:`	Filter by predicate kind. Narrows rule cards to those carrying a matching predicate leaf (`vendor:elastic kind:cidr_match`) and drives the indicator tier: `contains` / `starts_with` / `ends_with` / `regex` / `cidr` / `eq` / `in` … (operator aliases `op:`/`match:`)
`has:` / `no:`	`sample`, `field`, `notes`, `refs`, `trace`, `thirdparty`, `rule`, `pattern`, `timewindow`, `threshold`, `newterms`, `sigma`/`elastic`/`splunk`/`kusto`/`chronicle`
`-op:val`	Exclude matches; works on most operators but not `type:`/`like:`/`has:`/`no:` (use `no:<flag>` to exclude a rule flag): `tactic:execution -vendor:splunk`. Standalone `-kind:`/`-field:`/`-value:` drop every rule carrying a matching predicate leaf (`type:rules -kind:is_null`)
`field:"…"` / `value:"…"`	Quoted value = anchored exact match (also allows spaces): `value:"net user"`
`a,b`	Comma = OR inside one operator (`vendor:sigma,elastic`, `severity:high,critical`); repeating a facet merges the same way. `field:`/`value:` never split (literal commas)
`vendors:` / `stage:`	Singular and plural spellings fold to the canonical operator and value: `tactics:` = `tactic:`, `type:event` = `type:events`, `correlation:sequences` = `correlation:sequence`, `has:thresholds` = `has:threshold`
`"quoted phrase"`	Exact-match a multi-word phrase (free text)

Okta Multiple Failed MFA Requests For User

MITRE ATT&CK coverage

Rules detecting the same action

Rule body splunk

Stages and Predicates

Stage 1: `search`

Stage 2: `bucket`

Stage 3: `stats`

Stage 4: `where`

Stage 5: `search`

Stage 6: `search`

Stage 7: `search`

Indicators

Keyboard shortcuts

Search operators

Okta Multiple Failed MFA Requests For User

MITRE ATT&CK coverage

Rules detecting the same action

Rule body splunk

Stages and Predicates

Stage 1: search

Stage 2: bucket

Stage 3: stats

Stage 4: where

Stage 5: search

Stage 6: search

Stage 7: search

Indicators

Stage 1: `search`

Stage 2: `bucket`

Stage 3: `stats`

Stage 4: `where`

Stage 5: `search`

Stage 6: `search`

Stage 7: `search`