MFA Deactivation with no Re-Activation for Okta User Account

Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/05/20"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2025/08/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An
 11adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the
 12account.
 13"""
 14false_positives = [
 15    """
 16    If the behavior of deactivating MFA for Okta user accounts is expected, consider adding exceptions to this rule to
 17    filter false positives.
 18    """,
 19]
 20from = "now-12h"
 21index = ["filebeat-*", "logs-okta.system*"]
 22interval = "6h"
 23language = "eql"
 24license = "Elastic License v2"
 25name = "MFA Deactivation with no Re-Activation for Okta User Account"
 26note = """## Triage and analysis
 27
 28### Investigating MFA Deactivation with no Re-Activation for Okta User Account
 29
 30MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence.
 31
 32This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours.
 33
 34#### Possible investigation steps:
 35
 36- 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.
 37- 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.
 38- 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. 
 39- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.
 40    - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.
 41- Examine related administrative activity by the actor for privilege misuse or suspicious changes.
 42
 43#### False positive steps:
 44
 45- Determine with the target user if MFA deactivation was expected.
 46- Determine if MFA is required for the target user account.
 47
 48#### Response and remediation:
 49
 50- If the MFA deactivation was not expected, consider deactivating the user
 51    - This should be followed by resetting the user's password and re-enabling MFA.
 52- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives.
 53- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
 54- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
 55- Check if the compromised account was used to access or alter any sensitive data, applications or systems.
 56- Review the client user-agent to determine if it's a known custom application that can be whitelisted.
 57"""
 58references = [
 59    "https://developer.okta.com/docs/reference/api/system-log/",
 60    "https://developer.okta.com/docs/reference/api/event-types/",
 61    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
 62    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
 63    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
 64]
 65risk_score = 21
 66rule_id = "cd89602e-9db0-48e3-9391-ae3bf241acd8"
 67setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
 68severity = "low"
 69tags = [
 70    "Tactic: Persistence",
 71    "Use Case: Identity and Access Audit",
 72    "Data Source: Okta",
 73    "Domain: Cloud",
 74    "Resources: Investigation Guide",
 75]
 76type = "eql"
 77
 78query = '''
 79sequence by okta.target.id with maxspan=12h
 80    [any where event.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all")
 81        and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"]
 82    ![any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"]
 83'''
 84
 85
 86[[rule.threat]]
 87framework = "MITRE ATT&CK"
 88[[rule.threat.technique]]
 89id = "T1556"
 90name = "Modify Authentication Process"
 91reference = "https://attack.mitre.org/techniques/T1556/"
 92[[rule.threat.technique.subtechnique]]
 93id = "T1556.006"
 94name = "Multi-Factor Authentication"
 95reference = "https://attack.mitre.org/techniques/T1556/006/"
 96
 97
 98
 99[rule.threat.tactic]
100id = "TA0003"
101name = "Persistence"
102reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating MFA Deactivation with no Re-Activation for Okta User Account

MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence.

This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours.

Possible investigation steps:

  • 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:

  • Determine with the target user if MFA deactivation was expected.
  • Determine if MFA is required for the target user account.

Response and remediation:

  • If the MFA deactivation was not expected, consider deactivating the user
    • This should be followed by resetting the user's password and re-enabling MFA.
  • If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives.
  • Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
  • Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
  • Check if the compromised account was used to access or alter any sensitive data, applications or systems.
  • Review the client user-agent to determine if it's a known custom application that can be whitelisted.

References

Related rules

to-top