Okta User Assigned Administrator Role

Description

Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions.

Query · kuery

data_stream.dataset:okta.system
    and event.action: (user.account.privilege.grant or group.privilege.grant)
    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*

Known false positives

  • Administrator roles may be assigned to Okta users or groups by authorized Super Admin users during normal IT operations such as onboarding, role changes, or organizational restructuring. Verify that the behavior was expected and authorized. Exceptions can be added to this rule to filter known administrators, service accounts, or automated provisioning systems.

Analyst notes

Investigating Okta User Assigned Administrator Role

Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques.

Possible investigation steps:

  • Identify the actor who performed the privilege grant by examining the okta.actor.id, okta.actor.type, okta.actor.alternate_id, and okta.actor.display_name fields.
  • Determine the target user or group that received administrator privileges by reviewing the okta.target fields.
  • Review the specific administrator role granted by examining the okta.debug_context.debug_data.flattened.privilegeGranted field.
  • Determine the client used by the actor. Review the okta.client.ip, okta.client.user_agent.raw_user_agent, okta.client.zone, okta.client.device, and okta.client.id fields.
  • Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
  • Examine the okta.request.ip_chain field to determine if the actor used a proxy or VPN.
  • Review the actor's recent authentication history and session activity for suspicious patterns.
  • Verify whether the privilege grant was part of a legitimate change request or administrative workflow.
  • Check for any other suspicious activities performed by the actor or target account around the same time.
  • Review audit logs for any administrative actions performed after the privilege grant.

False positive analysis:

  • Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.
  • Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.
  • During organizational changes or access certification processes, multiple role assignments may occur.
  • Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.

Response and remediation:

  • If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.
  • Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.
  • Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.
  • Review all administrative actions performed by the target account after the privilege grant.
  • Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.
  • Alert security leadership and identity management teams about the unauthorized privilege escalation.
  • Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.
  • Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.
  • If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.
Raw source Okta User Assigned Administrator Role · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2020/11/06"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator
privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the
environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be
used to bypass security controls and perform unauthorized administrative actions.
"""
false_positives = [
    """
    Administrator roles may be assigned to Okta users or groups by authorized Super Admin users during normal IT
    operations such as onboarding, role changes, or organizational restructuring. Verify that the behavior was expected
    and authorized. Exceptions can be added to this rule to filter known administrators, service accounts, or automated
    provisioning systems.
    """,
]
index = ["logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Okta User Assigned Administrator Role"
note = """## Triage and analysis

### Investigating Okta User Assigned Administrator Role

Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques.

#### Possible investigation steps:
- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields.
- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field.
- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
- Review the actor's recent authentication history and session activity for suspicious patterns.
- Verify whether the privilege grant was part of a legitimate change request or administrative workflow.
- Check for any other suspicious activities performed by the actor or target account around the same time.
- Review audit logs for any administrative actions performed after the privilege grant.

### False positive analysis:
- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.
- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.
- During organizational changes or access certification processes, multiple role assignments may occur.
- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.

### Response and remediation:
- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.
- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.
- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.
- Review all administrative actions performed by the target account after the privilege grant.
- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.
- Alert security leadership and identity management teams about the unauthorized privilege escalation.
- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.
- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.
- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.
"""
references = [
    "https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm",
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
]
risk_score = 47
rule_id = "f06414a6-f2a4-466d-8eba-10f85e8abf71"
severity = "medium"
tags = [
    "Domain: Identity",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system
    and event.action: (user.account.privilege.grant or group.privilege.grant)
    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.