Merge pull request #1907 from splunk/linux_persist_priv_batch_2

linux_persist_priv_batch_2

detections/endpoint/linux_file_creation_in_init_boot_directory.yml

@@ -0,0 +1,69 @@
+name: Linux File Creation In Init Boot Directory
+id: 97d9cfb2-61ad-11ec-bb2d-acde48001122
+version: 1
+date: '2021-12-20'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for suspicious file creation on init system directories
+  for automatic execution of script or file upon boot up. This technique is commonly
+  abuse by adversaries, malware author and red teamer to persist on the targeted or
+  compromised host. This behavior can be executed or use by an administrator or network
+  operator to add script files or binary files as part of a task or automation.
+  filter is needed.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*/etc/init.d/*",
+  "*/etc/rc.d/*", "*/sbin/init.d/*", "*/etc/rc.local*") by Filesystem.dest Filesystem.file_name
+  Filesystem.process_guid Filesystem.file_path | `drop_dm_object_name(Filesystem)`
+  | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)` | `linux_file_creation_in_init_boot_directory_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the file name, file path, and process_guid executions from your endpoints.
+  If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase
+known_false_positives: Administrator or network operator can create file in this folders
+  for automation purposes. Please update the filter macros to remove false positives. 
+references:
+- https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1037.004
+  - T1037
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Filesystem.dest
+  - Filesystem.file_create_time
+  - Filesystem.file_name
+  - Filesystem.process_guid
+  - Filesystem.file_path
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: A file $file_name$ is created in $file_path$ on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_file_creation_in_profile_directory.yml

@@ -0,0 +1,70 @@
+name: Linux File Creation In Profile Directory
+id: 46ba0082-61af-11ec-9826-acde48001122
+version: 1
+date: '2021-12-20'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for suspicious file creation in /etc/profile.d directory
+  to automatically execute scripts by shell upon boot up of a linux machine. This technique is
+  commonly abused by adversaries, malware and red teamers as a persistence mechanism
+  to the targeted or compromised host. This Anomaly detection is a good indicator
+  that someone wants to run a code after boot up which can be done also by the administrator
+  or network operator for automation purposes.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*/etc/profile.d/*")
+  by Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.process_guid
+  Filesystem.file_path | `drop_dm_object_name(Filesystem)` | `security_content_ctime(lastTime)`
+  | `security_content_ctime(firstTime)` | `linux_file_creation_in_profile_directory_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the file name, file path, and process_guid executions from your endpoints.
+ If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
+known_false_positives: Administrator or network operator can create file in profile.d
+  folders for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://attack.mitre.org/techniques/T1546/004/
+- https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1546.004
+  - T1546
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Filesystem.dest
+  - Filesystem.file_create_time
+  - Filesystem.file_name
+  - Filesystem.process_guid
+  - Filesystem.file_path
+  security_domain: endpoint
+  impact: 70
+  confidence: 80
+  risk_score: 56
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: A file $file_name$ is created in $file_path$ on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_service_file_created_in_systemd_directory.yml

@@ -0,0 +1,76 @@
+name: Linux Service File Created In Systemd Directory
+id: c7495048-61b6-11ec-9a37-acde48001122
+version: 1
+date: '2021-12-20'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for suspicious file creation in systemd timer directory
+  in linux platform. systemd is a system and service manager for Linux distributions.
+  From the Windows perspective, this process fulfills the duties of wininit.exe and
+  services.exe combined. At the risk of simplifying the functionality of systemd,
+  it initializes a Linux system and starts relevant services that are defined in service
+  unit files. Adversaries, malware and red teamers may abuse this this feature by
+  stashing systemd service file to persist on the targetted or compromised host.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime FROM datamodel=Endpoint.Filesystem where Filesystem.file_name = *.service
+  Filesystem.file_path IN ("*/etc/systemd/system*", "*/lib/systemd/system*", "*/usr/lib/systemd/system*",
+  "*/run/systemd/system*", "*~/.config/systemd/*", "*~/.local/share/systemd/*","*/etc/systemd/user*",
+  "*/lib/systemd/user*", "*/usr/lib/systemd/user*", "*/run/systemd/user*") by Filesystem.dest
+  Filesystem.file_create_time Filesystem.file_name Filesystem.process_guid Filesystem.file_path
+  | `drop_dm_object_name(Filesystem)` | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)`
+  | `linux_service_file_created_in_systemd_directory_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the file name, file path, and process_guid executions from your endpoints.
+  If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
+known_false_positives: Administrator or network operator can create file in systemd
+  folders for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://attack.mitre.org/techniques/T1053/006/
+- https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/
+- https://redcanary.com/blog/attck-t1501-understanding-systemd-service-persistence/
+- https://github.com/microsoft/MSTIC-Sysmon/blob/main/linux/configs/attack-based/persistence/T1053.003_Cron_Activity.xml
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1053.006
+  - T1053
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Filesystem.dest
+  - Filesystem.file_create_time
+  - Filesystem.file_name
+  - Filesystem.process_guid
+  - Filesystem.file_path
+  security_domain: endpoint
+  impact: 80
+  confidence: 80
+  risk_score: 64
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: A service file named as $file_path$ is created in systemd folder on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_service_restarted.yml

