Branch was auto-updated.

detections/deprecated/remote_wmi_command_attempt.yml

@@ -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

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

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

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

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

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

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

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

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

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

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

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"

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

detections/endpoint/recon_using__wmi_class.yml

@@ -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

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

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

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

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

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

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

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/

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

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

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

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

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

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

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

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'

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

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