security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Tuning] SDH - Investigating MFA Deactivation with no Re-Activation for Okta User Account (#4986)

Browse Source 
* [Tuning] SDH - Investigating MFA Deactivation with no Re-Activation for Okta User Account

This tuning addresses SDH ticket by:
- replacing sequence by `okta.actor.id` with `okta.target.id` in query. This will ensure the deactivation and activation attempts are measured against the target entity. To account for instances where separate users (okta.actor.id) perform deactivation and activation actions against the same target account (okta.target.id)
- Adjusts the investigation guide to use correct target vs. actor fields

* add actor and target id fields to investigation guide

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>

---------

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
This commit is contained in:
Isai
2025-08-15 18:02:15 -04:00
committed by GitHub
parent c8ee4c8ce3
commit b7de4f5126
1 changed files with 7 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
+7 -6
View File
@@ -2,7 +2,7 @@
creation_date = "2020/05/20"
integration = ["okta"]
maturity = "production"
updated_date = "2025/07/02"
updated_date = "2025/08/15"
[rule]
author = ["Elastic"]
@@ -33,11 +33,12 @@ This rule fires when an Okta user account has MFA deactivated and no subsequent
#### Possible investigation steps:
- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted.
- Review `okta.target` or `user.target.full_name` fields to determine if deactivation was performed by a se parate user.
- Using the `okta.actor.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`.
- Review events where `okta.event_type` is `user.authenticate*` to determine if the user account had suspicious login activity.
- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity.
- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target.
- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user.
- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.
- Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.
- Examine related administrative activity by the actor for privilege misuse or suspicious changes.
#### False positive steps:
@@ -75,7 +76,7 @@ tags = [
type = "eql"
query = '''
sequence by okta.actor.id with maxspan=12h
sequence by okta.target.id with maxspan=12h
[any where event.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all")
and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"]
![any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"]