@@ -0,0 +1,76 @@
+name: Linux Service Restarted
+id: 084275ba-61b8-11ec-8d64-acde48001122
+version: 1
+date: '2021-12-20'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for restarted or re-enable services in linux platform.
+  This technique can be executed or performed using systemctl or service tool application.
+  Adversaries may create or modify Windows services to repeatedly execute malicious
+  payloads as part of persistence. When Windows boots up, it starts programs or applications
+  called services that perform background system functions. Administrator may also
+  create a legitimated service for a specific tool or normal application as part of
+  task or automation, in this scenario it is suggested to look for the service path
+  of the actual script or executable that register as service and who created the
+  service for further verification.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where (Processes.process_name IN ("systemctl",
+  "service") OR Processes.process IN ("*systemctl *", "*service *")) Processes.process
+  IN ("*restart*", "*reload*", "*reenable*") by Processes.dest Processes.user Processes.parent_process_name
+  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id
+  Processes.process_guid | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `linux_service_restarted_filter`'
+how_to_implement: To successfully implement this search, you need to be ingesting
+  logs with the process name, parent process, and commandline executions from your
+  endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
+known_false_positives: Administrator or network operator can use this commandline
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://attack.mitre.org/techniques/T1543/003/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1053.006
+  - T1053
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name
+  - Processes.process_name
+  - Processes.process
+  - Processes.process_id
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 50
+  confidence: 50
+  risk_score: 25
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: A commandline $process$ that may create or start a service on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_service_started_or_enabled.yml

@@ -0,0 +1,76 @@
+name: Linux Service Started Or Enabled
+id: e0428212-61b7-11ec-88a3-acde48001122
+version: 1
+date: '2021-12-20'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for created or enable services in linux platform.
+  This technique can be executed or performed using systemctl or service tool application.
+  Adversaries may create or modify Windows services to repeatedly execute malicious
+  payloads as part of persistence. When Windows boots up, it starts programs or applications
+  called services that perform background system functions. Administrator may also
+  create a legitimated service for a specific tool or normal application as part of
+  task or automation, in this scenario it is suggested to look for the service path
+  of the actual script or executable that register as service and who created the
+  service for further verification.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where (Processes.process_name IN ("systemctl",
+  "service") OR Processes.process IN ("*systemctl *", "*service *")) Processes.process
+  IN ("* start *", "* enable *") by Processes.dest Processes.user Processes.parent_process_name
+  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id
+  Processes.process_guid | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `linux_service_started_or_enabled_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 can use the Add-on for Linux Sysmon from Splunkbase. 
+known_false_positives: Administrator or network operator can use this commandline
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://attack.mitre.org/techniques/T1543/003/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1053.006
+  - T1053
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name
+  - Processes.process_name
+  - Processes.process
+  - Processes.process_id
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 60
+  confidence: 70
+  risk_score: 42
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: a commandline $process$ that may create or start a service on $dest
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_setuid_using_chmod_utility.yml

@@ -0,0 +1,75 @@
+name: Linux Setuid Using Chmod Utility
+id: bf0304b6-6250-11ec-9d7c-acde48001122
+version: 1
+date: '2021-12-21'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for suspicious chmod utility execution to enable
+  SUID bit. This allows a user to temporarily gain root access, usually in order to
+  run a program. For example, only the root account is allowed to change the password
+  information contained in the password database; If the SUID bit appears as an s,
+  the file's owner also has execute permission to the file; if it appears as an S,
+  the file's owner does not have execute permission. The second specialty permission
+  is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily
+  change group membership, usually to execute a program. The SGID bit is set if an
+  s or an S appears in the group section of permissions.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes WHERE (Processes.process_name = chmod
+  OR Processes.process = "*chmod *") AND Processes.process IN("* g+s *", "* u+s *",
+  "* 4777 *", "* 4577 *") by Processes.dest Processes.user Processes.parent_process_name
+  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id
+  Processes.process_guid | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `linux_setuid_using_chmod_utility_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 can use the Add-on for Linux Sysmon from Splunkbase.
+known_false_positives: Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
+references:
+- https://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1548.001
+  - T1548
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name
+  - Processes.process_name
+  - Processes.process
+  - Processes.process_id
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: a commandline $process$ that may set suid or sgid on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

