diff --git a/detections/deprecated/remote_wmi_command_attempt.yml b/detections/deprecated/remote_wmi_command_attempt.yml deleted file mode 100644 index 62d8a331fc..0000000000 --- a/detections/deprecated/remote_wmi_command_attempt.yml +++ /dev/null @@ -1,47 +0,0 @@ -name: Remote WMI Command Attempt -id: 272df6de-61f1-4784-877c-1fbc3e2d0838 -version: 2 -date: '2018-12-03' -author: Rico Valdez, Splunk -type: batch -datamodel: -- Endpoint -description: This search looks for wmic.exe being launched with parameters to operate - on remote systems. -search: '| tstats `security_content_summariesonly` count values(Processes.process) - as process values(Processes.parent_process) as parent_process min(_time) as firstTime - max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=wmic.exe AND - Processes.process= */node* by Processes.user Processes.process_name Processes.parent_process_name - Processes.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)` | `remote_wmi_command_attempt_filter`' -how_to_implement: You must be ingesting data that records process activity from your - hosts to populate the Endpoint data model in the Processes node. You must also be - ingesting logs with both the process name and command line from your endpoints. - The command-line arguments are mapped to the "process" field in the Endpoint data - model. Deprecated because duplicate of Remote Process Instantiation via WMI. -known_false_positives: Administrators may use this legitimately to gather info from - remote systems. -references: [] -tags: - analytic_story: - - Suspicious WMI Use - asset_type: Endpoint - cis20: - - CIS 3 - - CIS 5 - kill_chain_phases: - - Actions on Objectives - mitre_attack_id: - - T1047 - nist: - - PR.PT - - PR.AT - - PR.AC - - PR.IP - product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud - required_fields: - - _time - security_domain: endpoint diff --git a/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml b/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml new file mode 100644 index 0000000000..3b867b780c --- /dev/null +++ b/detections/endpoint/detect_empire_with_powershell_script_block_logging.yml @@ -0,0 +1,59 @@ +name: Detect Empire with PowerShell Script Block Logging +id: bc1dc6b8-c954-11eb-bade-acde48001122 +version: 1 +date: '2021-06-09' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies the common PowerShell stager used by PowerShell-Empire. + Each stager that may use PowerShell all uses the same pattern. The initial HTTP + will be base64 encoded and use `system.net.webclient`. Note that some obfuscation + may evade the analytic. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 (Message=*system.net.webclient* AND Message=*frombase64string*) + | stats count min(_time) as firstTime max(_time) as lastTime by OpCode ComputerName + User EventCode Message | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_empire_with_powershell_script_block_logging_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: False positives may only pertain to it not being related to + Empire, but another framework. Filter as needed if any applications use the same + pattern. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +- https://github.com/BC-SECURITY/Empire +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1059.001 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml b/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml new file mode 100644 index 0000000000..8b2e4686f3 --- /dev/null +++ b/detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml @@ -0,0 +1,56 @@ +name: Detect Mimikatz With PowerShell Script Block Logging +id: 8148c29c-c952-11eb-9255-acde48001122 +version: 1 +date: '2021-06-09' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies common Mimikatz functions that may be identified in the + script block, including `mimikatz`. This will catch the most basic use cases for + Pass the Ticket, Pass the Hash and `-DumprCreds`. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message IN (*mimikatz*, *-dumpcr*, *sekurlsa::pth*, + *kerberos::ptt*, *kerberos::golden*) | stats count min(_time) as firstTime max(_time) + as lastTime by OpCode ComputerName User EventCode Message | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `detect_mimikatz_with_powershell_script_block_logging_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: False positives should be limited as the commands being identifies + are quite specific to EventCode 4104 and Mimikatz. Filter as needed. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1003 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/detect_wmi_event_subscription_persistence.yml b/detections/endpoint/detect_wmi_event_subscription_persistence.yml new file mode 100644 index 0000000000..8636a817cc --- /dev/null +++ b/detections/endpoint/detect_wmi_event_subscription_persistence.yml @@ -0,0 +1,62 @@ +name: Detect WMI Event Subscription Persistence +id: 01d9a0c2-cece-11eb-ab46-acde48001122 +version: 1 +date: '2021-06-16' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic identifies the use of WMI Event Subscription + to establish persistence or perform privilege escalation. WMI can be used to install + event filters, providers, consumers, and bindings that execute code when a defined + event occurs. WMI subscription execution is proxied by the WMI Provider Host process + (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic + is restricted by commonly added process execution and a path. If the volume is low + enough, remove the values and flag on any new subscriptions. + + All event subscriptions have three components \ + + 1. Filter - WQL Query for the events we want. EventID = 19 \ + + 1. Consumer - An action to take upon triggering the filter. EventID = 20 \ + + 1. Binding - Registers a filter to a consumer. EventID = 21 \ + + Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. + It may be pertinent to review all 3 to identify the flow of execution. In addition, + EventCode 4104 may assist with any other PowerShell script usage that registered + the subscription.' +search: '`sysmon` EventID=20 | stats count min(_time) as firstTime max(_time) as lastTime + by Computer User Destination | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `detect_wmi_event_subscription_persistence_filter`' +how_to_implement: To successfully implement this search, you need to be ingesting + logs with that provide WMI Event Subscription from your endpoints. If you are using + Sysmon, you must have at least version 6.0.4 of the Sysmon TA and have enabled EventID + 19, 20 and 21. Tune and filter known good to limit the volume. +known_false_positives: It is possible some applications will create a consumer and + may be required to be filtered. For tuning, add any additional LOLBin's for further + depth of coverage. +references: + - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1546.003/T1546.003.md + - https://www.eideon.com/2018-03-02-THL03-WMIBackdoors/ + - https://github.com/trustedsec/SysmonCommunityGuide/blob/master/WMI-events.md + - https://in.security/an-intro-into-abusing-and-identifying-wmi-event-subscriptions-for-persistence/ +tags: + analytic_story: + - Suspicious WMI Use + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1546.003 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Destination + - Computer + - User + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/powershell_creating_thread_mutex.yml b/detections/endpoint/powershell_creating_thread_mutex.yml index 00657f2276..201f863d4a 100644 --- a/detections/endpoint/powershell_creating_thread_mutex.yml +++ b/detections/endpoint/powershell_creating_thread_mutex.yml @@ -4,22 +4,22 @@ version: 1 date: '2021-06-10' author: Teoderick Contreras, Splunk type: batch -datamodel: -- Endpoint -description: This search is to detect suspicious powershell script that using mutex - function. This function is commonly seen in some obfuscated powershell script to - make sure that only one instance of there process is running to a compromise machine - which is also a good indicator to check why powershell script is using it. +datamodel: [] +description: The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using the `mutex` function. This function is commonly seen in some obfuscated PowerShell scripts to + make sure that only one instance of there process is running on a compromise machine. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. search: '`powershell` EventCode=4104 Message = "*Threading.Mutex*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_creating_thread_mutex_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed - registry to monitor this event. +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: powershell developer may used this function in their script for instance checking too. references: -- https://isc.sans.edu/forums/diary/Some+Powershell+Malicious+Code/22988/ + - https://isc.sans.edu/forums/diary/Some+Powershell+Malicious+Code/22988/ + - https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf + - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ tags: analytic_story: - Malicious PowerShell diff --git a/detections/endpoint/powershell_domain_enumeration.yml b/detections/endpoint/powershell_domain_enumeration.yml new file mode 100644 index 0000000000..f5adcd1ffb --- /dev/null +++ b/detections/endpoint/powershell_domain_enumeration.yml @@ -0,0 +1,54 @@ +name: PowerShell Domain Enumeration +id: e1866ce2-ca22-11eb-8e44-acde48001122 +version: 1 +date: '2021-06-10' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies specific PowerShell modules typically used to enumerate + an organizations domain or users. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message IN (*get-netdomaintrust*, *get-netforesttrust*, + *get-addomain*, *get-adgroupmember*, *get-domainuser*) | stats count min(_time) + as firstTime max(_time) as lastTime by OpCode ComputerName User EventCode Message + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_domain_enumeration_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: It is possible there will be false positives, filter as needed. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Reconnaissance + mitre_attack_id: + - T1059.001 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml b/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml new file mode 100644 index 0000000000..e34f44a545 --- /dev/null +++ b/detections/endpoint/powershell_fileless_process_injection_via_getprocaddress.yml @@ -0,0 +1,58 @@ +name: Powershell Fileless Process Injection via GetProcAddress +id: a26d9db4-c883-11eb-9d75-acde48001122 +version: 1 +date: '2021-06-08' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies `GetProcAddress` in the script block. This is not normal + to be used by most PowerShell scripts and is typically unsafe/malicious. Many attack + toolkits use GetProcAddress to obtain code execution. \ + + In use, `$var_gpa = $var_unsafe_native_methods.GetMethod(GetProcAddress` and later + referenced/executed elsewhere. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message=*getprocaddress* | stats count min(_time) + as firstTime max(_time) as lastTime by OpCode ComputerName User EventCode Message + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_fileless_process_injection_via_getprocaddress_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: Limited false positives. Filter as needed. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1055 + - T1059.001 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml b/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml new file mode 100644 index 0000000000..ca8caaed49 --- /dev/null +++ b/detections/endpoint/powershell_fileless_script_contains_base64_encoded_content.yml @@ -0,0 +1,58 @@ +name: Powershell Fileless Script Contains Base64 Encoded Content +id: 8acbc04c-c882-11eb-b060-acde48001122 +version: 1 +date: '2021-06-08' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies `FromBase64String` within the script block. A typical malicious + instance will include additional code. \ + + Command example - `[Byte[]]$var_code = [System.Convert]::FromBase64String(38uqIyMjQ6rG....` + \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message=*frombase64string* | stats count min(_time) + as firstTime max(_time) as lastTime by OpCode ComputerName User EventCode Message + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_fileless_script_contains_base64_encoded_content_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: False positives should be limited. Filter as needed. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + - Privilege Escalation + mitre_attack_id: + - T1027 + - T1059.001 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.yml b/detections/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.yml new file mode 100644 index 0000000000..79ec26c1d0 --- /dev/null +++ b/detections/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.yml @@ -0,0 +1,57 @@ +name: PowerShell Loading DotNET into Memory via System Reflection Assembly +id: 85bc3f30-ca28-11eb-bd21-acde48001122 +version: 1 +date: '2021-06-10' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies the use of PowerShell loading .net assembly via reflection. + This is commonly found in malicious PowerShell usage, including Empire and Cobalt + Strike. In addition, the `load(` value may be modifed by removing `(` and it will + identify more events to review. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message="*[system.reflection.assembly]::load(*" + | stats count min(_time) as firstTime max(_time) as lastTime by OpCode ComputerName + User EventCode Message | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `powershell_loading_dotnet_into_memory_via_system_reflection_assembly_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: False positives will be limited to +references: +- https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly?view=net-5.0 +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1059.001 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/powershell_processing_stream_of_data.yml b/detections/endpoint/powershell_processing_stream_of_data.yml index 8a5d4c1f61..ecc9b839f5 100644 --- a/detections/endpoint/powershell_processing_stream_of_data.yml +++ b/detections/endpoint/powershell_processing_stream_of_data.yml @@ -4,22 +4,22 @@ version: 1 date: '2021-06-10' author: Teoderick Contreras, Splunk type: batch -datamodel: -- Endpoint -description: this search is to detect suspicious powershell that processing compressed - stream data. This technique was seen in obfuscated powershell or powershell with - embedded .net or binary files that are stream flated and will be deflated during - execution. +datamodel: [] +description: The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is processing compressed stream data. This is typically + found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are stream flattened and will be deflated durnig execution. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. search: '`powershell` EventCode=4104 Message = "*IO.Compression.*" OR Message = "*IO.StreamReader*" OR Message = "*]::Decompress*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_processing_stream_of_data_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed - registry to monitor this event. +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: powershell may used this function to process compressed data. references: -- https://medium.com/@ahmedjouini99/deobfuscating-emotets-powershell-payload-e39fb116f7b9 + - https://medium.com/@ahmedjouini99/deobfuscating-emotets-powershell-payload-e39fb116f7b9 + - https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell + - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf + - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ tags: analytic_story: - Malicious PowerShell diff --git a/detections/endpoint/powershell_using_memory_as_backing_store.yml b/detections/endpoint/powershell_using_memory_as_backing_store.yml index 32678956f5..1b3be4a693 100644 --- a/detections/endpoint/powershell_using_memory_as_backing_store.yml +++ b/detections/endpoint/powershell_using_memory_as_backing_store.yml @@ -4,23 +4,24 @@ version: 1 date: '2021-06-10' author: Teoderick Contreras, Splunk type: batch -datamodel: -- Endpoint -description: this search is to detect suspicious powershell script that using memory - stream as new object backstore. This technique is commonly seen in malicious powershell - contain a stream flate data and will be decompressed in memory to run or drop the - actual payload to the compromise machine. +datamodel: [] +description: The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using memory + stream as new object backstore. The malicious PowerShell script will contain stream flate data and will be decompressed in memory to run or drop the + actual payload. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. search: '`powershell` EventCode=4104 Message = "*New-Object IO.MemoryStream*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `powershell_using_memory_as_backing_store_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed - registry to monitor this event. +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: powershell may used this function to store out object into memory. references: -- https://www.carbonblack.com/blog/decoding-malicious-powershell-streams/ + - https://www.carbonblack.com/blog/decoding-malicious-powershell-streams/ + - https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf + - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ tags: analytic_story: - Malicious PowerShell diff --git a/detections/endpoint/process_execution_via_wmi.yml b/detections/endpoint/process_execution_via_wmi.yml index 56fa715b55..427b80a628 100644 --- a/detections/endpoint/process_execution_via_wmi.yml +++ b/detections/endpoint/process_execution_via_wmi.yml @@ -1,16 +1,21 @@ name: Process Execution via WMI id: 24869767-8579-485d-9a4f-d9ddfd8f0cac -version: 3 +version: 4 date: '2020-03-16' -author: Rico Valdez, Splunk +author: Rico Valdez, Michael Haag, Splunk type: batch -datamodel: [] -description: This search looks for processes launched via WMI. -search: '| tstats `security_content_summariesonly` count values(Processes.process) - as process min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes - where Processes.parent_process_name = *WmiPrvSE.exe by Processes.user Processes.dest - Processes.process_name | `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`| - `security_content_ctime(lastTime)`| `process_execution_via_wmi_filter` ' +datamodel: +- Endpoint +description: The following analytic identifies `WmiPrvSE.exe` spawning a process. This typically occurs when a process is instantiated from a local or remote process using `wmic.exe`. + During triage, review parallel processes for suspicious behavior or commands executed. Review the process and command-line spawning from `wmiprvse.exe`. Contain and remediate the endpoint as necessary. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=WmiPrvSE.exe + by Processes.dest Processes.user Processes.parent_process Processes.process_name + Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `process_execution_via_wmi_filter` ' how_to_implement: You must be ingesting endpoint data that tracks process activity, including parent-child relationships from your endpoints to populate the Endpoint data model in the Processes node. The command-line arguments are mapped to the "process" diff --git a/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml b/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml index 843a8a7465..49031821e8 100644 --- a/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml +++ b/detections/endpoint/recon_avproduct_through_pwh_or_wmi.yml @@ -4,21 +4,22 @@ version: 1 date: '2021-06-10' author: Teoderick Contreras, Splunk type: batch -datamodel: -- Endpoint -description: This search is to detect a powershell script that do a recon or checking - to the av product install on the machine. This technique is commonly seen in APT - or malware like ransomware to list all security product and disable it. +datamodel: [] +description: The following analytic identifies suspicious PowerShell script execution via EventCode 4104 performing checks to identify anti-virus products installed on the endpoint. This technique is commonly found in malware + and APT events where the adversary will map all running security applications or services. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. search: '`powershell` EventCode=4104 Message = "*SELECT*" AND (Message = "*AntiVirusProduct*" OR Message = "*AntiSpywareProduct*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `recon_avproduct_through_pwh_or_wmi_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed registry - to monitor this event. +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: network administrator may used this command for checking purposes references: -- https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ + - https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ + - https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf + - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ tags: analytic_story: - Ransomware diff --git a/detections/endpoint/recon_using__wmi_class.yml b/detections/endpoint/recon_using__wmi_class.yml deleted file mode 100644 index 7d46974ce0..0000000000 --- a/detections/endpoint/recon_using__wmi_class.yml +++ /dev/null @@ -1,44 +0,0 @@ -name: Recon Using WMI Class -id: 018c1972-ca07-11eb-9473-acde48001122 -version: 1 -date: '2021-06-10' -author: Teoderick Contreras, Splunk -type: batch -datamodel: -- Endpoint -description: This search is to detect a powershell script that do a recon to the targetted - or compromised machine. This technique is common nowadays to know the running process, - services -search: '`powershell` EventCode=4104 (Message= "*SELECT*" OR Message= "*Get-WmiObject*") - AND (Message= "*Win32_Bios*" OR Message= "*Win32_OperatingSystem*" OR Message= "*Win32_Processor*" - OR Message= "*Win32_ComputerSystem*" OR Message= "*Win32_ComputerSystemProduct*" - OR Message= "*Win32_ShadowCopy*") | stats count min(_time) as firstTime max(_time) - as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` - | `security_content_ctime(lastTime)` | `recon_using__wmi_class_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed registry - to monitor this event. -known_false_positives: network administrator may used this command for checking purposes -references: -- https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ -tags: - analytic_story: - - Malicious PowerShell - kill_chain_phases: - - Reconnaissance - mitre_attack_id: - - T1592 - product: - - Splunk Enterprise - - Splunk Enterprise Security - - Splunk Cloud - required_fields: - - _time - - EventCode - - Message - - ComputerName - - User - security_domain: endpoint - automated_detection_testing: passed - dataset: - - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/pwsh/windows-powershell.log diff --git a/detections/endpoint/recon_using_wmi_class.yml b/detections/endpoint/recon_using_wmi_class.yml new file mode 100644 index 0000000000..3fe8b5eaca --- /dev/null +++ b/detections/endpoint/recon_using_wmi_class.yml @@ -0,0 +1,45 @@ +name: Recon Using WMI Class +id: 018c1972-ca07-11eb-9473-acde48001122 +version: 1 +date: '2021-06-10' +author: Teoderick Contreras, Splunk +type: batch +datamodel: [] +description: The following analytic identifies suspicious PowerShell via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found where the adversary will identify services and system information on the compromised + machine. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. +search: '`powershell` EventCode=4104 (Message= "*SELECT*" OR Message= "*Get-WmiObject*") + AND (Message= "*Win32_Bios*" OR Message= "*Win32_OperatingSystem*" OR Message= "*Win32_Processor*" + OR Message= "*Win32_ComputerSystem*" OR Message= "*Win32_ComputerSystemProduct*" + OR Message= "*Win32_ShadowCopy*") | stats count min(_time) as firstTime max(_time) + as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `recon_using_wmi_class_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: network administrator may used this command for checking purposes +references: + - https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ + - https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. + - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf + - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + kill_chain_phases: + - Reconnaissance + mitre_attack_id: + - T1592 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - Message + - ComputerName + - User + security_domain: endpoint + automated_detection_testing: passed + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/honeypots/pwsh/windows-powershell.log diff --git a/detections/endpoint/remote_wmi_command_attempt.yml b/detections/endpoint/remote_wmi_command_attempt.yml new file mode 100644 index 0000000000..b1a9dfb44c --- /dev/null +++ b/detections/endpoint/remote_wmi_command_attempt.yml @@ -0,0 +1,61 @@ +name: Remote WMI Command Attempt +id: 272df6de-61f1-4784-877c-1fbc3e2d0838 +version: 3 +date: '2018-12-03' +author: Rico Valdez, Michael Haag, Splunk +type: batch +datamodel: +- Endpoint +description: The following analytic identifies usage of `wmic.exe` spawning a local + or remote process, identified by the `node` switch. During triage, review parallel + processes for additional commands executed. Look for any file modifications before + and after `wmic.exe` execution. In addition, identify the remote endpoint and confirm + execution or file modifications. Contain and isolate the endpoint as needed. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name=wmic.exe + Processes.process=*node* by Processes.dest Processes.user Processes.parent_process + Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `remote_wmi_command_attempt_filter`' +how_to_implement: You must be ingesting data that records process activity from your + hosts to populate the Endpoint data model in the Processes node. You must also be + ingesting logs with both the process name and command line from your endpoints. + The command-line arguments are mapped to the "process" field in the Endpoint data + model. Deprecated because duplicate of Remote Process Instantiation via WMI. +known_false_positives: Administrators may use this legitimately to gather info from + remote systems. Filter as needed. +references: +- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1047/T1047.yaml +tags: + analytic_story: + - Suspicious WMI Use + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + kill_chain_phases: + - Actions on Objectives + mitre_attack_id: + - T1047 + nist: + - PR.PT + - PR.AT + - PR.AC + - PR.IP + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Processes.user + - Processes.process_name + - Processes.parent_process_name + - Processes.dest + - Processes.parent_process + - Processes.parent_process_id + - Processes.process_id + security_domain: endpoint + automated_detection_testing: passed + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log diff --git a/detections/endpoint/script_execution_via_wmi.yml b/detections/endpoint/script_execution_via_wmi.yml index 572bca9e10..6d78200194 100644 --- a/detections/endpoint/script_execution_via_wmi.yml +++ b/detections/endpoint/script_execution_via_wmi.yml @@ -1,23 +1,28 @@ name: Script Execution via WMI id: aa73f80d-d728-4077-b226-81ea0c8be589 -version: 3 +version: 4 date: '2020-03-16' -author: Rico Valdez, Splunk +author: Rico Valdez, Michael Haag, Splunk type: batch -datamodel: [] -description: This search looks for scripts launched via WMI. -search: '| tstats `security_content_summariesonly` count values(Processes.process) - as process min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes - where Processes.process_name = "scrcons.exe" by Processes.user Processes.dest Processes.process_name | - `drop_dm_object_name("Processes")` | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| - `script_execution_via_wmi_filter` ' +datamodel: +- Endpoint +description: This search looks for scripts launched via WMI. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) + as lastTime from datamodel=Endpoint.Processes where Processes.process_name=scrcons.exe + by Processes.dest Processes.user Processes.parent_process Processes.process_name + Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `script_execution_via_wmi_filter` ' how_to_implement: You must be ingesting endpoint data that tracks process activity, including parent-child relationships from your endpoints to populate the Endpoint data model in the Processes node. The command-line arguments are mapped to the "process" field in the Endpoint data model. known_false_positives: Although unlikely, administrators may use wmi to launch scripts - for legitimate purposes. -references: [] + for legitimate purposes. Filter as needed. +references: + - https://redcanary.com/blog/child-processes/ tags: analytic_story: - Suspicious WMI Use diff --git a/detections/endpoint/unloading_amsi_via_reflection.yml b/detections/endpoint/unloading_amsi_via_reflection.yml new file mode 100644 index 0000000000..521e54b285 --- /dev/null +++ b/detections/endpoint/unloading_amsi_via_reflection.yml @@ -0,0 +1,57 @@ +name: Unloading AMSI via Reflection +id: a21e3484-c94d-11eb-b55b-acde48001122 +version: 1 +date: '2021-06-09' +author: Michael Haag, Splunk +type: batch +datamodel: [] +description: 'The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) + to identify suspicious PowerShell execution. Script Block Logging captures the command + sent to PowerShell, the full command to be executed. Upon enabling, logs will output + to Windows event logs. Dependent upon volume, enable no critical endpoints or all. + \ + + This analytic identifies the behavior of AMSI being tampered with. Implemented natively + in many frameworks, the command will look similar to `SEtValuE($Null,(New-OBJEct + COLlECtionS.GenerIC.HAshSEt[StrINg]))}$ReF=[ReF].AsSeMbLY.GeTTyPe("System.Management.Automation.Amsi"+"Utils")` + taken from Powershell-Empire. \ + + During triage, review parallel processes using an EDR product or 4688 events. It + will be important to understand the timeline of events around this activity. Review + the entire logged PowerShell script block.' +search: '`powershell` EventCode=4104 Message=*system.management.automation.amsi* | + stats count min(_time) as firstTime max(_time) as lastTime by OpCode ComputerName + User EventCode Message | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `unloading_amsi_via_reflection_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: Potential for some third party applications to disable AMSI + upon invocation. Filter as needed. +references: +- https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +- https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 +- https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf +- https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/ +tags: + analytic_story: + - Malicious PowerShell + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + kill_chain_phases: + - Exploitation + mitre_attack_id: + - T1562 + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - Message + - OpCode + - ComputerName + - User + - EventCode + security_domain: endpoint + automated_detection_testing: passed diff --git a/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml b/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml index 02ea4b7c39..4c509986d2 100644 --- a/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml +++ b/detections/endpoint/wmi_permanent_event_subscription___sysmon.yml @@ -1,20 +1,36 @@ name: WMI Permanent Event Subscription - Sysmon id: ad05aae6-3b2a-4f73-af97-57bd26cee3b9 -version: 2 +version: 3 date: '2020-12-08' -author: Rico Valdez, Splunk +author: Rico Valdez, Michael Haag, Splunk type: batch datamodel: [] -description: This search looks for the creation of WMI permanent event subscriptions. +description: This analytic looks for the creation of WMI permanent event subscriptions. + The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions. + + All event subscriptions have three components \ + + 1. Filter - WQL Query for the events we want. EventID = 19 \ + + 1. Consumer - An action to take upon triggering the filter. EventID = 20 \ + + 1. Binding - Registers a filter to a consumer. EventID = 21 \ + + Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription. + search: '`sysmon` EventCode=21 | rename host as dest | table _time, dest, user, Operation, EventType, Query, Consumer, Filter | `wmi_permanent_event_subscription___sysmon_filter`' how_to_implement: To successfully implement this search, you must be collecting Sysmon data using Sysmon version 6.1 or greater and have Sysmon configured to generate - alerts for WMI activity. In addition, you must have at least version 6.0.4 of the + alerts for WMI activity (eventID= 19, 20, 21). In addition, you must have at least version 6.0.4 of the Sysmon TA installed to properly parse the fields. known_false_positives: Although unlikely, administrators may use event subscriptions for legitimate purposes. -references: [] +references: + - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1546.003/T1546.003.md + - https://www.eideon.com/2018-03-02-THL03-WMIBackdoors/ + - https://github.com/trustedsec/SysmonCommunityGuide/blob/master/WMI-events.md + - https://in.security/an-intro-into-abusing-and-identifying-wmi-event-subscriptions-for-persistence/ tags: analytic_story: - Suspicious WMI Use diff --git a/detections/endpoint/wmi_recon_running_process_or_services.yml b/detections/endpoint/wmi_recon_running_process_or_services.yml index 6833b18e0e..70a5842212 100644 --- a/detections/endpoint/wmi_recon_running_process_or_services.yml +++ b/detections/endpoint/wmi_recon_running_process_or_services.yml @@ -4,22 +4,22 @@ version: 1 date: '2021-06-14' author: Teoderick Contreras, Splunk type: batch -datamodel: -- Endpoint -description: This seearch is to detect a suspicious powershell/wmi query to recon - running process and running services. This technique is commonly seen in malware - and apt attack to mapped all running security application or services on the compromised +datamodel: [] +description: The following analytic identifies suspicious PowerShell script execution via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found in malware + and APT events where the adversary will map all running security applications or services on the compromised machine. + During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts. search: '`powershell` EventCode=4104 Message= "*SELECT*" AND (Message="*Win32_Process*" OR Message="*Win32_Service*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode Message ComputerName User | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `wmi_recon_running_process_or_services_filter`' -how_to_implement: To successfully implement this search, you need to be ingesting - logs with the powershell logs from your endpoints. make sure you enable needed registry - to monitor this event. +how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: network administrator may used this command for checking purposes references: -- https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ + - https://news.sophos.com/en-us/2020/05/12/maze-ransomware-1-year-counting/ + - https://www.eideon.com/2018-03-02-THL03-WMIBackdoors/ + - https://github.com/trustedsec/SysmonCommunityGuide/blob/master/WMI-events.md + - https://in.security/an-intro-into-abusing-and-identifying-wmi-event-subscriptions-for-persistence/ tags: analytic_story: - Malicious PowerShell diff --git a/stories/malicious_powershell.yml b/stories/malicious_powershell.yml index f84830edcf..c1bcf4a50e 100644 --- a/stories/malicious_powershell.yml +++ b/stories/malicious_powershell.yml @@ -1,6 +1,6 @@ name: Malicious PowerShell id: 2c8ff66e-0b57-42af-8ad7-912438a403fc -version: 4 +version: 5 date: '2017-08-23' author: David Dorsey, Splunk type: batch @@ -14,25 +14,26 @@ narrative: 'The searches in this Analytic Story monitor for parameters often use events. These factors may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. Likewise, it is important to determine whether the issue is restricted to a single - user/system or is broader in scope.\ + user/system or is broader in scope. \ The following factors may assist you in determining whether the event is malicious: \ - 1. Country of origin\ + 1. Country of origin \ - 1. Responsible party\ + 1. Responsible party \ - 1. Fully qualified domain names associated with the external IP address\ + 1. Fully qualified domain names associated with the external IP address \ - 1. Registration of fully qualified domain names associated with external IP addressDetermining - whether it is a dynamic domain frequently visited by others and/or how third parties + 1. Registration of fully qualified domain names associated with external IP address \ + + Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you answer some questions surrounding the attacker and details related to the external system. In addition, there are various sources--such as VirusTotal— that can provide some reputation information on the IP address or domain name, which can assist in determining whether the event is malicious. Finally, determining whether there are other events associated with the IP address - may help connect data points or show other events that should be brought into scope.\ + may help connect data points or show other events that should be brought into scope. \ Gathering data on the system of interest can sometimes help you quickly determine whether something suspicious is happening. Some of these items include finding out @@ -41,7 +42,7 @@ narrative: 'The searches in this Analytic Story monitor for parameters often use are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been - targeted.\ + targeted. \ Often, a simple inspection of the process name and path can tell you if the system has been compromised. For example, if `svchost.exe` is found running from a location @@ -49,19 +50,21 @@ narrative: 'The searches in this Analytic Story monitor for parameters often use in plain sight when cursorily reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, that could be indicative of activity initiated via a compromised website - a user visited.\ + a user visited. \ It can also be very helpful to examine various behaviors of the process of interest or the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might be worth further scrutiny. If a process is suspect, a review of the network connections made in and around the time of the event and/or - whether the process spawned any child processes could be helpful, as well.\ + whether the process spawned any child processes could be helpful, as well. \ In the event a system is suspected of having been compromised via a malicious website, we suggest reviewing the browsing activity from that system around the time of the event. If categories are given for the URLs visited, that can help you zero in on - possible malicious sites.' + possible malicious sites. \ + + Most recently we have added new content related to PowerShell Script Block logging, Windows EventCode 4104. Script block logging presents the deobfuscated and raw script executed on an endpoint. The analytics produced were tested against commonly used attack frameworks - PowerShell-Empire, Cobalt Strike and Covenant. In addition, we sampled publicly available samples that utilize PowerShell and validated coverage. The analytics are here to identify suspicious usage, cmdlets, or script values. 4104 events are enabled via the Windows registry and may generate a large volume of data if enabled globally. Enabling on critical systems or a limited set may be best. During triage of 4104 events, review parallel processes for other processes and command executed. Identify any file modifications and network communication and review accordingly. Fortunately, we get the full script to determine the level of threat identified.' references: - https://blogs.mcafee.com/mcafee-labs/malware-employs-powershell-to-infect-systems/ - https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/ diff --git a/tests/endpoint/detect_empire_with_powershell_script_block_logging.test.yml b/tests/endpoint/detect_empire_with_powershell_script_block_logging.test.yml new file mode 100644 index 0000000000..9f6c847c9b --- /dev/null +++ b/tests/endpoint/detect_empire_with_powershell_script_block_logging.test.yml @@ -0,0 +1,12 @@ +name: Detect Empire with PowerShell Script Block Logging Unit Test +tests: +- name: Detect Empire with PowerShell Script Block Logging + file: endpoint/detect_empire_with_powershell_script_block_logging.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/detect_mimikatz_with_powershell_script_block_logging.test.yml b/tests/endpoint/detect_mimikatz_with_powershell_script_block_logging.test.yml new file mode 100644 index 0000000000..f03fd4d85e --- /dev/null +++ b/tests/endpoint/detect_mimikatz_with_powershell_script_block_logging.test.yml @@ -0,0 +1,12 @@ +name: Detect Mimikatz With PowerShell Script Block Logging Unit Test +tests: +- name: Detect Mimikatz With PowerShell Script Block Logging + file: endpoint/detect_mimikatz_with_powershell_script_block_logging.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/detect_wmi_event_subscription_persistence.test.yml b/tests/endpoint/detect_wmi_event_subscription_persistence.test.yml new file mode 100644 index 0000000000..679df91653 --- /dev/null +++ b/tests/endpoint/detect_wmi_event_subscription_persistence.test.yml @@ -0,0 +1,12 @@ +name: Detect WMI Event Subscription Persistence Unit Test +tests: +- name: Detect WMI Event Subscription Persistence + file: endpoint/detect_wmi_event_subscription_persistence.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-sysmon.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.003/atomic_red_team/windows-sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog \ No newline at end of file diff --git a/tests/endpoint/powershell_domain_enumeration.test.yml b/tests/endpoint/powershell_domain_enumeration.test.yml new file mode 100644 index 0000000000..c90a4de8f2 --- /dev/null +++ b/tests/endpoint/powershell_domain_enumeration.test.yml @@ -0,0 +1,12 @@ +name: PowerShell Domain Enumeration Unit Test +tests: +- name: PowerShell Domain Enumeration + file: endpoint/powershell_domain_enumeration.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/powershell_fileless_process_injection_via_getprocaddress.test.yml b/tests/endpoint/powershell_fileless_process_injection_via_getprocaddress.test.yml new file mode 100644 index 0000000000..4622c2090a --- /dev/null +++ b/tests/endpoint/powershell_fileless_process_injection_via_getprocaddress.test.yml @@ -0,0 +1,12 @@ +name: Powershell Fileless Process Injection via GetProcAddress Unit Test +tests: +- name: Powershell Fileless Process Injection via GetProcAddress + file: endpoint/powershell_fileless_process_injection_via_getprocaddress.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/powershell_fileless_script_contains_base64_encoded_content.test.yml b/tests/endpoint/powershell_fileless_script_contains_base64_encoded_content.test.yml new file mode 100644 index 0000000000..a407149eda --- /dev/null +++ b/tests/endpoint/powershell_fileless_script_contains_base64_encoded_content.test.yml @@ -0,0 +1,12 @@ +name: Powershell Fileless Script Contains Base64 Encoded Content Unit Test +tests: +- name: Powershell Fileless Script Contains Base64 Encoded Content + file: endpoint/powershell_fileless_script_contains_base64_encoded_content.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.test.yml b/tests/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.test.yml new file mode 100644 index 0000000000..9e922a87d7 --- /dev/null +++ b/tests/endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.test.yml @@ -0,0 +1,12 @@ +name: PowerShell Loading DotNET into Memory via System Reflection Assembly Unit Test +tests: +- name: PowerShell Loading DotNET into Memory via System Reflection Assembly + file: endpoint/powershell_loading_dotnet_into_memory_via_system_reflection_assembly.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file diff --git a/tests/endpoint/recon_using__wmi_class.test.yml b/tests/endpoint/recon_using_wmi_class.test.yml similarity index 84% rename from tests/endpoint/recon_using__wmi_class.test.yml rename to tests/endpoint/recon_using_wmi_class.test.yml index 7d7aece511..336de7244c 100644 --- a/tests/endpoint/recon_using__wmi_class.test.yml +++ b/tests/endpoint/recon_using_wmi_class.test.yml @@ -1,7 +1,7 @@ name: Recon Using WMI Class Unit Test tests: -- name: Recon Using WMI Class - file: endpoint/recon_using__wmi_class.yml +- name: Recon Using WMI Class + file: endpoint/recon_using_wmi_class.yml pass_condition: '| stats count | where count > 0' earliest_time: '-24h' latest_time: 'now' diff --git a/tests/endpoint/remote_wmi_command_attempt.test.yml b/tests/endpoint/remote_wmi_command_attempt.test.yml new file mode 100644 index 0000000000..8f4134e786 --- /dev/null +++ b/tests/endpoint/remote_wmi_command_attempt.test.yml @@ -0,0 +1,12 @@ +name: Remote WMI Command Attempt Unit Test +tests: +- name: Remote WMI Command Attempt + file: endpoint/remote_wmi_command_attempt.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-sysmon.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1047/atomic_red_team/windows-sysmon.log + source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational + sourcetype: xmlwineventlog \ No newline at end of file diff --git a/tests/endpoint/unloading_amsi_via_reflection.test.yml b/tests/endpoint/unloading_amsi_via_reflection.test.yml new file mode 100644 index 0000000000..60b06d3cd8 --- /dev/null +++ b/tests/endpoint/unloading_amsi_via_reflection.test.yml @@ -0,0 +1,12 @@ +name: Unloading AMSI via Reflection Unit Test +tests: +- name: Unloading AMSI via Reflection + file: endpoint/unloading_amsi_via_reflection.yml + pass_condition: '| stats count | where count > 0' + earliest_time: '-24h' + latest_time: 'now' + attack_data: + - file_name: windows-powershell.log + data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/windows-powershell.log + source: WinEventLog:Microsoft-Windows-PowerShell/Operational + sourcetype: WinEventLog \ No newline at end of file