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.
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.
- High-Risk Admin Activity (Kusto)
- Okta Support Access Granted (Panther)
- Okta User Session Impersonation (Elastic)
- User Session Impersonation(Okta) (Kusto)
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.
| Field | Kind | Values |
|---|---|---|
eventType | eq |
|
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 | Source |
|---|---|
event_time | p_event_time |
actor_email | actor:alternateId |
actor_name | actor:displayName |
src_ip | client:ipAddress |
city | client:geographicalContext:city |
country | client:geographicalContext:country |
user_agent | client:userAgent:rawUserAgent |
displayMessage | |
eventType |