detections/endpoint/linux_setuid_using_setcap_utility.yml

@@ -0,0 +1,77 @@
+name: Linux Setuid Using Setcap Utility
+id: 9d96022e-6250-11ec-9a19-acde48001122
+version: 1
+date: '2021-12-21'
+author: Teoderick Contreras, Splunk
+type: Anomaly
+datamodel:
+- Endpoint
+description: This analytic looks for suspicious setcap utility execution to enable
+  SUID bit. This allows a user to temporarily gain root access, usually in order to
+  run a program. For example, only the root account is allowed to change the password
+  information contained in the password database; If the SUID bit appears as an s,
+  the file's owner also has execute permission to the file; if it appears as an S,
+  the file's owner does not have execute permission. The second specialty permission
+  is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily
+  change group membership, usually to execute a program. The SGID bit is set if an
+  s or an S appears in the group section of permissions.
+search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
+  as lastTime from datamodel=Endpoint.Processes where (Processes.process_name = setcap
+  OR Processes.process = "*setcap *") AND Processes.process IN ("* cap_setuid=ep *",
+  "* cap_setuid+ep *", "* cap_net_bind_service+p *", "* cap_net_raw+ep *", "* cap_dac_read_search+ep
+  *") by Processes.dest Processes.user Processes.parent_process_name Processes.process_name
+  Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid
+  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `linux_setuid_using_setcap_utility_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 can use the Add-on for Linux Sysmon from Splunkbase.
+known_false_positives: Administrator or network operator can execute this command.
+  Please update the filter macros to remove false positives.
+references:
+- https://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_setcap/sysmon_linux.log
+  kill_chain_phases:
+  - Privilege Escalation
+  mitre_attack_id:
+  - T1548.001
+  - T1548
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Processes.dest
+  - Processes.user
+  - Processes.parent_process_name
+  - Processes.process_name
+  - Processes.process
+  - Processes.process_id
+  - Processes.parent_process_id
+  security_domain: endpoint
+  impact: 70
+  confidence: 70
+  risk_score: 49
+  context:
+  - Source:Endpoint
+  - Stage:Privilege Escalation
+  - Stage:Persistence
+  message: A commandline $process$ that may set suid or sgid on $dest$
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  nist:
+  - DE.CM
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 16
+  automated_detection_testing: passed

tests/endpoint/linux_file_creation_in_init_boot_directory.test.yml

@@ -0,0 +1,12 @@
+name: Linux File Creation In Init Boot Directory Unit Test
+tests:
+- name: Linux File Creation In Init Boot Directory
+  file: endpoint/linux_file_creation_in_init_boot_directory.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-30d'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_file_creation_in_profile_directory.test.yml

@@ -0,0 +1,12 @@
+name: Linux File Creation In Profile Directory Unit Test
+tests:
+- name: Linux File Creation In Profile Directory
+  file: endpoint/linux_file_creation_in_profile_directory.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1546.004/linux_init_profile/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_service_file_created_in_systemd_directory.test.yml

@@ -0,0 +1,12 @@
+name: Linux Service File Created In Systemd Directory Unit Test
+tests:
+- name: Linux Service File Created In Systemd Directory
+  file: endpoint/linux_service_file_created_in_systemd_directory.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_service_restarted.test.yml

@@ -0,0 +1,12 @@
+name: Linux Service Restarted Unit Test
+tests:
+- name: Linux Service Restarted
+  file: endpoint/linux_service_restarted.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_service_started_or_enabled.test.yml

@@ -0,0 +1,12 @@
+name: Linux Service Started Or Enabled Unit Test
+tests:
+- name: Linux Service Started Or Enabled
+  file: endpoint/linux_service_started_or_enabled.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.006/service_systemd/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_setuid_using_chmod_utility.test.yml

@@ -0,0 +1,12 @@
+name: Linux Setuid Using Chmod Utility Unit Test
+tests:
+- name: Linux Setuid Using Chmod Utility
+  file: endpoint/linux_setuid_using_chmod_utility.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/chmod_uid/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux

tests/endpoint/linux_setuid_using_setcap_utility.test.yml

@@ -0,0 +1,12 @@
+name: Linux Setuid Using Setcap Utility Unit Test
+tests:
+- name: Linux Setuid Using Setcap Utility
+  file: endpoint/linux_setuid_using_setcap_utility.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: sysmon_linux.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_setcap/sysmon_linux.log
+    source: Syslog:Linux-Sysmon/Operational
+    sourcetype: sysmon_linux