Branch was auto-updated.

detections/endpoint/nltest_domain_trust_discovery.yml

@@ -1,7 +1,7 @@
 name: NLTest Domain Trust Discovery
 id: c3e05466-5f22-11eb-ae93-0242ac130002
-version: 1
-date: '2021-01-25'
+version: 2
+date: '2022-04-18'
 author: Michael Haag, Splunk
 type: TTP
 datamodel:
@@ -12,8 +12,7 @@ description: This search looks for the execution of `nltest.exe` with command-li
   domains. Red Teams and adversaries alike use NLTest.exe to enumerate the current
   domain to assist with further understanding where to pivot next.
 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
-  as lastTime from datamodel=Endpoint.Processes where (Processes.process_name=nltest.exe
-  OR Processes.process_name!=nltest.exe) (Processes.process=*/domain_trusts* OR Processes.process=*/all_trusts*)
+  as lastTime from datamodel=Endpoint.Processes where `process_nltest` (Processes.process=*/domain_trusts* OR Processes.process=*/all_trusts*)
   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)` | `nltest_domain_trust_discovery_filter`'

detections/endpoint/start_up_during_safe_mode_boot.yml

@@ -1,70 +0,0 @@
-name: Start Up During Safe Mode Boot
-id: c6149154-c9d8-11eb-9da7-acde48001122
-version: 2
-date: '2022-01-26'
-author: Teoderick Contreras, Splunk
-type: TTP
-datamodel:
-- Endpoint
-description: This search is to detect a modification or registry add to the safeboot
-  registry as an autostart mechanism. This technique was seen in some ransomware to
-  automatically execute its code upon a safe mode boot.
-search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
-  where Registry.registry_path="*\\System\\CurrentControlSet\\Control\\SafeBoot\\Minimal\*"
-  by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name
-  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`
-  |rename process_guid as proc_guid |join proc_guid, _time [| tstats `security_content_summariesonly`
-  count FROM datamodel=Endpoint.Processes by _time span=1h Processes.process_id Processes.process_name
-  Processes.process Processes.dest Processes.parent_process_name Processes.parent_process
-  Processes.process_guid | `drop_dm_object_name(Processes)` |rename process_guid as
-  proc_guid | fields _time dest user parent_process_name parent_process process_name
-  process_path process proc_guid registry_path registry_value_name registry_value_data]
-  | table _time dest user parent_process_name parent_process process_name process_path
-  process proc_guid registry_path registry_value_name registry_value_data | `start_up_during_safe_mode_boot_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: updated windows application needed in safe boot may used this
-  registry
-references:
-- https://malware.news/t/threat-analysis-unit-tau-threat-intelligence-notification-snatch-ransomware/36365
-tags:
-  analytic_story:
-  - Ransomware
-  confidence: 70
-  context:
-  - Source:Endpoint
-  - Stage:Persistence
-  dataset:
-  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log
-  impact: 60
-  kill_chain_phases:
-  - Exploitation
-  message: Safeboot registry $registry_path$ was added or modified with a new value
-    $registry_value_name$ on $dest$
-  mitre_attack_id:
-  - T1547.001
-  - T1547
-  observable:
-  - name: dest
-    type: Endpoint
-    role:
-    - Victim
-  product:
-  - Splunk Enterprise
-  - Splunk Enterprise Security
-  - Splunk Cloud
-  required_fields:
-  - _time
-  - Registry.registry_path
-  - Registry.registry_key_name
-  - Registry.registry_value_name
-  - Registry.dest
-  risk_score: 42
-  security_domain: endpoint
-  supported_tas:
-  - Splunk_TA_microsoft_sysmon
-  asset_type: Endpoint

detections/endpoint/windows_drivers_loaded_by_signature.yml

@@ -0,0 +1,68 @@
+name: Windows Drivers Loaded by Signature
+id: d2d4af6a-6c2b-4d79-80c5-fc2cf12a2f68
+version: 1
+date: '2022-03-30'
+author: Michael Haag, Splunk
+type: Hunting
+datamodel:
+- Endpoint
+description: The following analytic assists with viewing all drivers being loaded by using Sysmon EventCode 6 (Driver Load). Sysmon provides some simple fields to assist with identifying suspicious drivers.
+  Use this analytic to look at prevalence of driver (count), path of driver, signature status and hash. Review these fields with scrutiny until the ability to prove the driver is legitimate and has a purpose in the environment.
+search: '`sysmon` EventCode=6 
+| stats min(_time) as firstTime max(_time) as lastTime values(ImageLoaded) count by Computer Signed Signature service_signature_verified service_signature_exists Hashes
+| `security_content_ctime(firstTime)`
+| `security_content_ctime(lastTime)`
+| `windows_drivers_loaded_by_signature_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 the latest version of the Sysmon TA. 
+  Most EDR products provide the ability to review driver loads, or module loads, and using a query as such help with hunting for malicious drivers.
+known_false_positives: This analytic is meant to assist with identifying drivers loaded in the environment and not to be setup for notables off the bat.
+references:
+  - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/
+  - https://attack.mitre.org/techniques/T1014/
+  - https://www.fuzzysecurity.com/tutorials/28.html
+tags:
+  analytic_story:
+  - Windows Drivers
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  confidence: 70
+  context:
+  - Source:Endpoint
+  - Stage:Persistence
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1014/windows-sysmon.log
+  impact: 60
+  kill_chain_phases:
+  - Exploitation
+  message: A driver has loaded on $Computer$. 
+  mitre_attack_id:
+  - T1014
+  nist:
+  - DE.CM
+  observable:
+  - name: Computer
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - ImageLoaded
+  - Computer
+  - Signed
+  - Signature
+  - service_signature_verified
+  - service_signature_exists
+  - Hashes
+  risk_score: 42
+  security_domain: endpoint
+  supported_tas:
+  - Splunk_TA_microsoft_sysmon
+  asset_type: Endpoint

