Branch was auto-updated.

automated_detection_testing/ci/detection_testing_batch/requirements.txt

@@ -1,4 +1,4 @@
-ansible==2.9.20
+ansible==4.2.0
 ansible-runner==1.4.4
 attackcti==0.3.4.3
 boto3==1.11.0

detections/endpoint/active_setup_registry_autostart.yml

@@ -0,0 +1,70 @@
+name: Active Setup Registry Autostart
+id: f64579c0-203f-11ec-abcc-acde48001122
+version: 1
+date: '2021-09-28'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious modification of the active setup
+  registry for persistence and privilege escalation. This technique was seen in several
+  malware (poisonIvy), adware and APT to gain persistence to the compromised machine
+  upon boot up. This TTP is a good indicator to further check the process id that
+  do the modification since modification of this registry is not commonly done. check
+  the legitimacy of the file and process involve in this rules to check if it is a
+  valid setup installer that creating or modifying this registry.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_value_name
+  = "StubPath" Registry.registry_key_name = "*\\SOFTWARE\\Microsoft\\Active Setup\\Installed
+  Components*" by Registry.dest  Registry.user Registry.registry_path Registry.registry_key_name
+  Registry.registry_value_name | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)`
+  | `drop_dm_object_name(Registry)` | `active_setup_registry_autostart_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting
+  data that records registry activity from your hosts to populate the endpoint data
+  model in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: Active setup installer may add or modify this registry.
+references:
+- https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Backdoor%3aWin32%2fPoisonivy.E
+- https://attack.mitre.org/techniques/T1547/014/
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1547.014/active_setup_stubpath/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1547.014
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  security_domain: endpoint
+  impact: 80
+  confidence: 80
+  risk_score: 64
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/change_default_file_association.yml

@@ -0,0 +1,67 @@
+name: Change Default File Association
+id: 462d17d8-1f71-11ec-ad07-acde48001122
+version: 1
+date: '2021-09-27'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is developed to detect suspicious registry modification
+  to change the default file association of windows to malicious payload. This techninique
+  was seen in some APT where it modify the default process to run file association,
+  like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other
+  payload that will load malicious command to the compromised host.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path
+  ="*\\shell\\open\\command\\*" Registry.registry_path = "*HKCR\\*" by Registry.dest  Registry.user
+  Registry.registry_path Registry.registry_key_name Registry.registry_value_name |
+  `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)`
+  | `change_default_file_association_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://dmcxblue.gitbook.io/red-team-notes-2-0/red-team-techniques/privilege-escalation/untitled-3/accessibility-features
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.001/txtfile_reg/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1546.001
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/disable_security_logs_using_minint_registry.yml

@@ -0,0 +1,65 @@
+name: Disable Security Logs Using MiniNt Registry
+id: 39ebdc68-25b9-11ec-aec7-acde48001122
+version: 1
+date: '2021-10-05'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious registry modification to disable
+  security audit logs. This technique was shared by a researcher to disable Security
+  logs of windows by adding this registry. The Windows will think it is WinPE and
+  will not log any event to the Security Log
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\Control\\MiniNt\\*"
+  by Registry.dest Registry.user Registry.registry_value_name Registry.registry_key_name
+  Registry.registry_path Registry.registry_value_data | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `disable_security_logs_using_minint_registry_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting
+  data that records registry activity from your hosts to populate the endpoint data
+  model in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: Unknown.
+references:
+- https://twitter.com/0gtweet/status/1182516740955226112
+tags:
+  analytic_story:
+  - Windows Defense Evasion Tactics
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/minint_reg/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1112
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_value_name
+  - Registry.registry_key_name
+  - Registry.registry_path
+  - Registry.registry_value_data
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - Source:Endpoint
+  - Stage:Defense Evasion
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/disable_uac_remote_restriction.yml

@@ -0,0 +1,69 @@
+name: Disable UAC Remote Restriction
+id: 9928b732-210e-11ec-b65e-acde48001122
+version: 1
+date: '2021-09-29'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious modification of registry to disable
+  UAC remote restriction. This technique was well documented in Microsoft page where
+  attacker may modify this registry value to bypassed UAC feature of windows host.
+  This is a good indicator that some tries to bypassed UAC to suspicious process or
+  gain privilege escalation.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path
+  ="*\\CurrentVersion\\Policies\\System*" Registry.registry_value_name="LocalAccountTokenFilterPolicy"
+  Registry.registry_value_data="0x00000001" by Registry.dest  Registry.user Registry.registry_path
+  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
+  | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)`
+  | `disable_uac_remote_restriction_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: admin may set this policy for non-critical machine.
+references:
+- https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction
+tags:
+  analytic_story:
+  - Windows Defense Evasion Tactics
+  - Suspicious Windows Registry Activities
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/LocalAccountTokenFilterPolicy/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1548.002
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  - Registry.registry_value_data
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/enable_wdigest_uselogoncredential_registry.yml

