Okta User Session Impersonation


Description

A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected.

Query · kuery

data_stream.dataset:okta.system and event.action:user.session.impersonation.initiate

Analyst notes

Investigating Okta User Session Impersonation

The detection of an Okta User Session Impersonation indicates that a user has initiated a session impersonation which grants them access with the permissions of the user they are impersonating. This type of activity typically indicates Okta administrative access and should only ever occur if requested and expected.

Possible investigation steps
  • Identify the actor associated with the impersonation event by checking the okta.actor.id, okta.actor.type, okta.actor.alternate_id, or okta.actor.display_name fields.
  • Review the event.action field to confirm the initiation of the impersonation event.
  • Check the event.time field to understand the timing of the event.
  • Check the okta.target.id, okta.target.type, okta.target.alternate_id, or okta.target.display_name to identify the user who was impersonated.
  • Review any activities that occurred during the impersonation session. Look for any activities related to the impersonated user's account during and after the impersonation event.

False positive analysis

  • Verify if the session impersonation was part of an approved activity. Check if it was associated with any documented administrative tasks or troubleshooting efforts.
  • Ensure that the impersonation session was initiated by an authorized individual. You can check this by verifying the okta.actor.id or okta.actor.display_name against the list of approved administrators.

Response and remediation

  • If the impersonation was not authorized, consider it as a breach. Suspend the user account of the impersonator immediately.
  • Reset the user session and invalidate any active sessions related to the impersonated user.
  • If a specific impersonation technique was used, ensure that systems are patched or configured to prevent such techniques.
  • Conduct a thorough investigation to understand the extent of the breach and the potential impact on the systems and data.
  • Review and update your security policies to prevent such incidents in the future.
  • Implement additional monitoring and logging of Okta events to improve visibility of user actions.

Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

Raw source Okta User Session Impersonation · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2022/03/22"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
A user has initiated a session impersonation granting them access to the environment with the permissions of the user
they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested
and expected.
"""
from = "now-30m"
index = ["filebeat-*", "logs-okta*"]
interval = "15m"
language = "kuery"
license = "Elastic License v2"
name = "Okta User Session Impersonation"
note = """## Triage and analysis

### Investigating Okta User Session Impersonation

The detection of an Okta User Session Impersonation indicates that a user has initiated a session impersonation which grants them access with the permissions of the user they are impersonating. This type of activity typically indicates Okta administrative access and should only ever occur if requested and expected.

#### Possible investigation steps

- Identify the actor associated with the impersonation event by checking the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields.
- Review the `event.action` field to confirm the initiation of the impersonation event.
- Check the `event.time` field to understand the timing of the event.
- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the user who was impersonated.
- Review any activities that occurred during the impersonation session. Look for any activities related to the impersonated user's account during and after the impersonation event.

### False positive analysis

- Verify if the session impersonation was part of an approved activity. Check if it was associated with any documented administrative tasks or troubleshooting efforts.
- Ensure that the impersonation session was initiated by an authorized individual. You can check this by verifying the `okta.actor.id` or `okta.actor.display_name` against the list of approved administrators.

### Response and remediation

- If the impersonation was not authorized, consider it as a breach. Suspend the user account of the impersonator immediately.
- Reset the user session and invalidate any active sessions related to the impersonated user.
- If a specific impersonation technique was used, ensure that systems are patched or configured to prevent such techniques.
- Conduct a thorough investigation to understand the extent of the breach and the potential impact on the systems and data.
- Review and update your security policies to prevent such incidents in the future.
- Implement additional monitoring and logging of Okta events to improve visibility of user actions.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/",
    "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 = 73
rule_id = "cdbebdc1-dc97-43c6-a538-f26a20c0a911"
severity = "high"
tags = [
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Data Source: Okta",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:user.session.impersonation.initiate
'''


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

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

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

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

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.