Detection rules › Panther
Okta Investigate MFA and Password resets
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.
Investigate Password and MFA resets for the last 7 days
Rules detecting the same action
Other rules on this platform that filter on the same API call or operation.
- Attempt to Reset MFA Factors for an Okta User Account (Elastic)
- High-Risk Admin Activity (Kusto)
- MFA Deactivation with no Re-Activation for Okta User Account (Elastic)
- New Device/Location sign-in along with critical operation (Kusto)
- Okta MFA Reset or Deactivated (Sigma)
- Okta Support Reset Credential (Panther)
- Okta User Password and MFA Factor Reset or Deactivated (YARA-L)
- Stolen Credentials Used to Login to Okta Account After MFA Reset (Elastic)
Rule body yaml
AnalysisType: scheduled_query
QueryName: "Okta Investigate MFA and Password resets"
Enabled: false
Description: >
Investigate Password and MFA resets for the last 7 days
Query: |
SELECT p_event_time,actor:alternateId as actor_user,target[0]:alternateId as target_user, eventType,client:ipAddress as ip_address
FROM panther_logs.public.okta_systemlog
WHERE eventType IN ('user.mfa.factor.reset_all', 'user.mfa.factor.deactivate', 'user.mfa.factor.suspend', 'user.account.reset_password', 'user.account.update_password','user.mfa.factor.update')
and p_occurs_since('7 days')
-- If you wish to investigate an individual user , uncomment this line and add their email here
-- and actor:alternateId = '<EMAIL_GOES_HERE>'
ORDER by p_event_time DESC
Schedule:
RateMinutes: 43200
TimeoutMinutes: 1
Detection logic
Stage 1: source
panther_logs.public.okta_systemlog
Stage 2: filter
eventType in ["user.mfa.factor.reset_all", "user.mfa.factor.deactivate", "user.mfa.factor.suspend", "user.account.reset_password", "user.account.update_password", "user.mfa.factor.update"]
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 | in |
|
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 |
|---|---|
p_event_time | |
actor_user | actor:alternateId |
target_user | target [ 0 ] : alternateId |
eventType | |
ip_address | client:ipAddress |