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 = "2024/12/09"
6min_stack_version = "8.15.0"
7min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within
13Okta.
14"""
15from = "now-30m"
16index = ["filebeat-*", "logs-okta*"]
17interval = "15m"
18language = "kuery"
19license = "Elastic License v2"
20name = "New Okta Identity Provider (IdP) Added by Admin"
21note = """## Triage and analysis
22
23### Investigating New Okta Identity Provider (IdP) Added by Admin
24
25This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta.
26
27#### Possible investigation steps:
28- 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.
29- Identify the IdP added by reviewing the `okta.target` field and determing if this IdP is authorized.
30- 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.
31- 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.
32- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field.
33- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action.
34- 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.
35
36### False positive analysis:
37- It might be a false positive if the action was part of a planned activity or performed by an authorized person.
38- Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times.
39
40### Response and remediation:
41- If the IdP is unauthorized, deactivate it immediately via the Okta console.
42- If the IdP is authorized, ensure that the actor who created it is authorized to do so.
43- If the actor is unauthorized, deactivate their account via the Okta console.
44- If the actor is authorized, ensure that the actor's account is not compromised.
45- Reset the user's password and enforce MFA re-enrollment, if applicable.
46- 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.
47- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
48- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP.
49
50## Setup
51
52The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
53"""
54references = [
55 "https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/",
56 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
57 "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
58 "https://unit42.paloaltonetworks.com/muddled-libra/",
59 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
60 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
61]
62risk_score = 47
63rule_id = "29b53942-7cd4-11ee-b70e-f661ea17fbcd"
64severity = "medium"
65tags = ["Use Case: Identity and Access Audit", "Tactic: Persistence", "Data Source: Okta"]
66timestamp_override = "event.ingested"
67type = "query"
68
69query = '''
70event.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS"
71'''
72
73
74[[rule.threat]]
75framework = "MITRE ATT&CK"
76[[rule.threat.technique]]
77id = "T1556"
78name = "Modify Authentication Process"
79reference = "https://attack.mitre.org/techniques/T1556/"
80[[rule.threat.technique.subtechnique]]
81id = "T1556.007"
82name = "Hybrid Identity"
83reference = "https://attack.mitre.org/techniques/T1556/007/"
84
85
86
87[rule.threat.tactic]
88id = "TA0003"
89name = "Persistence"
90reference = "https://attack.mitre.org/tactics/TA0003/"
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
, andokta.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
, andokta.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
, andokta.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
andokta.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
- Administrator Privileges Assigned to an Okta Group
- Administrator Role Assigned to an Okta User
- Attempt to Create Okta API Token
- Attempt to Reset MFA Factors for an Okta User Account
- MFA Deactivation with no Re-Activation for Okta User Account