diff --git a/rules/windows/collection_email_powershell_exchange_mailbox.toml b/rules/windows/collection_email_powershell_exchange_mailbox.toml index cd5fd6840ad..a905fd663c4 100644 --- a/rules/windows/collection_email_powershell_exchange_mailbox.toml +++ b/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. """ diff --git a/rules/windows/credential_access_posh_request_ticket.toml b/rules/windows/credential_access_posh_request_ticket.toml index 7cf2f22a7ae..ba6bf6d32eb 100644 --- a/rules/windows/credential_access_posh_request_ticket.toml +++ b/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", diff --git a/rules/windows/defense_evasion_code_injection_conhost.toml b/rules/windows/defense_evasion_code_injection_conhost.toml index 22612b22905..47028d052ca 100644 --- a/rules/windows/defense_evasion_code_injection_conhost.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_defender_disabled_via_registry.toml b/rules/windows/defense_evasion_defender_disabled_via_registry.toml index 041b3b8ec50..ca20d35fd6f 100644 --- a/rules/windows/defense_evasion_defender_disabled_via_registry.toml +++ b/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 diff --git a/rules/windows/defense_evasion_disabling_windows_defender_powershell.toml b/rules/windows/defense_evasion_disabling_windows_defender_powershell.toml index 4c5a75cdfb8..129f61bdba6 100644 --- a/rules/windows/defense_evasion_disabling_windows_defender_powershell.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_microsoft_defender_tampering.toml b/rules/windows/defense_evasion_microsoft_defender_tampering.toml index 71db482ccc5..cb96667c1bd 100644 --- a/rules/windows/defense_evasion_microsoft_defender_tampering.toml +++ b/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. """ diff --git a/rules/windows/defense_evasion_posh_assembly_load.toml b/rules/windows/defense_evasion_posh_assembly_load.toml index b1b9724b2ae..45bbc12d88b 100644 --- a/rules/windows/defense_evasion_posh_assembly_load.toml +++ b/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", ] diff --git a/rules/windows/defense_evasion_posh_compressed.toml b/rules/windows/defense_evasion_posh_compressed.toml index 4f8f7dd28dd..84b8ed33c11 100644 --- a/rules/windows/defense_evasion_posh_compressed.toml +++ b/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" diff --git a/rules/windows/execution_suspicious_pdf_reader.toml b/rules/windows/execution_suspicious_pdf_reader.toml index 760b0272cb4..0a41ee9aa42 100644 --- a/rules/windows/execution_suspicious_pdf_reader.toml +++ b/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. """ diff --git a/rules/windows/execution_suspicious_powershell_imgload.toml b/rules/windows/execution_suspicious_powershell_imgload.toml index 1ad2cc1501e..aee5b809bd4 100644 --- a/rules/windows/execution_suspicious_powershell_imgload.toml +++ b/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. """ diff --git a/rules/windows/execution_via_hidden_shell_conhost.toml b/rules/windows/execution_via_hidden_shell_conhost.toml index 42d9ee46667..71463955232 100644 --- a/rules/windows/execution_via_hidden_shell_conhost.toml +++ b/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. """