Okta Login Without Push

Severity: critical
Time window: 1h
Tags: Okta, Push Security, Identity Verification, Configuration Required, Credential Access
Reference: https://www.okta.com/resources/datasheet/okta-adaptive-multi-factor-authentication-product-datasheet/
Source: github.com/panther-labs/panther-analysis

Identifies successful Okta logins not followed by Push Security authorization within 60 minutes. Push Security provides additional identity verification beyond Okta MFA as a defense-in-depth strategy. Missing Push Security verification suggests compromised credentials, session hijacking, or MFA bypass where attackers satisfied Okta authentication but cannot complete additional verification.

MITRE ATT&CK coverage

Tactic	Techniques
Initial Access	`T1078` Valid Accounts
Credential Access	`T1539` Steal Web Session Cookie, `T1621` Multi-Factor Authentication Request Generation

Rule body yaml

AnalysisType: correlation_rule
RuleID: "Okta.Login.Without.Push"
DisplayName: "Okta Login Without Push"
Enabled: false
Tags:
  - Okta
  - Push Security
  - Identity Verification
  - Configuration Required
  - Credential Access
Reports:
  MITRE ATT&CK:
    - TA0001:T1078 # Initial Access: Valid Accounts
    - TA0006:T1539 # Credential Access: Steal Web Session Cookie
    - TA0006:T1621 # Credential Access: Multi-Factor Authentication Request Generation
Severity: Critical
Description: >
  Identifies successful Okta logins not followed by Push Security authorization within 60 minutes. Push Security provides additional identity verification beyond Okta MFA as a defense-in-depth strategy. Missing Push Security verification suggests compromised credentials, session hijacking, or MFA bypass where attackers satisfied Okta authentication but cannot complete additional verification.
Runbook: |
  1. Query Okta System Log for all authentication events by actor.alternateId in the 90 minutes around the login to check if Push Security authentication occurred outside the 60-minute detection window, and review the source IP, geolocation, device, and MFA method used
  2. Query Push Security logs for any authentication attempts or failures by the same user in the 2 hours around the Okta login to determine if the user attempted but failed to complete Push Security verification
  3. Check Okta audit logs for all application access, permission changes, and administrative actions during the Okta session to identify suspicious activity that may indicate compromised credentials or session hijacking
Reference: https://www.okta.com/resources/datasheet/okta-adaptive-multi-factor-authentication-product-datasheet/
Detection:
  - Sequence:
      - ID: Okta
        RuleID: Okta.Login.Success
      - ID: Push
        RuleID: Push.Security.Authorized.IdP.Login
        Absence: true
    Transitions:
      - ID: Okta to Push
        From: Okta
        To: Push
        WithinTimeFrameMinutes: 60
        Match:
          - From: actor.alternateId
            To: new.email
    Schedule:
      RateMinutes: 1440
      TimeoutMinutes: 10
    LookbackWindowMinutes: 2160
Tests:
  - Name: Okta Login, Followed By Push Authorized Login
    ExpectedResult: false
    RuleOutputs:
      - ID: Okta
        Matches:
          actor.alternateId:
            frodo.baggins@hobbiton.com:
              - 0
      - ID: Push
        Matches:
          new.email:
            frodo.baggins@hobbiton.com:
              - 3
  - Name: Okta Login, Not Followed By Push Authorized Login
    ExpectedResult: true
    RuleOutputs:
      - ID: Okta
        Matches:
          actor.alternateId:
            frodo.baggins@hobbiton.com:
              - 0
  - Name: Okta Login, Followed By Push Authorized Login By Other User
    ExpectedResult: true
    RuleOutputs:
      - ID: Okta
        Matches:
          actor.alternateId:
            frodo.baggins@hobbiton.com:
              - 0
      - ID: Push
        Matches:
          new.email:
            samwise.gamgee@hobbiton.com:
              - 3

Detection logic

Stage 1: `step Okta` ordered before `$Push`

References detection Okta.Login.Success.

Stage 2: `step Push` (negated) ordered after `$Okta`

References detection Push.Security.Authorized.IdP.Login.

`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 Login Without Push

MITRE ATT&CK coverage

Rule body yaml

Detection logic

Stage 1: `step Okta` ordered before `$Push`

Stage 2: `step Push` (negated) ordered after `$Okta`

Keyboard shortcuts

Search operators

Okta Login Without Push

MITRE ATT&CK coverage

Rule body yaml

Detection logic

Stage 1: step Okta ordered before $Push

Stage 2: step Push (negated) ordered after $Okta

Stage 1: `step Okta` ordered before `$Push`

Stage 2: `step Push` (negated) ordered after `$Okta`