detections/endpoint/windows_iso_lnk_file_creation.yml

@@ -0,0 +1,62 @@
+name: Windows ISO LNK File Creation
+id: d7c2c09b-9569-4a9e-a8b6-6a39a99c1d32
+version: 1
+date: '2022-03-29'
+author: Michael Haag, Splunk
+type: Hunting
+datamodel:
+- Endpoint
+description: The following analytic identifies the use of a delivered ISO file that has been mounted and the afformention lnk or file opened within it. When the ISO file is opened, the files are saved in the %USER%\AppData\Local\Temp\<random folder name>\ path. 
+  The analytic identifies .iso.lnk written to the path. The name of the ISO file is prepended. 
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\Microsoft\\Windows\\Recent\\*") Filesystem.file_name IN ("*.iso.lnk") by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name Filesystem.file_path Filesystem.dest 
+  | `drop_dm_object_name(Filesystem)` 
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `windows_iso_lnk_file_creation_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 `Filesystem` 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 may be high depending on the environment and consistent use of ISOs mounting. Restrict to servers, or filter out based on commonly used ISO names. Filter as needed.
+references:
+- https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/
+- https://github.com/MHaggis/notes/blob/master/utilities/ISOBuilder.ps1
+tags:
+  analytic_story:
+  - Spearphishing Attachments
+  asset_type: Endpoint
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  context:
+  - Source:Endpoint
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.001/atomic_red_team/iso_windows-sysmon.log
+  kill_chain_phases:
+  - Delivery
+  message: An ISO file was mounted on $dest$ and should be reviewed and filtered as needed.
+  mitre_attack_id:
+  - T1566.001
+  - T1566
+  - T1204.001
+  - T1204
+  nist:
+  - DE.CM
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - Filesystem.file_create_time 
+  - Filesystem.process_id
+  - Filesystem.file_name 
+  - Filesystem.file_path 
+  - Filesystem.dest
+  security_domain: endpoint
+  impact: 80
+  confidence: 50
+  risk_score: 40

detections/endpoint/windows_registry_certificate_added.yml

@@ -0,0 +1,75 @@
+name: Windows Registry Certificate Added
+id: 5ee98b2f-8b9e-457a-8bdc-dd41aaba9e87
+version: 1
+date: '2022-03-31'
+author: Michael Haag, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: 'The following analytic identifies installation of a root CA certificate by monitoring the registry. The base paths may be found [here](https://gist.github.com/mattifestation/75d6117707bcf8c26845b3cbb6ad2b6b/raw/ae65ef15c706140ffc2e165615204e20f2903028/RootCAInstallationDetection.xml). In short, there are specific certificate registry paths that will be written to (SetValue) when a new certificate is added.
+  The high-fidelity events to pay attention to are SetValue events where the TargetObject property ends with "<THUMBPRINT_VALUE>\Blob" as this indicates the direct installation or modification of a root certificate binary blob.
+  The other high fidelity reference will be which process is making the registry modifications. There are very few processes that modify these day to day, therefore monitoring for all to start (hunting) provides a great beginning.'
+search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Registry
+  where Registry.registry_path IN ("*\\certificates\\*") AND Registry.registry_value_name="Blob"
+  by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.process_guid Registry.registry_key_name Registry.registry_value_data 
+  | `drop_dm_object_name(Registry)` 
+  | join process_guid _time 
+  [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes
+  by _time span=1h Processes.process_id Processes.process_name Processes.process Processes.dest Processes.process_guid 
+  | `drop_dm_object_name(Processes)`]
+  | table
+  _time dest user process_name process process_guid registry_path registry_value_name registry_value_data registry_key_name
+  | `windows_registry_certificate_added_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` and `Registry` 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 will be limited to a legitimate business applicating consistently adding new root certificates to the endpoint. Filter by user, process, or thumbprint.
+references:
+- https://posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec
+- https://github.com/redcanaryco/atomic-red-team/tree/master/atomics/T1553.004
+tags:
+  analytic_story:
+  - Windows Drivers
+  - Windows Registry Abuse
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  confidence: 70
+  context:
+  - Source:Endpoint
+  - Stage:Persistence
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.002/atomic_red_team/certblob_windows-sysmon.log
+  impact: 60
+  kill_chain_phases:
+  - Exploitation
+  message: A root certificate was added on $dest$. 
+  mitre_attack_id:
+  - T1553.004
+  - T1553
+  nist:
+  - DE.CM
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  - Registry.dest
+  - Processes.process_id 
+  - Processes.process_name 
+  - Processes.process
+  - Processes.dest
+  - Processes.process_guid 
+  risk_score: 42
+  security_domain: endpoint
+  supported_tas:
+  - Splunk_TA_microsoft_sysmon
+  asset_type: Endpoint

detections/endpoint/windows_registry_delete_task_sd.yml

@@ -0,0 +1,70 @@
+name: Windows Registry Delete Task SD
+id: ffeb7893-ff06-446f-815b-33ca73224e92
+version: 1
+date: '2022-04-13'
+author: Michael Haag, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: The following analytic identifies a process attempting to delete a scheduled task SD (Security Descriptor) from within the registry path of that task.
+  This may occur from a non-standard process running and may not come from reg.exe. This particular behavior will remove the actual Task Name from the Task Scheduler GUI and from the command-line query - schtasks.exe /query. 
+  In addition, in order to perform this action, the user context will need to be SYSTEM.
+search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Registry
+  where Registry.registry_path IN ("*\\Schedule\\TaskCache\\Tree\\*") Registry.user="SYSTEM" Registry.registry_value_name="SD" (Registry.action=Deleted OR Registry.action=modified)
+  by _time  Registry.dest Registry.process_guid Registry.user Registry.registry_path Registry.registry_value_name Registry.registry_key_name Registry.registry_value_data Registry.status Registry.action
+  | `drop_dm_object_name(Registry)` 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `windows_registry_delete_task_sd_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 `Registry` 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 the activity is not common to delete ONLY the SD from the registry. Filter as needed. Update the analytic Modified or Deleted values based on product that is in the datamodel.
+references:
+- https://www.microsoft.com/security/blog/2022/04/12/tarrask-malware-uses-scheduled-tasks-for-defense-evasion/
+- https://gist.github.com/MHaggis/5f7fd6745915166fc6da863d685e2728
+- https://gist.github.com/MHaggis/b246e2fae6213e762a6e694cabaf0c17
+tags:
+  analytic_story:
+  - Windows Registry Abuse
+  - Windows Persistence Techniques
+  asset_type: Endpoint
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  confidence: 70
+  context:
+  - Source:Endpoint
+  - Stage:Persistence
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/taskschedule/sd_delete_windows-sysmon.log
+  impact: 70
+  kill_chain_phases:
+  - Installation
+  mitre_attack_id:
+  - T1053.005
+  - T1562
+  nist:
+  - DE.CM
+  message: A scheduled task security descriptor was deleted from the registry on $dest$. 
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  - Registry.dest
+  - Processes.process_id 
+  - Processes.process_name 
+  - Processes.process
+  - Processes.dest
+  - Processes.process_guid 
+  risk_score: 49
+  security_domain: endpoint