@@ -0,0 +1,68 @@
+name: Enable WDigest UseLogonCredential Registry
+id: 0c7d8ffe-25b1-11ec-9f39-acde48001122
+version: 1
+date: '2021-10-05'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious registry modification to enable
+  plain text credential feature of windows. This technique was used by several malware
+  and also by mimikatz to be able to dumpe the a plain text credential to the compromised
+  or target host. This TTP is really a good indicator that someone wants to dump the
+  crendential of the host so it must be a good pivot for credential dumping techniques.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path="*\\System\\CurrentControlSet\\Control\\SecurityProviders\\WDigest\\*"
+  Registry.registry_value_name = "UseLogonCredential" Registry.registry_value_data
+  = 0x00000001 by Registry.dest Registry.user Registry.registry_value_name Registry.registry_key_name
+  Registry.registry_path Registry.registry_value_data | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `enable_wdigest_uselogoncredential_registry_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting
+  data that records registry activity from your hosts to populate the endpoint data
+  model in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://www.csoonline.com/article/3438824/how-to-detect-and-halt-credential-theft-via-windows-wdigest.html
+tags:
+  analytic_story:
+  - Credential Dumping
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003/wdigest_enable/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1112
+  - T1003
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_value_name
+  - Registry.registry_key_name
+  - Registry.registry_path
+  - Registry.registry_value_data
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - Source:Endpoint
+  - Stage:Credential Access
+  message: wdigest registry $registry_path$ was modified in $dest$
+  observable:
+  - name: user
+    type: User
+    role:
+    - Victim
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/etw_registry_disabled.yml

@@ -0,0 +1,67 @@
+name: ETW Registry Disabled
+id: 8ed523ac-276b-11ec-ac39-acde48001122
+version: 1
+date: '2021-10-07'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a registry modification to disable ETW feature
+  of windows. This technique is to evade EDR appliance to evade detections and hide
+  its execution from audit logs.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where (Registry.registry_path="*\\SOFTWARE\\Microsoft\\.NETFramework*")
+  Registry.registry_value_name = ETWEnabled Registry.registry_value_data=0x00000000
+  by Registry.dest Registry.user Registry.registry_path Registry.registry_key_name
+  Registry.registry_value_name Registry.registry_value_data | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `etw_registry_disabled_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting
+  data that records registry activity from your hosts to populate the endpoint data
+  model in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://gist.github.com/Cyb3rWard0g/a4a115fd3ab518a0e593525a379adee3
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127/etw_disable/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1562.006
+  - T1127
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  - Registry.registry_value_data
+  security_domain: endpoint
+  impact: 90
+  confidence: 100
+  risk_score: 90
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/logon_script_event_trigger_execution.yml

@@ -0,0 +1,65 @@
+name: Logon Script Event Trigger Execution
+id: 4c38c264-1f74-11ec-b5fa-acde48001122
+version: 1
+date: '2021-09-27'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This search is to detect a suspicious modification of registry entry
+  to persist and gain privilege escalation upon booting up of compromised host. This
+  technique was seen in several APT and malware where it modify UserInitMprLogonScript
+  registry entry to its malicious payload to be executed upon boot up of the machine.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path
+  IN ("*\\Environment\\UserInitMprLogonScript") by Registry.dest  Registry.user Registry.registry_path
+  Registry.registry_key_name Registry.registry_value_name | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` | `logon_script_event_trigger_execution_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://attack.mitre.org/techniques/T1037/001
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1037.001/logonscript_reg/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1037.001
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/msbuild_suspicious_spawned_by_script_process.yml

