Splunk

Okta Mismatch Between Source and Response for Verify Push Request

Last updated 2 days ago on 2026-07-17

About

The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems.

Platform: Splunk
Tags: Data Source: SplunkDomain: ApplicationRule Type: QueryOS: Any
Severity: medium
Risk Score: 47
References: https://attack.mitre.org/techniques/T1621(external, opens in a new tab or window)https://splunkbase.splunk.com/app/6553(external, opens in a new tab or window)
False Positives: False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed.
Source: View on GitHub(external, opens in a new tab or window)

Definition

Rule Language: SPL
Rule Type: query

✄𐘗text code block:
✄𐘗`okta` eventType IN (system.push.send_factor_verify_push) OR (eventType IN (user.authentication.auth_via_mfa) debugContext.debugData.factor="OKTA_VERIFY_PUSH")
  | eval groupby="authenticationContext.externalSessionId"
  | eval group_push_time=_time
  | bin span=2s group_push_time
  | fillnull value=NULL
  | stats min(_time) as _time
    BY authenticationContext.externalSessionId eventType debugContext.debugData.factor
       outcome.result actor.alternateId client.device
       client.ipAddress client.userAgent.rawUserAgent debugContext.debugData.behaviors
       group_push_time
  | iplocation client.ipAddress
  | fields - lat, lon, group_push_time
  | stats min(_time) as _time dc(client.ipAddress) as dc_ip sum(eval(if(eventType="system.push.send_factor_verify_push" AND $outcome.result$="SUCCESS", 1, 0))) as total_pushes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND $outcome.result$="SUCCESS", 1, 0))) as total_successes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND $outcome.result$="FAILURE", 1, 0))) as total_rejected sum(eval(if(eventType="system.push.send_factor_verify_push" AND $debugContext.debugData.behaviors$ LIKE "%New Device=POSITIVE%", 1, 0))) as suspect_device_from_source sum(eval(if(eventType="system.push.send_factor_verify_push" AND $debugContext.debugData.behaviors$ LIKE "%New IP=POSITIVE%", 1, 0))) as suspect_ip_from_source values(eval(if(eventType="system.push.send_factor_verify_push", $client.ipAddress$, ""))) as src values(eval(if(eventType="user.authentication.auth_via_mfa", $client.ipAddress$, ""))) as dest values(*) as *
    BY authenticationContext.externalSessionId
  | eval ratio = round(total_successes / total_pushes, 2)
  | search ((ratio < 0.5 AND total_pushes > 1) OR (total_rejected > 0)) AND dc_ip > 1 AND suspect_device_from_source > 0 AND suspect_ip_from_source > 0
  | rename actor.alternateId as user
  | `okta_mismatch_between_source_and_response_for_verify_push_request_filter`

View this rule on Splunk

This rule was sourced from the official Splunk public repository. View the original rule on GitHub(external, opens in a new tab or window).