detections/endpoint/windows_registry_modification_for_safe_mode_persistence.yml

@@ -0,0 +1,78 @@
+name: Windows Registry Modification for Safe Mode Persistence
+id: c6149154-c9d8-11eb-9da7-acde48001122
+version: 3
+date: '2022-03-31'
+author: Teoderick Contreras, Michael Haag, Splunk
+type: TTP
+datamodel:
+- Endpoint
+description: The following analytic identifies a modification or registry add to the safeboot registry as an autostart mechanism. This technique is utilized by adversaries to persist a driver or service into Safe Mode. Two keys are monitored in this analytic,  Minimal and Network. 
+  adding values to Minimal will load into Safe Mode and by adding into Network it will provide the service or drive the ability to perform network connections in Safe Mode. 
+search: '| tstats `security_content_summariesonly` count from datamodel=Endpoint.Registry
+  where Registry.registry_path IN ("*SYSTEM\\CurrentControlSet\\Control\\SafeBoot\\Minimal\\*","*SYSTEM\\CurrentControlSet\\Control\\SafeBoot\\Network\\*")
+  by _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_value_name Registry.process_guid Registry.registry_key_name Registry.registry_value_data 
+  | `drop_dm_object_name(Registry)` 
+  | join process_guid _time 
+  [| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes
+  by _time span=1h Processes.process_id Processes.process_name Processes.process Processes.dest Processes.process_guid 
+  | `drop_dm_object_name(Processes)`]
+  | table
+  _time dest user process_name process process_guid registry_path registry_value_name registry_value_data registry_key_name
+  | `windows_registry_modification_for_safe_mode_persistence_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: updated windows application needed in safe boot may used this
+  registry
+references:
+- https://malware.news/t/threat-analysis-unit-tau-threat-intelligence-notification-snatch-ransomware/36365
+- https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/
+- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1112/T1112.md
+- https://blog.didierstevens.com/2007/03/26/playing-with-safe-mode/
+tags:
+  analytic_story:
+  - Ransomware
+  - Windows Registry Abuse
+  - Windows Drivers
+  confidence: 70
+  context:
+  - Source:Endpoint
+  - Stage:Persistence
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/malware/ransomware_ttp/data1/windows-sysmon.log
+  impact: 60
+  kill_chain_phases:
+  - Exploitation
+  message: Safeboot registry $registry_path$ was added or modified with a new value
+    $registry_value_name$ on $dest$
+  mitre_attack_id:
+  - T1547.001
+  - T1547
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Registry.registry_path
+  - Registry.registry_key_name
+  - Registry.registry_value_name
+  - Registry.dest
+  - Processes.process_id 
+  - Processes.process_name 
+  - Processes.process
+  - Processes.dest
+  - Processes.process_guid 
+  risk_score: 42
+  security_domain: endpoint
+  supported_tas:
+  - Splunk_TA_microsoft_sysmon
+  asset_type: Endpoint

stories/windows_drivers.yml

@@ -0,0 +1,20 @@
+name: Windows Drivers
+id: d0a9323f-9411-4da6-86b2-18c184d750c0
+version: 1
+date: '2022-03-30'
+author: Michael Haag, Splunk
+description: Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components.
+narrative: A rootkit on Windows may sometimes be in the form of a Windows Driver. A driver typically has a file extension of .sys, however the internals of a sys file is similar to a Windows DLL. For Microsoft Windows to load a driver, a few requirements are needed. First, it must have a valid signature. Second, typically it should load from the windows\system32\drivers path.
+  There are a few methods to investigate drivers in the environment. Drivers are noisy. An inventory of all drivers is important to understand prevalence. A driver location (Path) is also important when attempting to baseline. Looking at a driver name and path is not enough, we must also explore the signing information. Product, description, company name, signer and signing result are all items to take into account when reviewing drivers.
+  What makes a driver malicious? Depending if a driver was dropped during a campaign or you are baselining drivers after, triaging a driver to determine maliciousness may be tough. We break this into two categories - 1. vulnerable drivers 2. driver rootkits. Attempt to identify prevelance of the driver. Is it on one or many?
+  Review the signing information if it is present. Is it common? A lot of driver hunting will lead down rabbit holes, but we hope to help lead the way. 
+references: 
+  - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/
+tags:
+  analytic_story: Windows Drivers
+  category: []
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  usecase: Advanced Threat Detection

tests/endpoint/windows_drivers_loaded_by_signature.test.yml

@@ -0,0 +1,12 @@
+name: Windows Drivers Loaded by Signature Unit Test
+tests:
+- name: Windows Drivers Loaded by Signature
+  file: endpoint/windows_drivers_loaded_by_signature.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/T1014/windows-sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/windows_iso_lnk_file_creation.test.yml

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

tests/endpoint/windows_registry_certificate_added.test.yml

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

tests/endpoint/windows_registry_delete_task_sd.test.yml

@@ -0,0 +1,12 @@
+name: Windows Registry Delete Task SD Unit Test
+tests:
+- name: Windows Registry Delete Task SD
+  file: endpoint/windows_registry_delete_task_sd.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: -24h
+  latest_time: now
+  attack_data:
+  - file_name: sd_delete_windows-sysmon.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.005/taskschedule/sd_delete_windows-sysmon.log
+    source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
+    sourcetype: xmlwineventlog

tests/endpoint/windows_registry_modification_for_safe_mode_persistence.test.yml

@@ -1,7 +1,7 @@
-name: Start Up During Safe Mode Boot Unit Test
+name: Windows Registry Modification for Safe Mode Persistence Unit Test
 tests:
-- name: Start Up During Safe Mode Boot
-  file: endpoint/start_up_during_safe_mode_boot.yml
+- name: 'Windows Registry Modification for Safe Mode Persistence'
+  file: endpoint/windows_registry_modification_for_safe_mode_persistence.yml
   pass_condition: '| stats count | where count > 0'
   earliest_time: -24h
   latest_time: now