[Security Content] 8.3 - Add Investigation Guides 2 (#1989)

* [Security Content] 8.3 - Add Investigation Guides 2 - Initial Commit

* .

* Add Related rules

* Apply suggestions from code review

Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com>

* Apply suggestions from code review

Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com>

* .

* .

* Apply suggestions from code review

Co-authored-by: Joe Peeples <joe.peeples@elastic.co>

Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com>
Co-authored-by: Joe Peeples <joe.peeples@elastic.co>

(cherry picked from commit e5d3c6329c)

rules/windows/collection_email_powershell_exchange_mailbox.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/12/15"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,57 @@ index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Exporting Exchange Mailbox via PowerShell"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Exporting Exchange Mailbox via PowerShell
+
+The `New-MailBoxExportRequest` cmdlet is used to begin the process of exporting contents of a primary mailbox or archive
+to a .pst file. Note that this is done on a per-mailbox basis and this cmdlet is available only in on-premises Exchange.
+
+Attackers can abuse this functionality in preparation for exfiltrating contents, which is likely to contain sensitive
+and strategic data.
+
+#### 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.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Investigate the export operation:
+  - 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.
+  - Check if this operation is done under change management and approved according to the organization's policy.
+  - Retrieve the operation status and use the `Get-MailboxExportRequest` cmdlet to review previous requests.
+  - By default, no group in Exchange has the privilege to import or export mailboxes. Investigate administrators that
+  assigned the "Mailbox Import Export" privilege for abnormal activity.
+- Investigate if there is a significant quantity of export requests in the alert timeframe. This operation is done on
+a per-mailbox basis and can be part of a mass export.
+- If the operation was completed successfully:
+  - Check if the file is on the path specified in the command.
+  - Investigate if the file was compressed, archived, or retrieved by the attacker for exfiltration.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity
+and it is done with proper approval.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- If the involved host is not the Exchange server, isolate the host to prevent further post-compromise behavior.
+- Use the `Remove-MailboxExportRequest` cmdlet to remove fully or partially completed export requests.
+- Prioritize cases that involve personally identifiable information (PII) or other classified data.
+- 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 of users with the "Mailbox Import Export" privilege to ensure that the least privilege principle
+is being followed.
+- Run a full scan using the antimalware tool in place. This scan can 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/credential_access_posh_request_ticket.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/01/24"
 maturity = "production"
-updated_date = "2022/05/09"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,24 @@ systems, and web services. Prioritize privileged accounts.
 - 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
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with with Advanced Audit Configuration:
+
+```
+Computer Configuration > 
+Administrative Templates > 
+Windows PowerShell > 
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
 """
 references = [
     "https://cobalt.io/blog/kerberoast-attack-techniques",

rules/windows/defense_evasion_code_injection_conhost.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/08/31"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +11,64 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Process from Conhost"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Suspicious Process from Conhost
+
+The Windows Console Host, or `conhost.exe`, is both the server application for all of the Windows Console APIs as well as
+the classic Windows user interface for working with command-line applications.
+
+The `conhost.exe` process doesn't normally have child processes. Any processes spawned by the `conhost.exe` process can indicate code
+injection activity or a suspicious process masquerading as the `conhost.exe` process.
+
+#### 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.
+- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+- Retrieve the process executable and determine if it is malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+### Related rules
+
+- Conhost Spawned By Suspicious Parent Process - 05b358de-aa6d-4f6c-89e6-78f74018b43b
+- Suspicious PowerShell Engine ImageLoad - 852c1f19-68e8-43a6-9dce-340771fe1be3
+
+### 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 hosts to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- 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_defender_disabled_via_registry.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/12/23"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,49 @@ license = "Elastic License v2"
 name = "Windows Defender Disabled via Registry Modification"
 note = """## Triage and analysis
 
-Detections should be investigated to identify if the hosts and users are authorized to use this tool. As this rule detects post-exploitation process activity, investigations into this should be prioritized.
+### Investigating Windows Defender Disabled via Registry Modification
+
+Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple
+environments. Disabling it is a common step in threat actor playbooks.
+
+This rule monitors the registry for configurations that disable Windows Defender or the start of its service.
+
+#### 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.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate
+software installations.
+- 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.
+- Check if this operation is done under change management and approved according to the organization's policy.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity,
+the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),
+and no other suspicious activity has been observed.
+
+### Related rules
+
+- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87
+- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3
+
+### 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.
+- 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.
+- Re-enable Windows Defender and restore the service configurations to automatic start.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Review the privileges assigned to the user 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
 

rules/windows/defense_evasion_disabling_windows_defender_powershell.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/07"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +12,54 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Disabling Windows Defender Security Settings via PowerShell"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Disabling Windows Defender Security Settings via PowerShell
+
+Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple
+environments. Disabling it is a common step in threat actor playbooks.
+
+This rule monitors the execution of commands that can tamper the Windows Defender antivirus features.
+
+#### 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.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate
+software installations.
+- 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.
+- Examine the command line to determine which action was executed. Based on that, examine exceptions, antivirus state,
+sample submission, etc.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity,
+the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),
+and no other suspicious activity has been observed.
+
+### Related rules
+
+- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb
+- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3
+
+### 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.
+- 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.
+- Based on the command line, take actions to restore the appropriate Windows Defender antivirus configurations.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Review the privileges assigned to the user 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_microsoft_defender_tampering.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/10/18"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -15,7 +15,54 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Microsoft Windows Defender Tampering"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Microsoft Windows Defender Tampering
+
+Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple
+environments. Disabling it is a common step in threat actor playbooks.
+
+This rule monitors the registry for modifications that disable Windows Defender features.
+
+#### 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.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate
+software installations.
+- 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.
+- Examine which features have been disabled, and check if this operation is done under change management and approved
+according to the organization's policy.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity,
+the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),
+and no other suspicious activity has been observed.
+
+### Related rules
+
+- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb
+- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87
+
+### 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.
+- 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.
+- Take actions to restore the appropriate Windows Defender antivirus configurations.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
+malware components.
+- Review the privileges assigned to the user 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_posh_assembly_load.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/10/15"
 maturity = "production"
-updated_date = "2022/02/16"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -14,6 +14,85 @@ index = ["winlogbeat-*", "logs-windows.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Suspicious .NET Reflection via PowerShell"
+note = """## Triage and analysis
+
+### Investigating Suspicious .NET Reflection via PowerShell
+
+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 use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script,
+which can circumvent file-based security protections.
+
+#### Possible investigation steps
+
+- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration
+capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
+- Investigate the script 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.
+- Examine file or network events from the involved PowerShell process for suspicious behavior.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Evaluate whether the user needs to use PowerShell to complete tasks.
+- Retrieve the script and determine if it is malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did
+not identify malware or suspicious activity related to the user or host, this alert can be dismissed.
+
+### Related rules
+
+- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
+- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
+- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
+
+### 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.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- 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.
+- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
+- 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
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with with Advanced Audit Configuration:
+
+```
+Computer Configuration > 
+Administrative Templates > 
+Windows PowerShell > 
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+"""
 references = [
     "https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load",
 ]

rules/windows/defense_evasion_posh_compressed.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/10/19"
 maturity = "production"
-updated_date = "2022/03/02"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,85 @@ index = ["winlogbeat-*", "logs-windows.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "PowerShell Suspicious Payload Encoded and Compressed"
+note = """## Triage and analysis
+
+### Investigating PowerShell Suspicious Payload Encoded and Compressed
+
+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 embed compressed and encoded payloads in scripts to load directly into the memory without touching the
+disk. This strategy can circumvent string and file-based security protections.
+
+#### Possible investigation steps
+
+- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration
+capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
+- Investigate the script 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.
+- Examine file or network events from the involved PowerShell process for suspicious behavior.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Evaluate whether the user needs to use PowerShell to complete tasks.
+- Retrieve the script and determine if it is malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did
+not identify malware or suspicious activity related to the user or host, this alert can be dismissed.
+
+### Related rules
+
+- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
+- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
+- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
+
+### 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.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- 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.
+- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
+- 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
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with with Advanced Audit Configuration:
+
+```
+Computer Configuration > 
+Administrative Templates > 
+Windows PowerShell > 
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+"""
 risk_score = 47
 rule_id = "81fe9dc6-a2d7-4192-a2d8-eed98afc766a"
 severity = "medium"

rules/windows/execution_suspicious_pdf_reader.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/03/30"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,64 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious PDF Reader Child Process"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Suspicious PDF Reader Child Process
+
+PDF is a common file type used in corporate environments and most machines have software to handle these files. This
+creates a vector where attackers can exploit the engines and technology behind this class of software for initial access
+or privilege escalation.
+
+This rule looks for commonly abused built-in utilities spawned by a PDF reader process, which is likely a malicious behavior.
+
+#### 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.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Retrieve PDF documents received and opened by the user that could cause this behavior. Common locations include, but
+are not limited to, the Downloads and Document folders and the folder configured at the email client.
+- Determine if the collected files are malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+
+### 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.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- Run a full scan using the antimalware tool in place. This scan can 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. 
+  - If the malicious file was delivered via phishing:
+    - Block the email sender from sending future emails.
+    - Block the malicious web pages.
+    - Remove emails from the sender from mailboxes.
+    - Consider improvements to the security awareness program.
+- 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/execution_suspicious_powershell_imgload.toml

@@ -3,7 +3,7 @@ creation_date = "2020/11/17"
 maturity = "production"
 min_stack_comments = "EQL regex syntax introduced in 7.12"
 min_stack_version = "7.12.0"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,79 @@ index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious PowerShell Engine ImageLoad"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Suspicious PowerShell Engine ImageLoad
+
+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 use PowerShell without having to execute `PowerShell.exe` directly. This technique, often called
+"PowerShell without PowerShell," works by using the underlying System.Management.Automation namespace and can bypass
+application allowlisting and PowerShell security features.
+
+#### 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.
+- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+- Retrieve the implementation (DLL, executable, etc.) and determine if it is malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+### False positive analysis
+
+- This activity can happen legitimately. Some vendors have their own PowerShell implementations that are shipped with
+some products. These benign true positives (B-TPs) can be added as exceptions if necessary after analysis.
+
+### 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.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- 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
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with with Advanced Audit Configuration:
+
+```
+Computer Configuration > 
+Administrative Templates > 
+Windows PowerShell > 
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+
+## 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/execution_via_hidden_shell_conhost.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/08/17"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,65 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Conhost Spawned By Suspicious Parent Process"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Conhost Spawned By Suspicious Parent Process
+
+The Windows Console Host, or `conhost.exe`, is both the server application for all of the Windows Console APIs as well as
+the classic Windows user interface for working with command-line applications.
+
+Attackers often rely on custom shell implementations to avoid using built-in command interpreters like `cmd.exe` and 
+`PowerShell.exe` and bypass application allowlisting and security features. Attackers commonly inject these implementations into
+legitimate system processes.
+
+#### 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.
+- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+- Retrieve the parent process executable and determine if it is malicious:
+  - Use a private sandboxed malware analysis system to perform analysis.
+    - Observe and collect information about the following activities:
+      - Attempts to contact external domains and addresses.
+      - File and registry access, modification, and creation activities.
+      - Service creation and launch activities.
+      - Scheduled tasks creation.
+  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
+    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+### Related rules
+
+- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26
+- Suspicious PowerShell Engine ImageLoad - 852c1f19-68e8-43a6-9dce-340771fe1be3
+
+### 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.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that
+  attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- 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.
 """