[Security Content] 8.4 - Add Investigation Guides (#2069)

* [Security Content] 8.4 - Add Investigation Guides

* Apply suggestions from code review

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

* Update rules/windows/credential_access_cmdline_dump_tool.toml

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

* Apply suggestions from code review

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

* Update rules/windows/credential_access_credential_dumping_msbuild.toml

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

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

Removed changes from:
- rules/windows/execution_command_shell_started_by_svchost.toml

(selectively cherry picked from commit 3a8efc8183)

rules/windows/credential_access_cmdline_dump_tool.toml

@@ -3,7 +3,7 @@ creation_date = "2020/11/24"
 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/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,53 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Credential Access via Windows Utilities"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Potential Credential Access via Windows Utilities
+
+Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible
+for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles
+password changes, and creates access tokens.
+
+The `Ntds.dit` file is a database that stores Active Directory data, including information about user objects, groups, and
+group membership.
+
+This rule looks for the execution of utilities that can extract credential data from the LSASS memory and Active
+Directory `Ntds.dit` 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.
+- 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.
+- Examine the command line to identify what information was targeted.
+- Identify the target computer and its role in the IT environment.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious
+must be monitored by the security team.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- If the host is a domain controller (DC):
+  - Activate your incident response plan for total Active Directory compromise.
+  - Review the privileges assigned to users that can access the DCs, to ensure that the least privilege principle is
+  being followed and to reduce the attack surface.
+- 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.
+- 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/credential_access_credential_dumping_msbuild.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/03/25"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,66 @@ from = "now-9m"
 index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
-name = "Microsoft Build Engine Loading Windows Credential Libraries"
+name = "Potential Credential Access via Trusted Developer Utility"
+note = """## Triage and analysis
+
+### Investigating Potential Credential Access via Trusted Developer Utility
+
+The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML
+schema for a project file that controls how the build platform processes and builds software.
+
+Adversaries can abuse MSBuild to proxy the execution of malicious code. The inline task capability of MSBuild that was
+introduced in .NET version 4 allows for C# or Visual Basic code to be inserted into an XML project file. MSBuild will
+compile and execute the inline task. `MSBuild.exe` is a signed Microsoft binary, and the execution of code using it can bypass
+application control defenses that are configured to allow `MSBuild.exe` execution.
+
+This rule looks for the MSBuild process loading `vaultcli.dll` or `SAMLib.DLL`, which indicates the execution of
+credential access activities.
+
+#### 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.
+- Examine the command line to identify the `.csproj` file location.
+- Retrieve the file 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.
+- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target
+host after the registry modification.
+
+### 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).
+"""
 risk_score = 73
 rule_id = "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae5"
 severity = "high"

rules/windows/defense_evasion_execution_msbuild_started_by_office_app.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/03/25"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,71 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Microsoft Build Engine Started by an Office Application"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Microsoft Build Engine Started by an Office Application
+
+Microsoft Office (MS Office) is a suite of applications designed to help with productivity and completing common tasks on a computer.
+You can create and edit documents containing text and images, work with data in spreadsheets and databases, and create
+presentations and posters. As it is some of the most-used software across companies, MS Office is frequently targeted
+for initial access. It also has a wide variety of capabilities that attackers can take advantage of.
+
+The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML
+schema for a project file that controls how the build platform processes and builds software, and can be abused to proxy
+execution of code.
+
+This rule looks for the `Msbuild.exe` utility spawned by MS Office programs. This is generally the result of the
+execution of malicious documents.
+
+#### 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.
+- Retrieve MS Office 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/defense_evasion_system_critical_proc_abnormal_file_activity.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/08/19"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,55 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Unusual Executable File Creation by a System Critical Process"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Unusual Executable File Creation by a System Critical Process
+
+Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these
+characteristics is file operations.
+
+This rule looks for the creation of executable files done by system-critical processes. This can indicate the exploitation
+of a vulnerability or a malicious process masquerading as a system-critical 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 other alerts associated with the user/host during the past 48 hours.
+- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+
+### 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.
+- 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 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/execution_psexec_lateral_movement_command.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2021/03/03"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -20,6 +20,49 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "PsExec Network Connection"
+note = """## Triage and analysis
+
+### Investigating PsExec Network Connection
+
+PsExec is a remote administration tool that enables the execution of commands with both regular and SYSTEM privileges
+on Windows systems. Microsoft develops it as part of the Sysinternals Suite. Although commonly used by administrators,
+PsExec is frequently used by attackers to enable lateral movement and execute commands as SYSTEM to disable defenses and
+bypass security protections.
+
+This rule identifies PsExec execution by looking for the creation of `PsExec.exe`, the default name for the
+utility, followed by a network connection done by the process.
+
+#### Possible investigation steps
+
+- Check if the usage of this tool complies with the organization's administration policy.
+- 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.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Identify the target computer and its role in the IT environment.
+- Investigate what commands were run, and assess whether this behavior is prevalent in the environment by looking for
+similar occurrences across hosts.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. As long as the analyst did not identify suspicious activity related to the
+user or involved hosts, and the tool is allowed by the organization's policy, such alerts can be dismissed.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+  - Prioritize accordingly with the role of the servers and users involved.
+- 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.
+- 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.
+- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
+- 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 = "55d551c6-333b-4665-ab7e-5d14a59715ce"
 severity = "low"

rules/windows/initial_access_suspicious_ms_office_child_process.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2022/05/29"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,65 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious MS Office Child Process"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Suspicious MS Office Child Process
+
+Microsoft Office (MS Office) is a suite of applications designed to help with productivity and completing common tasks on a computer.
+You can create and edit documents containing text and images, work with data in spreadsheets and databases, and create
+presentations and posters. As it is some of the most-used software across companies, MS Office is frequently targeted
+for initial access. It also has a wide variety of capabilities that attackers can take advantage of.
+
+This rule looks for suspicious processes spawned by MS Office programs. This is generally the result of the execution of
+malicious documents.
+
+#### 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 MS Office 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/initial_access_suspicious_ms_outlook_child_process.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,63 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious MS Outlook Child Process"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Suspicious MS Outlook Child Process
+
+Microsoft Outlook is an email client that provides contact, email calendar, and task management features. Outlook is
+widely used, either standalone or as part of the Office suite.
+
+This rule looks for suspicious processes spawned by MS Outlook, which can be the result of the execution of malicious
+documents and/or exploitation for initial access.
+
+#### 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 recently opened files received via email 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/lateral_movement_direct_outbound_smb_connection.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2021/09/23"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,55 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Direct Outbound SMB Connection"
+note = """## Triage and analysis
+
+### Investigating Direct Outbound SMB Connection
+
+This rule looks for unexpected processes making network connections over port 445. Windows file sharing is typically
+implemented over Server Message Block (SMB), which communicates between hosts using port 445. When legitimate, these
+network connections are established by the kernel (PID 4). Occurrences of non-system processes using this port can indicate
+port scanners, exploits, and tools used to move laterally on the environment.
+
+#### 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.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+
+### False positive analysis
+
+- 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.
+- Isolate the involved host 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.
+- 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 = 47
 rule_id = "c82c7d8f-fb9e-4874-a4bd-fd9e3f9becf1"
 severity = "medium"

rules/windows/privilege_escalation_unusual_parentchild_relationship.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/02/18"
 maturity = "production"
-updated_date = "2022/03/31"
+updated_date = "2022/07/05"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +14,55 @@ index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Unusual Parent-Child Relationship"
-note = """## Config
+note = """## Triage and analysis
+
+### Investigating Unusual Parent-Child Relationship
+
+Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these
+characteristics is parent-child relationships. These relationships can be used to baseline the typical behavior of the
+system and then alert on occurrences that don't comply with the baseline.
+
+This rule uses this information to spot suspicious parent and child 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 other alerts associated with the user/host during the past 48 hours.
+- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file
+modifications, and any spawned child processes.
+- 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.
+
+### 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.
+- 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 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.
 """