@@ -0,0 +1,65 @@
+name: MSBuild Suspicious Spawned By Script Process
+id: 213b3148-24ea-11ec-93a2-acde48001122
+version: 1
+date: '2021-10-04'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious child process of MSBuild 
+  spawned by Windows Script Host - cscript or wscript. 
+  This behavior or event are commonly seen and used by malware or adversaries
+  to execute malicious msbuild process using malicious script in the compromised host.
+  During triage, review parallel processes and identify any file modifications. MSBuild
+  may load a script from the same path without having command-line arguments.
+search: '| tstats `security_content_summariesonly` count values(Processes.process_name)
+  as process_name values(Processes.process) as process min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name
+  IN ("wscript.exe", "cscript.exe") AND `process_msbuild` by Processes.dest Processes.parent_process
+  Processes.parent_process_name Processes.process_name Processes.original_file_name
+  Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `msbuild_suspicious_spawned_by_script_process_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: False positives should be limited as developers do not spawn MSBuild via a WSH.
+references:
+- https://app.any.run/tasks/dc93ee63-050c-4ff8-b07e-8277af9ab939/#
+tags:
+  analytic_story:
+  - Trusted Developer Utilities Proxy Execution MSBuild
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/regsvr32_silent/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1127.001
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.parent_process
+  - Processes.parent_process_name
+  - Processes.process_name
+  - Processes.original_file_name
+  - Processes.user
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Stage:Execution
+  - Stage:Defense Evasion
+  message: Msbuild.exe process spawned by $parent_process_name$ on $dest$ executed
+    by $user$
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: User
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/registry_keys_used_for_persistence.yml

@@ -11,7 +11,8 @@ description: The search looks for modifications to registry keys that can be use
 search: '| tstats `security_content_summariesonly` count values(Registry.registry_key_name)
   as registry_key_name values(Registry.registry_path) as registry_path min(_time)
   as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry where (Registry.registry_path=*\\currentversion\\run*
-  OR Registry.registry_path=*\\currentVersion\\Windows\\Appinit_Dlls* OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Shell*
+  OR Registry.registry_path=*\\currentVersion\\Windows\\Appinit_Dlls* OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Shell* 
+  OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Notify*
   OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Userinit* OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\VmApplet*
   OR Registry.registry_path=*\\currentversion\\policies\\explorer\\run* OR Registry.registry_path=*\\currentversion\\runservices*
   OR Registry.registry_path=HKLM\\SOFTWARE\\Microsoft\\Netsh\\* OR (Registry.registry_path="*Microsoft\\Windows

detections/endpoint/regsvr32_silent_param_dll_loading.yml

@@ -0,0 +1,73 @@
+name: Regsvr32 Silent Param Dll Loading
+id: f421c250-24e7-11ec-bc43-acde48001122
+version: 1
+date: '2021-10-04'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a loading of dll using regsvr32 application
+  with silent parameter and dllinstall execution. This technique was seen in several
+  RAT malware like remcos, njrat and APT's to load their malicious dll in the compromised
+  machine. This TTP may executed by normal 3rd party application so it is better to
+  pivot the parent process, parent commandline and commandline of the file that execute
+  this regsvr32.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where Processes.process_name = regsvr32.exe
+  Processes.process="*/i*" Processes.process="*/s*" by Processes.dest Processes.parent_process
+  Processes.process Processes.parent_process_name Processes.process_name Processes.original_file_name
+  Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `regsvr32_silent_param_dll_loading_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the process name, parent process, and command-line executions from your
+  endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the
+  Sysmon TA.
+known_false_positives: Other third part application may used this parameter but not
+  so common in base windows environment.
+references:
+- https://app.any.run/tasks/dc93ee63-050c-4ff8-b07e-8277af9ab939/#
+- https://attack.mitre.org/techniques/T1218/010/
+tags:
+  analytic_story:
+  - Suspicious Regsvr32 Activity
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1218.010
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name
+  - Processes.parent_process
+  - Processes.original_file_name
+  - Processes.process_name
+  - Processes.process
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 60
+  confidence: 60
+  risk_score: 36
+  context:
+  - Source:Endpoint
+  - Stage:Defense Evasion
+  message: regsvr32 process with $process$ commandline in $dest$
+  observable:
+  - name: user
+    type: User
+    role:
+    - Victim
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/rundll32_shimcache_flush.yml

