Okta User Assigned Administrator Role

Feb 12, 2026 · Domain: Identity Data Source: Okta Data Source: Okta System Logs Use Case: Identity and Access Audit Tactic: Persistence Resources: Investigation Guide ·

Share on:

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/11/06"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2026/02/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator
 11privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the
 12environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be
 13used to bypass security controls and perform unauthorized administrative actions.
 14"""
 15false_positives = [
 16    """
 17    Administrator roles may be assigned to Okta users or groups by authorized Super Admin users during normal IT
 18    operations such as onboarding, role changes, or organizational restructuring. Verify that the behavior was expected
 19    and authorized. Exceptions can be added to this rule to filter known administrators, service accounts, or automated
 20    provisioning systems.
 21    """,
 22]
 23index = ["logs-okta*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "Okta User Assigned Administrator Role"
 27note = """## Triage and analysis
 28
 29### Investigating Okta User Assigned Administrator Role
 30
 31Okta 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.
 32
 33#### Possible investigation steps:
 34- 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.
 35- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields.
 36- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field.
 37- 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.
 38- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
 39- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
 40- Review the actor's recent authentication history and session activity for suspicious patterns.
 41- Verify whether the privilege grant was part of a legitimate change request or administrative workflow.
 42- Check for any other suspicious activities performed by the actor or target account around the same time.
 43- Review audit logs for any administrative actions performed after the privilege grant.
 44
 45### False positive analysis:
 46- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.
 47- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.
 48- During organizational changes or access certification processes, multiple role assignments may occur.
 49- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.
 50
 51### Response and remediation:
 52- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.
 53- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.
 54- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.
 55- Review all administrative actions performed by the target account after the privilege grant.
 56- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.
 57- Alert security leadership and identity management teams about the unauthorized privilege escalation.
 58- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.
 59- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.
 60- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.
 61"""
 62references = [
 63    "https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm",
 64    "https://developer.okta.com/docs/reference/api/system-log/",
 65    "https://developer.okta.com/docs/reference/api/event-types/",
 66    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
 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 = 47
 73rule_id = "f06414a6-f2a4-466d-8eba-10f85e8abf71"
 74severity = "medium"
 75tags = [
 76    "Domain: Identity",
 77    "Data Source: Okta",
 78    "Data Source: Okta System Logs",
 79    "Use Case: Identity and Access Audit",
 80    "Tactic: Persistence",
 81    "Resources: Investigation Guide",
 82]
 83timestamp_override = "event.ingested"
 84type = "query"
 85
 86query = '''
 87event.dataset:okta.system
 88    and event.action: (user.account.privilege.grant or group.privilege.grant)
 89    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*
 90'''
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1098"
 97name = "Account Manipulation"
 98reference = "https://attack.mitre.org/techniques/T1098/"
 99
100
101[rule.threat.tactic]
102id = "TA0003"
103name = "Persistence"
104reference = "https://attack.mitre.org/tactics/TA0003/"

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

Administrator roles and permissions | Okta Classic Engine

A comparison table that lists all Okta administrators and the permissions assigned to each admin role.

Read More
System Log

The Okta System Log records system events that are related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems. The System Log API provides near real-time, read-only access to your organization's System Log and is the programmatic counterpart of the [System Log UI](https://help.okta.com/okta_help.htm?id=ext_Reports_SysLog). The terms "event" and "log event" are often used interchangeably. In the context of this API, an "event" is an occurrence of interest within the system, and a "log" or "log event" is the recorded fact. The System Log API supports these primary use cases: * Event data export into a security information and event management system (SIEM) * System monitoring * Development debugging * Event introspection and audit > **Note:** Some of the curl code examples on this page include SSWS API token authentication. However, Okta recommends using scoped OAuth 2.0 and OIDC access tokens to authenticate with Okta management APIs. OAuth 2.0 and OIDC access tokens provide fine-grain control over the bearer's actions on specific endpoints. See [Okta API authentication methods](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/). For further details and examples, see [System Log query](https://developer.okta.com/docs/reference/system-log-query/).

Read More
Event Types | Okta Developer

Secure, scalable, and highly available authentication and user management for any app.

Read More
Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft | Google Cloud Blog

ShinyHunters-branded operations are using sophisticated vishing and victim-branded sites to steal data from cloud-based SaaS applications.

Read More
Testing your Okta visibility and detection with Dorothy and Elastic Security — Elastic Security Labs

Dorothy is a tool for security teams to test their visibility and detection capabilities for their Okta environment. IAM solutions are frequently targeted by adversaries but poorly monitored. Learn how to get started with Dorothy in this post.

Read More
Monitoring Okta threats with Elastic Security — Elastic Security Labs

This article guides readers through establishing an Okta threat detection lab, emphasizing the importance of securing SaaS platforms like Okta. It details creating a lab environment with the Elastic Stack, integrating SIEM solutions, and Okta.

Read More
Starter guide to understanding Okta — Elastic Security Labs

This article delves into Okta's architecture and services, laying a solid foundation for threat research and detection engineering. Essential reading for those aiming to master threat hunting and detection in Okta environments.

Read More
Okta and LAPSUS$: What you need to know — Elastic Security Labs

The latest organization under the microscope of the LAPSUS$ group is Okta. Threat hunt for the recent breach targeting Okta users using these simple steps in Elastic

Read More