Detection rules › Panther

Okta Support Access

This is a threat-hunting query, not an automated detection. It surfaces activity for an analyst to review rather than firing on a match. It is searchable for reference but is excluded from the detection-rule browse and the ATT&CK coverage matrix.

Source
github.com/panther-labs/panther-analysis

Show instances that Okta support was granted to your account

Rules detecting the same action

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

Rule body yaml

AnalysisType: scheduled_query
QueryName: "Okta Support Access"
Enabled: false
Description: >
  Show instances that Okta support was granted to your account
Query: |
  SELECT
  p_event_time as event_time,
  actor:alternateId as actor_email,
  actor:displayName as actor_name,
  client:ipAddress as src_ip,
  client:geographicalContext:city as city,
  client:geographicalContext:country as country,
  client:userAgent:rawUserAgent as user_agent,
  displayMessage,
  eventType
  FROM
  panther_logs.public.okta_systemlog
  WHERE
    eventType = 'user.session.impersonation.grant'
    OR
    eventType = 'user.session.impersonation.initiate'
   AND
      p_occurs_between('2022-01-14','2022-03-22')
  ORDER BY
    event_time desc
Schedule:
  RateMinutes: 43200
  TimeoutMinutes: 1

Detection logic

Stage 1: source

panther_logs.public.okta_systemlog

Stage 2: filter

eventType eq "user.session.impersonation.grant" or eventType eq "user.session.impersonation.initiate"

This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.

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
eventTypeeq
  • user.session.impersonation.grant
  • user.session.impersonation.initiate

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.

FieldSource
event_timep_event_time
actor_emailactor:alternateId
actor_nameactor:displayName
src_ipclient:ipAddress
cityclient:geographicalContext:city
countryclient:geographicalContext:country
user_agentclient:userAgent:rawUserAgent
displayMessage
eventType