New Okta Authentication Behavior Detected

 1[metadata]
 2creation_date = "2023/11/07"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2024/09/23"
 6
 7[rule]
 8author = ["Elastic"]
 9description = "Detects events where Okta behavior detection has identified a new authentication behavior."
10from = "now-30m"
11index = ["filebeat-*", "logs-okta*"]
12interval = "15m"
13language = "kuery"
14license = "Elastic License v2"
15name = "New Okta Authentication Behavior Detected"
16note = """## Triage and analysis
17
18### Investigating New Okta Authentication Behavior Detected
19
20This rule detects events where Okta behavior detection has identified a new authentication behavior such as a new device or location.
21
22#### Possible investigation steps:
23- Identify the user involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
24- Determine the authentication anomaly by examining the `okta.debug_context.debug_data.risk_behaviors` and `okta.debug_context.debug_data.flattened` fields.
25- 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.
26- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields.
27- Review the past activities of the actor involved in this action by checking their previous actions.
28- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action.
29- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
30
31### False positive analysis:
32- A user may be using a new device or location to sign in.
33- The Okta behavior detection may be incorrectly identifying a new authentication behavior and need adjusted.
34
35### Response and remediation:
36- If the user is legitimate and the authentication behavior is not suspicious, no action is required.
37- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
38    - If MFA is already enabled, consider resetting MFA for the user.
39- If the user is not legitimate, consider deactivating the user's account.
40- If this is a false positive, consider adjusting the Okta behavior detection settings.
41- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields.
42- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
43
44## Setup
45
46The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
47"""
48references = [
49    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
50    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
51    "https://unit42.paloaltonetworks.com/muddled-libra/",
52    "https://help.okta.com/oie/en-us/content/topics/security/behavior-detection/about-behavior-detection.htm",
53    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
54    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
55]
56risk_score = 47
57rule_id = "260486ee-7d98-11ee-9599-f661ea17fbcd"
58severity = "medium"
59tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta"]
60timestamp_override = "event.ingested"
61type = "query"
62
63query = '''
64event.dataset:okta.system and okta.debug_context.debug_data.risk_behaviors:*
65'''
66
67
68[[rule.threat]]
69framework = "MITRE ATT&CK"
70
71[rule.threat.tactic]
72id = "TA0001"
73name = "Initial Access"
74reference = "https://attack.mitre.org/tactics/TA0001/"

References

• 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

• Cross-Tenant Impersonation: Prevention and Detection

  SummaryOkta has observed attacks in which a threat actor used social engineering to attain a highly privileged role in an Okta customer Orga

  
  Read More

• Threat Group Assessment: Muddled Libra (Updated)

  

  Muddled Libra continues to evolve. From social engineering to adaptation of new technologies, significant time is spent breaking down organizational defenses.

  
  Read More

• About Behavior Detection

  With this feature, admins can configure the system so that individual end users are only prompted for an additional MFA factor when there is a change in behavior that the admin defines.

  
  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

Related rules

• First Occurrence of Okta User Session Started via Proxy
• Okta FastPass Phishing Detection
• Okta Sign-In Events via Third-Party IdP
• Suspicious Activity Reported by Okta User
• Unauthorized Access to an Okta Application