New Okta Identity Provider (IdP) Added by Admin


Description

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

Query · kuery

data_stream.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS"

Analyst notes

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.

Raw source New Okta Identity Provider (IdP) Added by Admin · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2023/11/06"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within
Okta.
"""
from = "now-30m"
index = ["filebeat-*", "logs-okta*"]
interval = "15m"
language = "kuery"
license = "Elastic License v2"
name = "New Okta Identity Provider (IdP) Added by Admin"
note = """## 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 = [
    "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://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
    "https://unit42.paloaltonetworks.com/muddled-libra/",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "29b53942-7cd4-11ee-b70e-f661ea17fbcd"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Data Source: Okta",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS"
'''


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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.007"
name = "Hybrid Identity"
reference = "https://attack.mitre.org/techniques/T1556/007/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

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

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[[rule.threat.technique.subtechnique]]
id = "T1484.002"
name = "Trust Modification"
reference = "https://attack.mitre.org/techniques/T1484/002/"

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.007"
name = "Hybrid Identity"
reference = "https://attack.mitre.org/techniques/T1556/007/"

[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.