From 035842caa60c25a0ca20e483bae018b1a6cad217 Mon Sep 17 00:00:00 2001 From: Jonhnathan Date: Tue, 31 May 2022 12:57:02 -0300 Subject: [PATCH] [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 <79124755+nastasha-solomon@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Joe Peeples Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com> Co-authored-by: Joe Peeples (cherry picked from commit 27f5c2e6958b5286671f5221c43968a93e44425b) --- ...sion_clearing_windows_console_history.toml | 44 ++++++++++++- ...e_evasion_clearing_windows_event_logs.toml | 46 +++++++++++++- ...vasion_clearing_windows_security_logs.toml | 40 +++++++++++- ...efense_evasion_disabling_windows_logs.toml | 63 ++++++++++++++++--- ...n_enable_network_discovery_with_netsh.toml | 43 ++++++++++++- ..._powershell_windows_firewall_disabled.toml | 44 ++++++++++++- .../execution_ms_office_written_file.toml | 61 +++++++++++++++++- rules/windows/execution_pdf_written_file.toml | 62 +++++++++++++++++- ...movement_executable_tool_transfer_smb.toml | 61 +++++++++++++++++- .../persistence_dontexpirepasswd_account.toml | 44 ++++++++++++- 10 files changed, 485 insertions(+), 23 deletions(-) diff --git a/rules/windows/defense_evasion_clearing_windows_console_history.toml b/rules/windows/defense_evasion_clearing_windows_console_history.toml index 42cae421f2e..eb86821a911 100644 --- a/rules/windows/defense_evasion_clearing_windows_console_history.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_clearing_windows_event_logs.toml b/rules/windows/defense_evasion_clearing_windows_event_logs.toml index e6c951d125b..29644b70788 100644 --- a/rules/windows/defense_evasion_clearing_windows_event_logs.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_clearing_windows_security_logs.toml b/rules/windows/defense_evasion_clearing_windows_security_logs.toml index 0a523524eae..248c209fd94 100644 --- a/rules/windows/defense_evasion_clearing_windows_security_logs.toml +++ b/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" diff --git a/rules/windows/defense_evasion_disabling_windows_logs.toml b/rules/windows/defense_evasion_disabling_windows_logs.toml index 350d88e497b..d28ece6f532 100644 --- a/rules/windows/defense_evasion_disabling_windows_logs.toml +++ b/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" diff --git a/rules/windows/defense_evasion_enable_network_discovery_with_netsh.toml b/rules/windows/defense_evasion_enable_network_discovery_with_netsh.toml index 04f8e8b0e58..cc0642844e5 100644 --- a/rules/windows/defense_evasion_enable_network_discovery_with_netsh.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_powershell_windows_firewall_disabled.toml b/rules/windows/defense_evasion_powershell_windows_firewall_disabled.toml index 702bd9e2d55..1506f95884f 100644 --- a/rules/windows/defense_evasion_powershell_windows_firewall_disabled.toml +++ b/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. """ diff --git a/rules/windows/execution_ms_office_written_file.toml b/rules/windows/execution_ms_office_written_file.toml index 01068897b8b..7d32d89a278 100644 --- a/rules/windows/execution_ms_office_written_file.toml +++ b/rules/windows/execution_ms_office_written_file.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/09/02" maturity = "production" -updated_date = "2021/07/19" +updated_date = "2022/05/23" [rule] author = ["Elastic"] @@ -15,6 +15,65 @@ interval = "60m" language = "eql" license = "Elastic License v2" name = "Execution of File Written or Modified by Microsoft Office" +note = """## Triage and analysis + +### Investigating Execution of File Written or Modified by Microsoft Office + +Microsoft 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 searches for executable files written by MS Office applications executed in sequence. This is most likely the result +of the execution of malicious documents or exploitation for initial access or privilege escalation. This rule can also detect +suspicious processes masquerading as the MS Office applications. + +#### 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). +""" risk_score = 21 rule_id = "0d8ad79f-9025-45d8-80c1-4f0cd3c5e8e5" severity = "high" diff --git a/rules/windows/execution_pdf_written_file.toml b/rules/windows/execution_pdf_written_file.toml index fb4a69e2f99..14e53e6cbc7 100644 --- a/rules/windows/execution_pdf_written_file.toml +++ b/rules/windows/execution_pdf_written_file.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/09/02" maturity = "production" -updated_date = "2021/07/19" +updated_date = "2022/05/23" [rule] author = ["Elastic"] @@ -15,7 +15,65 @@ interval = "60m" language = "eql" license = "Elastic License v2" name = "Execution of File Written or Modified by PDF Reader" -risk_score = 21 +note = """## Triage and analysis + +### Investigating Execution of File Written or Modified by PDF Reader + +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 searches for executable files written by PDF reader software and executed in sequence. This is most likely the +result of exploitation for privilege escalation or initial access. This rule can also detect suspicious processes masquerading as +PDF readers. + +#### 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 the 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). +""" +risk_score = 73 rule_id = "1defdd62-cd8d-426e-a246-81a37751bb2b" severity = "high" tags = ["Elastic", "Host", "Windows", "Threat Detection", "Execution"] diff --git a/rules/windows/lateral_movement_executable_tool_transfer_smb.toml b/rules/windows/lateral_movement_executable_tool_transfer_smb.toml index 8466fdd5e91..7f643135fb6 100644 --- a/rules/windows/lateral_movement_executable_tool_transfer_smb.toml +++ b/rules/windows/lateral_movement_executable_tool_transfer_smb.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/11/10" maturity = "production" -updated_date = "2022/01/13" +updated_date = "2022/05/23" [rule] author = ["Elastic"] @@ -13,7 +13,54 @@ from = "now-9m" index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"] language = "eql" license = "Elastic License v2" -name = "Lateral Tool Transfer" +name = "Potential Lateral Tool Transfer via SMB Share" +note = """## Triage and analysis + +### Investigating Potential Lateral Tool Transfer via SMB Share + +Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools +can include discovery utilities, credential dumpers, malware, etc. Attackers can also leverage file shares that employees +frequently access to host malicious files to gain a foothold in other machines. + +#### 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. +- Retrieve the created 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. + +### False positive analysis + +- This activity can happen legitimately. Consider adding exceptions if it is expected and noisy in your environment. + +### 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. +- Review the privileges needed to write to the network share and restrict write access as needed. +- 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 = "58bc134c-e8d2-4291-a552-b4b3e537c60b" severity = "medium" @@ -33,11 +80,21 @@ sequence by host.id with maxspan=30s [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1570" name = "Lateral Tool Transfer" reference = "https://attack.mitre.org/techniques/T1570/" +[[rule.threat.technique]] +id = "T1021" +name = "Remote Services" +reference = "https://attack.mitre.org/techniques/T1021/" + + [[rule.threat.technique.subtechnique]] + id = "T1021.002" + name = "SMB/Windows Admin Shares" + reference = "https://attack.mitre.org/techniques/T1021/002/" [rule.threat.tactic] id = "TA0008" diff --git a/rules/windows/persistence_dontexpirepasswd_account.toml b/rules/windows/persistence_dontexpirepasswd_account.toml index a0be997728f..b3b0f594d49 100644 --- a/rules/windows/persistence_dontexpirepasswd_account.toml +++ b/rules/windows/persistence_dontexpirepasswd_account.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2022/02/22" maturity = "production" -updated_date = "2022/02/22" +updated_date = "2022/05/23" [rule] author = ["Elastic"] @@ -22,7 +22,47 @@ from = "now-9m" index = ["winlogbeat-*", "logs-system.*"] language = "kuery" license = "Elastic License v2" -name = "Account configured with never Expiring Password" +name = "Account Configured with Never-Expiring Password" +note = """## Triage and analysis + +### Investigating Account Configured with Never-Expiring Password + +Active Directory provides a setting that prevents users' passwords from expiring. Enabling this setting is bad practice and can expose +environments to vulnerabilities that weaken security posture, especially when these accounts are privileged. + +The setting is usually configured so a user account can act as a service account. Attackers can abuse these accounts to +persist in the domain and maintain long-term access using compromised accounts with a never-expiring password set. + +#### Possible investigation steps + +- 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/source host during the past 48 hours. +- Inspect the account for suspicious or abnormal behaviors in the alert timeframe. + +### False positive analysis + +- This activity should not happen legitimately. The security team should address any potential benign true positive +(B-TP), as this configuration can put the user and the domain at risk. +- Using user accounts as service accounts is a bad security practice and should not be allowed in the domain. The +security team should map and monitor potential benign true positives (B-TPs), especially if the account is privileged. +For cases in which user accounts cannot be avoided, Microsoft provides the Group Managed Service Accounts (gMSA) feature, +which ensures that the account password is robust and changed regularly and automatically. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Reset the password of the account and update its password settings. +- Search for other occurrences on the domain. + - Using the [Active Directory PowerShell module](https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduser): + - `get-aduser -filter { passwordNeverExpires -eq $true -and enabled -eq $true } | ft` +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts, if +any, are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, +business systems, and web services. +- 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). +""" references = [ "https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dont_expire", "https://blog.menasec.net/2019/02/threat-hunting-26-persistent-password.html",