detection.wiki

Detection rules › Panther

Okta Login From CrowdStrike Unmanaged Device (crowdstrike_fdrevent table)

Tags
Multi-Table Query
Source
github.com/panther-labs/panther-analysis

Okta Logins from an IP Address not found in CrowdStrike's AIP List (crowdstrike_fdrevent table)

Rule body yaml

# This file is the part of the Crowdstrike FDREvent migration, and it's the equivalent of
# https://github.com/panther-labs/panther-analysis/blob/b61db1ecf3967c5f6a44c1782f8891fd5f54384d/queries/okta_queries/Okta_Login_From_CrowdStrike_Unmanaged_Device.yml
#
AnalysisType: scheduled_query
Description: Okta Logins from an IP Address not found in CrowdStrike's AIP List (crowdstrike_fdrevent table)
Enabled: false
Query: |
  SELECT *
  FROM panther_logs.public.okta_systemlog
  WHERE p_occurs_since('1 days')
    AND eventtype = 'user.session.start'
    AND outcome:result = 'SUCCESS'
    AND client:device = 'Computer'
    AND client:ipAddress LIKE '%.%.%.%'
    AND client:ipAddress NOT IN
      (
        SELECT DISTINCT aip
        FROM panther_logs.public.crowdstrike_fdrevent
        WHERE p_occurs_since('3 days') AND panther_logs.public.crowdstrike_fdrevent.fdr_event_type = 'aid_master'
      )
QueryName: "Okta Login From CrowdStrike Unmanaged Device (crowdstrike_fdrevent table)"
Schedule:
  RateMinutes: 1440
  TimeoutMinutes: 1
Tags:
  - Multi-Table Query

Detection logic

Stage 1: source

panther_logs.public.okta_systemlog

Stage 2: filter

eventtype eq "user.session.start"
outcome:result eq "SUCCESS"
client:device eq "Computer"
client:ipAddress wildcard "*.*.*.*"
client:ipAddress not in (subquery on panther_logs.public.crowdstrike_fdrevent)

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.

FieldKindValues
client:deviceeq
  • Computer
client:ipAddresswildcard
  • *.*.*.*
outcome:resulteq
  • SUCCESS

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

Field
*