[Security Content] 8.3 Add Investigation Guides - 3 (#1990)

* [Security Content] 8.3 Add Investigation Guides - 3

* bump date

* Apply suggestions from code review

Co-authored-by: nastasha-solomon <[email protected]>

* Apply suggestions from code review

Co-authored-by: Joe Peeples <[email protected]>

Co-authored-by: nastasha-solomon <[email protected]>
Co-authored-by: Joe Peeples <[email protected]>

(cherry picked from commit 27f5c2e)

rules/windows/defense_evasion_clearing_windows_console_history.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/11/22"
 maturity = "production"
-updated_date = "2022/04/20"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Austin Songer"]
@@ -14,7 +14,47 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Clearing Windows Console History"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Clearing Windows Console History
+
+PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This
+makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+
+Attackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of
+logging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the
+execution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - Verify if any other anti-forensics behaviors were observed.
+- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be
+trying to cover up.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+  - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility.
+
+## Config
 
 If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
 """

rules/windows/defense_evasion_clearing_windows_event_logs.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,49 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Clearing Windows Event Logs"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Clearing Windows Event Logs
+
+Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries
+can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.
+
+This rule looks for the execution of the `wevtutil.exe` utility or the `Clear-EventLog` cmdlet to clear event logs.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - Verify if any other anti-forensics behaviors were observed.
+- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity
+and there are justifications for this action.
+- Analyze whether the cleared event log is pertinent to security and general monitoring. Administrators can clear
+non-relevant event logs using this mechanism. If this activity is expected and noisy in your environment, consider
+adding exceptions — preferably with a combination of user and command line conditions.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+  - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous
+  actions, if any, are investigated accordingly with their response playbooks.
+- Isolate the involved host to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+
+## Config
 
 If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
 """

rules/windows/defense_evasion_clearing_windows_security_logs.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/11/12"
 maturity = "production"
-updated_date = "2022/04/13"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Elastic", "Anabella Cristaldi"]
@@ -14,6 +14,44 @@ index = ["winlogbeat-*", "logs-system.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Windows Event Logs Cleared"
+note = """## Triage and analysis
+
+### Investigating Windows Event Logs Cleared
+
+Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries
+can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.
+
+This rule looks for the occurrence of clear actions on the `security` event log.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - Verify if any other anti-forensics behaviors were observed.
+- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+  - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous
+  actions, if any, are investigated accordingly with their response playbooks.
+- Isolate the involved host to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+"""
 risk_score = 21
 rule_id = "45ac4800-840f-414c-b221-53dd36a5aaf7"
 severity = "low"

rules/windows/defense_evasion_disabling_windows_logs.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/05/06"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Elastic", "Ivan Ninichuck", "Austin Songer"]
@@ -14,11 +14,51 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Disable Windows Event and Security Logs Using Built-in Tools"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Disable Windows Event and Security Logs Using Built-in Tools
+
+Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries
+can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.
+
+This rule looks for the usage of different utilities to disable the EventLog service or specific event logs.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - Verify if any other anti-forensics behaviors were observed.
+- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- Re-enable affected logging components, services, and security monitoring.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+
+## Config
 
 If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
 """
-references = ["https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman"]
+references = [
+  "https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman",
+  "https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63",
+]
 risk_score = 21
 rule_id = "4de76544-f0e5-486a-8f84-eae0b6063cdc"
 severity = "low"
@@ -46,12 +86,21 @@ framework = "MITRE ATT&CK"
 id = "T1070"
 name = "Indicator Removal on Host"
 reference = "https://attack.mitre.org/techniques/T1070/"
-[[rule.threat.technique.subtechnique]]
-id = "T1070.001"
-name = "Clear Windows Event Logs"
-reference = "https://attack.mitre.org/techniques/T1070/001/"
 
+  [[rule.threat.technique.subtechnique]]
+  id = "T1070.001"
+  name = "Clear Windows Event Logs"
+  reference = "https://attack.mitre.org/techniques/T1070/001/"
+
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
 
+  [[rule.threat.technique.subtechnique]]
+  id = "T1562.006"
+  name = "Indicator Blocking"
+  reference = "https://attack.mitre.org/techniques/T1562/006/"
 
 [rule.threat.tactic]
 id = "TA0005"

rules/windows/defense_evasion_enable_network_discovery_with_netsh.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/07"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,46 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Enable Host Network Discovery via Netsh"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Enable Host Network Discovery via Netsh
+
+The Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a
+device and blocks unauthorized network traffic flowing into or out of the local device.
+
+Attackers can enable Network Discovery on the Windows firewall to find other systems present in the same network. Systems
+with this setting enabled will communicate with other systems using broadcast messages, which can be used to identify
+targets for lateral movement. This rule looks for the setup of this setting using the netsh utility.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity
+and there are justifications for this configuration.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- Disable Network Discovery:
+    - Using netsh: `netsh advfirewall firewall set rule group="Network Discovery" new enable=No`
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+
+## Config
 
 If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
 """

rules/windows/defense_evasion_powershell_windows_firewall_disabled.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/10/15"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/23"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,47 @@ index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Windows Firewall Disabled via PowerShell"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Windows Firewall Disabled via PowerShell
+
+Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a
+device and blocks unauthorized network traffic flowing into or out of the local device.
+
+Attackers can disable the Windows firewall or its rules to enable lateral movement and command and control activity.
+
+This rule identifies patterns related to disabling the Windows firewall or its rules using the `Set-NetFirewallProfile`
+PowerShell cmdlet.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
+for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing
+troubleshooting.
+- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- Re-enable the firewall with its desired configurations.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
+identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
+systems, and web services.
+- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
+mean time to respond (MTTR).
+
+## Config
 
 If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
 """