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

* [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 <[email protected]>

---------

Co-authored-by: Terrance DeJesus <[email protected]>

Author: imays11

rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml

@@ -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"]