@@ -0,0 +1,67 @@
+name: Rundll32 Shimcache Flush
+id: a913718a-25b6-11ec-96d3-acde48001122
+version: 1
+date: '2021-10-05'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious rundll32 commandline to clear
+  shim cache. This technique is a anti-forensic technique to clear the cache taht
+  are one important artifacts in terms of digital forensic during attacks or incident.
+  This TTP is a good indicator that someone tries to evade some tools and clear foothold
+  on the machine.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where  `process_rundll32` AND Processes.process
+  = "*apphelp.dll,ShimFlushCache*" by Processes.dest Processes.user Processes.parent_process_name
+  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.original_file_name
+  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `rundll32_shimcache_flush_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: unknown
+references:
+- https://blueteamops.medium.com/shimcache-flush-89daff28d15e
+tags:
+  analytic_story:
+  - Unusual Processes
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/shimcache_flush/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1112
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - Stage:Execution
+  - Stage:Defense Evasion
+  message: rundll32 process execute $process$ to clear shim cache in $dest$
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: User
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/screensaver_event_trigger_execution.yml

@@ -0,0 +1,68 @@
+name: Screensaver Event Trigger Execution
+id: 58cea3ec-1f6d-11ec-8560-acde48001122
+version: 1
+date: '2021-09-27'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is developed to detect possible event trigger execution
+  through screensaver registry entry modification for persistence or privilege escalation.
+  This technique was seen in several APT and malware where they put the malicious
+  payload path to the SCRNSAVE.EXE registry key to redirect the execution to their
+  malicious payload path. This TTP is a good indicator that some attacker may modify
+  this entry for their persistence and privilege escalation.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where (Registry.registry_path="*\\Control
+  Panel\\Desktop\\SCRNSAVE.EXE*") by Registry.dest Registry.user Registry.registry_path
+  Registry.registry_key_name Registry.registry_value_name | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)` | `screensaver_event_trigger_execution_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://attack.mitre.org/techniques/T1546/002/
+- https://dmcxblue.gitbook.io/red-team-notes-2-0/red-team-techniques/privilege-escalation/untitled-3/screensaver
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.002/scrnsave_reg/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1546.002
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  security_domain: endpoint
+  impact: 80
+  confidence: 90
+  risk_score: 72
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/sdelete_application_execution.yml

@@ -0,0 +1,70 @@
+name: Sdelete Application Execution
+id: 31702fc0-2682-11ec-85c3-acde48001122
+version: 1
+date: '2021-10-06'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect the execution of sdelete.exe application sysinternal
+  tools. This tool is one of the most use tool of malware and adversaries to remove
+  or clear their tracks and artifact in the targetted host. This tool is designed
+  to delete securely a file in file system that remove the forensic evidence on the
+  machine. A good TTP query to check why user execute this application which is not
+  a common practice.
+search: '| tstats `security_content_summariesonly` values(Processes.process) as process
+  values(Processes.parent_process) as parent_process values(Processes.process_id)
+  as process_id count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes
+  where `process_sdelete` by  Processes.process_name Processes.original_file_name
+  Processes.dest Processes.user Processes.parent_process_name Processes.parent_process
+  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `sdelete_application_execution_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: user may execute and use this application
+references:
+- https://app.any.run/tasks/956f50be-2c13-465a-ac00-6224c14c5f89/
+tags:
+  analytic_story:
+  - Masquerading - Rename System Utilities
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/sdelete/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1485
+  - T1070.004
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Execution
+  message: sdelete process $process_name$ executed in $dest$
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: user
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/suspicious_copy_on_system32.yml

@@ -0,0 +1,68 @@
+name: Suspicious Copy on System32
+id: ce633e56-25b2-11ec-9e76-acde48001122
+version: 1
+date: '2021-10-05'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious copy of file from systemroot
+  folder of the windows OS. This technique is commonly used by APT or other malware
+  as part of execution (LOLBIN) to run its malicious code using the available legitimate
+  tool in OS. this type of event may seen or may execute of normal user in some instance
+  but this is really a anomaly that needs to be check within the network.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name
+  IN("cmd.exe", "powershell*","pwsh.exe", "sqlps.exe", "sqltoolsps.exe", "powershell_ise.exe") AND `process_copy` AND Processes.process IN("*\\Windows\\System32\*",
+  "*\\Windows\\SysWow64\\*") AND Processes.process = "*copy*" by Processes.dest Processes.user
+  Processes.parent_process_name 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)`| `suspicious_copy_on_system32_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: every user may do this event but very un-ussual.
+references:
+- https://www.hybrid-analysis.com/sample/8da5b75b6380a41eee3a399c43dfe0d99eeefaa1fd21027a07b1ecaa4cd96fdd?environmentId=120
+tags:
+  analytic_story:
+  - Unusual Processes
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/copy_sysmon/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1036.003
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 90
+  risk_score: 63
+  context:
+  - Stage:Execution
+  - Stage:Defense Evasion
+  message: execution of copy exe to copy file from $process$ in $dest$
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: User
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/time_provider_persistence_registry.yml

