Administrator Role Assigned to an Okta User

 1[metadata]
 2creation_date = "2020/11/06"
 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 = """
12Identifies when an administrator role is assigned to an Okta user. An adversary may attempt to assign an administrator
13role to an Okta user in order to assign additional permissions to a user account and maintain access to their target's
14environment.
15"""
16false_positives = [
17    """
18    Administrator roles may be assigned to Okta users by a Super Admin user. Verify that the behavior was expected.
19    Exceptions can be added to this rule to filter expected behavior.
20    """,
21]
22index = ["filebeat-*", "logs-okta*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Administrator Role Assigned to an Okta User"
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 Administrator Role Assigned to an Okta User
32
33Okta is a widely used identity management service that facilitates secure user authentication and access control. In environments using Okta, assigning an administrator role grants elevated permissions, which can be exploited by adversaries to maintain unauthorized access. The detection rule monitors system events for privilege grants, flagging suspicious role assignments to mitigate potential abuse.
34
35### Possible investigation steps
36
37- Review the event details to confirm the presence of the event.dataset:okta.system and event.action:user.account.privilege.grant fields, ensuring the alert is triggered by the correct conditions.
38- Identify the user account that was assigned the administrator role and gather information about their recent activities and login history to assess any unusual behavior.
39- Check the timestamp of the role assignment event to determine if it coincides with any other suspicious activities or known incidents.
40- Investigate the source IP address and location associated with the role assignment event to verify if it aligns with the user's typical access patterns.
41- Review the change history for the affected user account to identify any other recent modifications or privilege escalations that may indicate malicious intent.
42- Consult with the user or their manager to verify if the role assignment was authorized and legitimate, documenting any discrepancies or unauthorized actions.
43
44### False positive analysis
45
46- Routine administrative tasks may trigger the rule when legitimate IT staff assign administrator roles for maintenance or onboarding purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
47- Automated scripts or integrations that require elevated permissions might cause false positives. Identify these scripts and whitelist their associated accounts to prevent unnecessary alerts.
48- Organizational changes such as mergers or department restructuring can lead to multiple legitimate role assignments. During these periods, temporarily adjust the rule sensitivity or increase monitoring to differentiate between expected and suspicious activities.
49- Training or testing environments where roles are frequently assigned for simulation purposes can generate false positives. Exclude these environments from the rule or set up a separate monitoring profile for them.
50
51### Response and remediation
52
53- Immediately revoke the administrator role from the affected Okta user account to prevent further unauthorized access or privilege escalation.
54- Conduct a thorough review of recent activity logs for the affected user account to identify any unauthorized actions or changes made while the elevated privileges were active.
55- Reset the password and enforce multi-factor authentication (MFA) for the affected user account to secure it against potential compromise.
56- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized role assignment and any identified malicious activities.
57- Implement additional monitoring for the affected user account and similar accounts to detect any further suspicious activities or attempts to reassign elevated privileges.
58- Review and update access control policies to ensure that administrator role assignments require additional verification or approval processes to prevent unauthorized changes.
59- If evidence of broader compromise is found, initiate a full security incident response process, including forensic analysis and potential involvement of external cybersecurity experts.
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://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm",
66    "https://developer.okta.com/docs/reference/api/system-log/",
67    "https://developer.okta.com/docs/reference/api/event-types/",
68    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
69    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
70    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
71    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
72]
73risk_score = 47
74rule_id = "f06414a6-f2a4-466d-8eba-10f85e8abf71"
75severity = "medium"
76tags = ["Data Source: Okta", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
77timestamp_override = "event.ingested"
78type = "query"
79
80query = '''
81event.dataset:okta.system and event.action:user.account.privilege.grant
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1098"
89name = "Account Manipulation"
90reference = "https://attack.mitre.org/techniques/T1098/"
91
92
93[rule.threat.tactic]
94id = "TA0003"
95name = "Persistence"
96reference = "https://attack.mitre.org/tactics/TA0003/"