Loading

Okta User Assigned Administrator Role

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.

Rule type: query
Rule indices:

  • logs-okta*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: ``
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Identity
  • Data Source: Okta
  • Data Source: Okta System Logs
  • Use Case: Identity and Access Audit
  • Tactic: Persistence
  • Resources: Investigation Guide

Version: 412
Rule authors:

  • Elastic

Rule license: Elastic License v2

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.

  • 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.
  • 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.
  • 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.
event.dataset:okta.system
    and event.action: (user.account.privilege.grant or group.privilege.grant)
    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*

Framework: MITRE ATT&CK