@@ -0,0 +1,68 @@
+name: Time Provider Persistence Registry
+id: 5ba382c4-2105-11ec-8d8f-acde48001122
+version: 1
+date: '2021-09-29'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspiciouos modification of time provider
+  registry for persistence and autostart. This technique can allow the attacker to
+  persist on the compromised host and autostart as soon as the machine boot up. This
+  TTP can be a good indicator of suspicious behavior since this registry is not commonly
+  modified by normal user or even an admin.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path
+  ="*\\CurrentControlSet\\Services\\W32Time\\TimeProviders*" by Registry.dest  Registry.user
+  Registry.registry_path Registry.registry_key_name Registry.registry_value_name |
+  `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `drop_dm_object_name(Registry)`
+  | `time_provider_persistence_registry_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: unknown
+references:
+- https://pentestlab.blog/2019/10/22/persistence-time-providers/
+- https://attack.mitre.org/techniques/T1547/003/
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.003/timeprovider_reg/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1547.003
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest
+  - Registry.user
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  risk_score: 80
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/vbscript_execution_using_wscript_app.yml

@@ -0,0 +1,69 @@
+name: Vbscript Execution Using Wscript App
+id: 35159940-228f-11ec-8a49-acde48001122
+version: 1
+date: '2021-10-01'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious wscript commandline to execute
+  vbscript. This technique was seen in several malware to execute malicious vbs file
+  using wscript application. commonly vbs script is associated to cscript process
+  and this can be a technique to evade process parent child detections or even some
+  av script emulation system.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where (Processes.parent_process_name
+  = "wscript.exe" AND Processes.parent_process = "*//e:vbscript*") OR (Processes.process_name
+  = "wscript.exe" AND Processes.process = "*//e:vbscript*") by Processes.parent_process_name
+  Processes.parent_process Processes.process_name Processes.process_id Processes.process
+  Processes.dest Processes.user | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `vbscript_execution_using_wscript_app_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: unknown
+references:
+- https://www.joesandbox.com/analysis/369332/0/html
+tags:
+  analytic_story:
+  - FIN7
+  - Remcos
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1059.005
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Execution
+  message: Process name $process_name$ with commandline $process$ to execute vbsscript
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: user
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/verclsid_clsid_execution.yml

@@ -0,0 +1,72 @@
+name: Verclsid CLSID Execution
+id: 61e9a56a-20fa-11ec-8ba3-acde48001122
+version: 1
+date: '2021-09-29'
+author: Teoderick Contreras, Splunk
+type: Hunting
+datamodel:
+- Endpoint
+description: This analytic is to detect a possible abuse of verclsid to execute malicious
+  file through generate CLSID. This process is a normal application of windows to
+  verify the CLSID COM object before it is instantiated by Windows Explorer. This
+  hunting query can be a good pivot point to analyze what is he CLSID or COM object
+  pointing too to check if it is a valid application or not.
+search: '| tstats `security_content_summariesonly` values(Processes.process) as process
+  values(Processes.parent_process) as parent_process values(Processes.process_id)
+  as process_id count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes
+  where `process_verclsid` AND Processes.process="*/S*" Processes.process="*/C*" AND  Processes.process="*{*"
+  AND Processes.process="*}*" by  Processes.process_name Processes.original_file_name
+  Processes.dest Processes.user Processes.parent_process_name Processes.parent_process
+  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `verclsid_clsid_execution_filter`'
+how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
+known_false_positives: windows can used this application for its normal COM object
+  validation.
+references:
+- https://gist.github.com/NickTyrer/0598b60112eaafe6d07789f7964290d5
+- https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/
+tags:
+  analytic_story:
+  - Unusual Processes
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.012/verclsid_exec/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1218.012
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 50
+  confidence: 50
+  risk_score: 25
+  context:
+  - source:endpoint
+  - stage:Defense Evasion
+  message: process $process_name$ to execute possible clsid commandline $process$
+    in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/endpoint/wscript_or_cscript_suspicious_child_process.yml

@@ -0,0 +1,78 @@
+name: Wscript Or Cscript Suspicious Child Process
+id: 1f35e1da-267b-11ec-90a9-acde48001122
+version: 1
+date: '2021-10-06'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious spawned process by wscript or
+  cscript process. This technique was a common technique used by adversaries and malware
+  to execute different LOLBIN, other script like powershell or create a suspended
+  process to inject its code as a defense evasion. This TTP may detect some normal
+  script that using several application tool that are in the list of the child process
+  it detects but a good pivot and indicator that a script is may execute suspicious
+  code.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name
+  IN ("cscript.exe", "wscript.exe") Processes.process_name IN ("regsvr32.exe", "rundll32.exe","winhlp32.exe","certutil.exe","msbuild.exe","cmd.exe","powershell*","wmic.exe","mshta.exe")
+  by Processes.dest Processes.user Processes.parent_process_name 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)`
+  | `wscript_or_cscript_suspicious_child_process_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the process name, parent process, and command-line executions from your
+  endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the
+  Sysmon TA.
+known_false_positives: user may create vbs or js script that use several tool as part
+  of its execution.
+references:
+- https://www.hybrid-analysis.com/sample/8da5b75b6380a41eee3a399c43dfe0d99eeefaa1fd21027a07b1ecaa4cd96fdd?environmentId=120
+tags:
+  analytic_story:
+  - FIN7
+  - Remcos
+  - Unusual Processes
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1055
+  - T1543
+  - T1134.004
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name #parent process name
+  - Processes.parent_process #parent cmdline
+  - Processes.original_file_name
+  - Processes.process_name #process name
+  - Processes.process #process cmdline
+  - Processes.process_id
+  - Processes.parent_process_path
+  - Processes.process_path
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Execution
+  message: wscript or cscript parent process spawned $process_name$ in $dest$
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  - name: user
+    type: User
+    role:
+    - Victim
+  automated_detection_testing: passed

detections/experimental/endpoint/print_processor_registry_autostart.yml

@@ -0,0 +1,69 @@
+name: Print Processor Registry Autostart
+id: 1f5b68aa-2037-11ec-898e-acde48001122
+version: 1
+date: '2021-09-28'
+author: Teoderick Contreras, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: This analytic is to detect a suspicious modification or new registry entry regarding print processor. 
+  This registry is known to be abuse by turla or other APT to gain persistence and privilege escalation to the compromised machine. 
+  This is done by adding the malicious dll payload on the new created key in this registry that will be executed as it restarted the spoolsv.exe process and services.
+search: '| tstats `security_content_summariesonly` count  min(_time) as firstTime
+  max(_time) as lastTime FROM datamodel=Endpoint.Registry 
+  where Registry.registry_path ="*\\Control\\Print\\Environments\\Windows x64\\Print Processors*" 
+  by Registry.dest  Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name 
+  | `security_content_ctime(lastTime)`  
+  | `security_content_ctime(firstTime)`
+  | `drop_dm_object_name(Registry)`
+  | `print_processor_registry_autostart_filter`'
+how_to_implement: To successfully implement this search, you must be ingesting data
+  that records registry activity from your hosts to populate the endpoint data model
+  in the registry node. This is typically populated via endpoint detection-and-response
+  product, such as Carbon Black or endpoint data sources, such as Sysmon. The data
+  used for this search is typically generated via logs that report reads and writes
+  to the registry.
+known_false_positives: possible new printer installation may add driver component on this registry.
+references:
+- https://attack.mitre.org/techniques/T1547/012/
+- https://www.welivesecurity.com/2020/05/21/no-game-over-winnti-group/
+tags:
+  analytic_story:
+  - Windows Persistence Techniques
+  - Windows Privilege Escalation
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/print_reg/sysmon_print.log
+  kill_chain_phases:
+  - Exploitation
+  mitre_attack_id:
+  - T1547.012
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.dest 
+  - Registry.user 
+  - Registry.registry_path 
+  - Registry.registry_key_name 
+  - Registry.registry_value_name 
+  security_domain: endpoint
+  impact: 80
+  confidence: 100
+  # (impact * confidence)/100
+  risk_score: 80
+  context:
+  - source:endpoint
+  - stage:Privilege Escalation Persistence
+  message: modified/added/deleted registry entry $Registry.registry_path$ in $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  - name: user
+    type: user
+    role:
+    - Victim
+  

detections/network/dns_query_length_with_high_standard_deviation.yml

@@ -1,7 +1,7 @@
 name: DNS Query Length With High Standard Deviation
 id: 1a67f15a-f4ff-4170-84e9-08cf6f75d6f5
-version: 3
-date: '2021-07-21'
+version: 4
+date: '2021-10-06'
 author: Bhavin Patel, Splunk
 type: Anomaly
 datamodel:
@@ -11,10 +11,11 @@ description: This search allows you to identify DNS requests and compute the sta
   standard deviation to show you those queries that are unusually large for your environment.
 search: '| tstats `security_content_summariesonly` count from datamodel=Network_Resolution
   where NOT DNS.message_type IN("Pointer","PTR") by DNS.query | `drop_dm_object_name("DNS")`
+  | eval tlds=split(query,".") | eval tld=mvindex(tlds,-1) | eval tld_len=len(tld) | search tld_len<=24
   | eval query_length = len(query) | table query query_length record_type count |
   eventstats stdev(query_length) AS stdev avg(query_length) AS avg p50(query_length)
   AS p50| where query_length>(avg+stdev*2) | eval z_score=(query_length-avg)/stdev
-  | `dns_query_length_with_high_standard_deviation_filter` '
+  | `dns_query_length_with_high_standard_deviation_filter`'
 how_to_implement: To successfully implement this search, you will need to ensure that
   DNS data is populating the Network_Resolution data model.
 known_false_positives: It's possible there can be long domain names that are legitimate.

docs/_config.yml

@@ -6,7 +6,7 @@ description: >- # this means to ignore newlines until "baseurl:"
   mapped to the MITRE ATT&CK Framework, the Lockheed Martin Cyber Kill Chain, and CIS Controls.
   They include Splunk searches, machine learning algorithms and
   Splunk Phantom playbooks (where available)—all designed to work together to detect, investigate, and respond to threats.
-name: Jose Hernandez
+name: Splunk Threat Research Team (STRT)
 url: "https://splunkresearch.com"
 baseurl: "/" # the subpath of your site, e.g. /blog
 url: "https://splunkresearch.com" # the base hostname & protocol for your site, e.g. http://example.com

macros/process_copy.yml

@@ -0,0 +1,3 @@
+definition: (Processes.process_name=copy.exe OR Processes.original_file_name=copy.exe OR Processes.process_name=xcopy.exe OR Processes.original_file_name=xcopy.exe)
+description: Matches the process with its original file name, data for this macro came from https://strontic.github.io/
+name: process_copy

macros/process_sdelete.yml

@@ -0,0 +1,3 @@
+definition: (Processes.process_name=sdelete.exe OR Processes.original_file_name=sdelete.exe)
+description: Matches the process with its original file name, data for this macro came from https://strontic.github.io/
+name: process_sdelete

macros/process_verclsid.yml

@@ -0,0 +1,3 @@
+definition: (Processes.process_name=verclsid.exe OR Processes.original_file_name=verclsid.exe)
+description: Matches the process with its original file name, data for this macro came from https://strontic.github.io/
+name: process_verclsid

requirements.txt

@@ -26,7 +26,7 @@ importlib-metadata==4.8.1
 importlib-resources==5.2.2
 ipaddr==2.2.0
 Jinja2==3.0.1
-jsonschema==3.2.0
+jsonschema==4.0.1
 lockfile==0.12.2
 MarkupSafe==2.0.1
 more-itertools==8.9.0

tests/endpoint/active_setup_registry_autostart.test.yml

@@ -0,0 +1,12 @@
+name: Active Setup Registry Autostart Unit Test
+tests:
+- name: Active Setup Registry Autostart
+  file: endpoint/active_setup_registry_autostart.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/t1547.014/active_setup_stubpath/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/change_default_file_association.test.yml

@@ -0,0 +1,12 @@
+name: Change Default File Association Unit Test
+tests:
+- name: Change Default File Association
+  file: endpoint/change_default_file_association.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.001/txtfile_reg/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/disable_security_logs_using_minint_registry.test.yml

@@ -0,0 +1,12 @@
+name: Disable Security Logs Using MiniNt Registry Unit Test
+tests:
+- name: Disable Security Logs Using MiniNt Registry
+  file: endpoint/disable_security_logs_using_minint_registry.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/minint_reg/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/disable_uac_remote_restriction.test.yml

@@ -0,0 +1,12 @@
+name: Disable UAC Remote Restriction Unit Test
+tests:
+- name: Disable UAC Remote Restriction
+  file: endpoint/disable_uac_remote_restriction.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/LocalAccountTokenFilterPolicy/sysmon.log
+    source:  XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/enable_wdigest_uselogoncredential_registry.test.yml

@@ -0,0 +1,12 @@
+name: Enable WDigest UseLogonCredential Registry Unit Test
+tests:
+- name: Enable WDigest UseLogonCredential Registry
+  file: endpoint/enable_wdigest_uselogoncredential_registry.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1003/wdigest_enable/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/etw_registry_disabled.test.yml

@@ -0,0 +1,12 @@
+name: ETW Registry Disabled Unit Test
+tests:
+- name: ETW Registry Disabled
+  file: endpoint/etw_registry_disabled.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127/etw_disable/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/logon_script_event_trigger_execution.test.yml

@@ -0,0 +1,12 @@
+name: Logon Script Event Trigger Execution Unit Test
+tests:
+- name: Logon Script Event Trigger Execution
+  file: endpoint/logon_script_event_trigger_execution.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1037.001/logonscript_reg/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/msbuild_suspicious_spawned_by_script_process.test.yml

@@ -0,0 +1,12 @@
+name: MSBuild Suspicious Spawned By Script Process Unit Test
+tests:
+- name: MSBuild Suspicious Spawned By Script Process
+  file: endpoint/msbuild_suspicious_spawned_by_script_process.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1127.001/regsvr32_silent/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/print_processor_registry_autostart.test.yml

@@ -0,0 +1,12 @@
+name: Print Processor Registry Autostart Unit Test
+tests:
+- name: Print Processor Registry Autostart
+  file: experimental/endpoint/print_processor_registry_autostart.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-365d'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_print.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.012/print_reg/sysmon_print.log
+    source: WinEventLog:Microsoft-Windows-PrintService/Operational
+    sourcetype: WinEventLog

tests/endpoint/regsvr32_silent_param_dll_loading.test.yml

@@ -0,0 +1,12 @@
+name: Regsvr32 Silent Param Dll Loading Unit Test
+tests:
+- name: Regsvr32 Silent Param Dll Loading
+  file: endpoint/regsvr32_silent_param_dll_loading.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/rundll32_shimcache_flush.test.yml

@@ -0,0 +1,12 @@
+name: Rundll32 Shimcache Flush Unit Test
+tests:
+- name: Rundll32 Shimcache Flush
+  file: endpoint/rundll32_shimcache_flush.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1112/shimcache_flush/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/screensaver_event_trigger_execution.test.yml

@@ -0,0 +1,12 @@
+name: Screensaver Event Trigger Execution  Unit Test
+tests:
+- name: Manual datasets generation for Screensaver Event Trigger Execution. 
+  file: endpoint/screensaver_event_trigger_execution.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.002/scrnsave_reg/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/sdelete_application_execution.test.yml

@@ -0,0 +1,12 @@
+name: Sdelete Application Execution Unit Test
+tests:
+- name: Sdelete Application Execution
+  file: endpoint/sdelete_application_execution.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/sdelete/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/suspicious_copy_on_system32.test.yml

@@ -0,0 +1,12 @@
+name: Suspicious Copy on System32 Unit Test
+tests:
+- name: Suspicious Copy on System32
+  file: endpoint/suspicious_copy_on_system32.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1036.003/copy_sysmon/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/time_provider_persistence_registry.test.yml

@@ -0,0 +1,12 @@
+name: Time Provider Persistence Registry Unit Test
+tests:
+- name: Time Provider Persistence Registry 
+  file: endpoint/time_provider_persistence_registry.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.003/timeprovider_reg/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/vbscript_execution_using_wscript_app.test.yml

@@ -0,0 +1,12 @@
+name: Vbscript Execution Using Wscript App Unit Test
+tests:
+- name: Vbscript Execution Using Wscript App
+  file: endpoint/vbscript_execution_using_wscript_app.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/verclsid_clsid_execution.test.yml

@@ -0,0 +1,12 @@
+name: Verclsid CLSID Execution Unit Test
+tests:
+- name: Verclsid CLSID Execution
+  file: endpoint/verclsid_clsid_execution.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1218.012/verclsid_exec/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/wscript_or_cscript_suspicious_child_process.test.yml

@@ -0,0 +1,12 @@
+name: Wscript Or Cscript Suspicious Child Process Unit Test
+tests:
+- name: Wscript Or Cscript Suspicious Child Process
+  file: endpoint/wscript_or_cscript_suspicious_child_process.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.005/vbs_wscript/sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog