Attempt to Deactivate an Okta Application
Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization's security controls or disrupt their business operations.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/11/06"
3integration = ["okta"]
4maturity = "production"
5updated_date = "2024/09/23"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta
11application in order to weaken an organization's security controls or disrupt their business operations.
12"""
13false_positives = [
14 """
15 Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
16 regularly deactivated and the behavior is expected.
17 """,
18]
19index = ["filebeat-*", "logs-okta*"]
20language = "kuery"
21license = "Elastic License v2"
22name = "Attempt to Deactivate an Okta Application"
23note = """## Triage and analysis
24
25### Investigating Attempt to Deactivate an Okta Application
26
27This rule detects attempts to deactivate an Okta application. Unauthorized deactivation could lead to disruption of services and pose a significant risk to the organization.
28
29#### Possible investigation steps:
30- Identify the actor associated with the deactivation attempt by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
31- 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.
32- 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.
33- Understand the context of the event from the `okta.debug_context.debug_data` and `okta.authentication_context` fields.
34- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed.
35- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field.
36- Analyze the `okta.transaction.id` and `okta.transaction.type` fields to understand the context of the transaction.
37- 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.
38
39### False positive analysis:
40- It might be a false positive if the action was part of a planned activity, performed by an authorized person, or if the `okta.outcome.result` field shows a failure.
41- An unsuccessful attempt might also indicate an authorized user having trouble rather than a malicious activity.
42
43### Response and remediation:
44- If unauthorized deactivation attempts are confirmed, initiate the incident response process.
45- 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.
46- Reset the user's password and enforce MFA re-enrollment, if applicable.
47- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
48- If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact.
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://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm",
56 "https://developer.okta.com/docs/reference/api/system-log/",
57 "https://developer.okta.com/docs/reference/api/event-types/",
58 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
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 = 21
63rule_id = "edb91186-1c7e-4db8-b53e-bfa33a1a0a8a"
64severity = "low"
65tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
66timestamp_override = "event.ingested"
67type = "query"
68
69query = '''
70event.dataset:okta.system and event.action:application.lifecycle.deactivate
71'''
72
73
74[[rule.threat]]
75framework = "MITRE ATT&CK"
76[[rule.threat.technique]]
77id = "T1489"
78name = "Service Stop"
79reference = "https://attack.mitre.org/techniques/T1489/"
80
81
82[rule.threat.tactic]
83id = "TA0040"
84name = "Impact"
85reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating Attempt to Deactivate an Okta Application
This rule detects attempts to deactivate an Okta application. Unauthorized deactivation could lead to disruption of services and pose a significant risk to the organization.
Possible investigation steps:
- Identify the actor associated with the deactivation attempt by examining the
okta.actor.id
,okta.actor.type
,okta.actor.alternate_id
, andokta.actor.display_name
fields. - 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. - Understand the context of the event from the
okta.debug_context.debug_data
andokta.authentication_context
fields. - Check the
okta.outcome.result
andokta.outcome.reason
fields to see if the attempt was successful or failed. - Review the past activities of the actor involved in this action by checking their previous actions logged in the
okta.target
field. - Analyze the
okta.transaction.id
andokta.transaction.type
fields to understand the context of the transaction. - 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, performed by an authorized person, or if the
okta.outcome.result
field shows a failure. - An unsuccessful attempt might also indicate an authorized user having trouble rather than a malicious activity.
Response and remediation:
- If unauthorized deactivation attempts are confirmed, initiate the incident response process.
- 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. - Reset the user's password and enforce MFA re-enrollment, if applicable.
- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
- If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact.
Setup
The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- Attempt to Delete an Okta Application
- Attempt to Modify an Okta Application
- Attempt to Revoke Okta API Token
- Possible Okta DoS Attack
- Administrator Privileges Assigned to an Okta Group