Okta User Session Impersonation

 1[metadata]
 2creation_date = "2022/03/22"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2024/09/23"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10A user has initiated a session impersonation granting them access to the environment with the permissions of the user
11they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested
12and expected.
13"""
14from = "now-30m"
15index = ["filebeat-*", "logs-okta*"]
16interval = "15m"
17language = "kuery"
18license = "Elastic License v2"
19name = "Okta User Session Impersonation"
20note = """## Triage and analysis
21
22### Investigating Okta User Session Impersonation
23
24The 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.
25
26#### Possible investigation steps
27
28- 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.
29- Review the `event.action` field to confirm the initiation of the impersonation event.
30- Check the `event.time` field to understand the timing of the event.
31- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the user who was impersonated.
32- 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.
33
34### False positive analysis
35
36- Verify if the session impersonation was part of an approved activity. Check if it was associated with any documented administrative tasks or troubleshooting efforts.
37- 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.
38
39### Response and remediation
40
41- If the impersonation was not authorized, consider it as a breach. Suspend the user account of the impersonator immediately.
42- Reset the user session and invalidate any active sessions related to the impersonated user.
43- If a specific impersonation technique was used, ensure that systems are patched or configured to prevent such techniques.
44- Conduct a thorough investigation to understand the extent of the breach and the potential impact on the systems and data.
45- Review and update your security policies to prevent such incidents in the future.
46- Implement additional monitoring and logging of Okta events to improve visibility of user actions.
47
48## Setup
49
50The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
51references = [
52    "https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/",
53    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
54    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
55    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
56    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
57]
58risk_score = 73
59rule_id = "cdbebdc1-dc97-43c6-a538-f26a20c0a911"
60severity = "high"
61tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
62timestamp_override = "event.ingested"
63type = "query"
64
65query = '''
66event.dataset:okta.system and event.action:user.session.impersonation.initiate
67'''
68
69
70[[rule.threat]]
71framework = "MITRE ATT&CK"
72
73[rule.threat.tactic]
74id = "TA0006"
75name = "Credential Access"
76reference = "https://attack.mitre.org/tactics/TA0006/"

References

• Cloudflare’s investigation of the January 2022 Okta compromise

  

  Today at 03:30 UTC we learnt of a compromise of Okta. We use Okta internally for employee identity as part of our authentication stack. We have investigated this compromise carefully and do not believe we have been compromised as a result.

  
  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

Related rules

• Attempted Bypass of Okta MFA
• Attempts to Brute Force an Okta User Account
• Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy
• Okta Brute Force or Password Spraying Attack
• Potential Okta MFA Bombing via Push Notifications