New Okta Identity Provider (IdP) Added by Admin

Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/11/06"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within
 11Okta.
 12"""
 13from = "now-30m"
 14index = ["filebeat-*", "logs-okta*"]
 15interval = "15m"
 16language = "kuery"
 17license = "Elastic License v2"
 18name = "New Okta Identity Provider (IdP) Added by Admin"
 19note = """## Triage and analysis
 20
 21### Investigating New Okta Identity Provider (IdP) Added by Admin
 22
 23This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta.
 24
 25#### Possible investigation steps:
 26- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
 27- Identify the IdP added by reviewing the `okta.target` field and determing if this IdP is authorized.
 28- 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.
 29- 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.
 30- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field.
 31- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action.
 32- 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.
 33
 34### False positive analysis:
 35- It might be a false positive if the action was part of a planned activity or performed by an authorized person.
 36- Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times.
 37
 38### Response and remediation:
 39- If the IdP is unauthorized, deactivate it immediately via the Okta console.
 40- If the IdP is authorized, ensure that the actor who created it is authorized to do so.
 41- If the actor is unauthorized, deactivate their account via the Okta console.
 42- If the actor is authorized, ensure that the actor's account is not compromised.
 43- Reset the user's password and enforce MFA re-enrollment, if applicable.
 44- 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.
 45- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
 46- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP.
 47
 48## Setup
 49
 50The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 51"""
 52references = [
 53    "https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/",
 54    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
 55    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
 56    "https://unit42.paloaltonetworks.com/muddled-libra/",
 57    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
 58    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
 59]
 60risk_score = 47
 61rule_id = "29b53942-7cd4-11ee-b70e-f661ea17fbcd"
 62severity = "medium"
 63tags = [
 64    "Use Case: Identity and Access Audit",
 65    "Tactic: Persistence",
 66    "Data Source: Okta",
 67    "Resources: Investigation Guide",
 68    "Noise: High",
 69    "Performance: Fast",
 70    "Profile: Aggressive",
 71    "Rule Type: Custom Query (KQL)",
 72    "Platform: Okta",
 73    "Domain: Identity",
 74]
 75timestamp_override = "event.ingested"
 76type = "query"
 77
 78query = '''
 79data_stream.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS"
 80'''
 81
 82
 83[[rule.threat]]
 84framework = "MITRE ATT&CK"
 85
 86[[rule.threat.technique]]
 87id = "T1556"
 88name = "Modify Authentication Process"
 89reference = "https://attack.mitre.org/techniques/T1556/"
 90
 91[[rule.threat.technique.subtechnique]]
 92id = "T1556.007"
 93name = "Hybrid Identity"
 94reference = "https://attack.mitre.org/techniques/T1556/007/"
 95
 96[rule.threat.tactic]
 97id = "TA0003"
 98name = "Persistence"
 99reference = "https://attack.mitre.org/tactics/TA0003/"
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103
104[[rule.threat.technique]]
105id = "T1484"
106name = "Domain or Tenant Policy Modification"
107reference = "https://attack.mitre.org/techniques/T1484/"
108
109[[rule.threat.technique.subtechnique]]
110id = "T1484.002"
111name = "Trust Modification"
112reference = "https://attack.mitre.org/techniques/T1484/002/"
113
114[[rule.threat.technique]]
115id = "T1556"
116name = "Modify Authentication Process"
117reference = "https://attack.mitre.org/techniques/T1556/"
118
119[[rule.threat.technique.subtechnique]]
120id = "T1556.007"
121name = "Hybrid Identity"
122reference = "https://attack.mitre.org/techniques/T1556/007/"
123
124[rule.threat.tactic]
125id = "TA0005"
126name = "Defense Evasion"
127reference = "https://attack.mitre.org/tactics/TA0005/"

Triage and analysis

Investigating New Okta Identity Provider (IdP) Added by Admin

This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta.

Possible investigation steps:

  • Identify the actor associated with the IdP creation by examining the okta.actor.id, okta.actor.type, okta.actor.alternate_id, and okta.actor.display_name fields.
  • Identify the IdP added by reviewing the okta.target field and determing if this IdP is authorized.
  • 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.
  • 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.
  • Review the past activities of the actor involved in this action by checking their previous actions logged in the okta.target field.
  • Examine the okta.request.ip_chain field to potentially determine if the actor used a proxy or VPN to perform this action.
  • 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.

False positive analysis:

  • It might be a false positive if the action was part of a planned activity or performed by an authorized person.
  • Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times.

Response and remediation:

  • If the IdP is unauthorized, deactivate it immediately via the Okta console.
  • If the IdP is authorized, ensure that the actor who created it is authorized to do so.
  • If the actor is unauthorized, deactivate their account via the Okta console.
  • If the actor is authorized, ensure that the actor's account is not compromised.
  • Reset the user's password and enforce MFA re-enrollment, if applicable.
  • 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.
  • Conduct a review of Okta policies and ensure they are in accordance with security best practices.
  • If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP.

Setup

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

References

Related rules

to-top