Attempt to Reset MFA Factors for an Okta User Account

 1[metadata]
 2creation_date = "2020/05/21"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6min_stack_version = "8.15.0"
 7min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 8
 9[rule]
10author = ["Elastic"]
11description = """
12Detects attempts to reset an Okta user's enrolled multi-factor authentication (MFA) factors. An adversary may attempt to
13reset the MFA factors for an Okta user's account in order to register new MFA factors and abuse the account to blend in
14with normal activity in the victim's environment.
15"""
16false_positives = [
17    """
18    Consider adding exceptions to this rule to filter false positives if the MFA factors for Okta user accounts are
19    regularly reset in your organization.
20    """,
21]
22index = ["filebeat-*", "logs-okta*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Attempt to Reset MFA Factors for an Okta User Account"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
30
31### Investigating Attempt to Reset MFA Factors for an Okta User Account
32
33Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities.
34
35### Possible investigation steps
36
37- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt.
38- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time.
39- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual.
40- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise.
41- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation.
42- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary.
43
44### False positive analysis
45
46- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions.
47- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts.
48- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives.
49- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities.
50
51### Response and remediation
52
53- Immediately disable the affected Okta user account to prevent further unauthorized access.
54- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior.
55- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
56- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity.
57- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made.
58- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected.
59- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics.
60
61## Setup
62
63The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
64references = [
65    "https://developer.okta.com/docs/reference/api/system-log/",
66    "https://developer.okta.com/docs/reference/api/event-types/",
67    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
68    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
69    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
70    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
71]
72risk_score = 21
73rule_id = "729aa18d-06a6-41c7-b175-b65b739b1181"
74severity = "low"
75tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
76timestamp_override = "event.ingested"
77type = "query"
78
79query = '''
80event.dataset:okta.system and event.action:user.mfa.factor.reset_all
81'''
82
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86[[rule.threat.technique]]
87id = "T1098"
88name = "Account Manipulation"
89reference = "https://attack.mitre.org/techniques/T1098/"
90
91
92[rule.threat.tactic]
93id = "TA0003"
94name = "Persistence"
95reference = "https://attack.mitre.org/tactics/TA0003/"