diff --git a/detections/endpoint/linux_adding_crontab_using_list_parameter.yml b/detections/endpoint/linux_adding_crontab_using_list_parameter.yml new file mode 100644 index 0000000000..15196aad37 --- /dev/null +++ b/detections/endpoint/linux_adding_crontab_using_list_parameter.yml @@ -0,0 +1,74 @@ +name: Linux Adding Crontab Using List Parameter +id: 52f6d751-1fd4-4c74-a4c9-777ecfeb5c58 +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: Hunting +datamodel: +- Endpoint +description: The following analytic identifies a suspicious cron jobs modification using crontab list parameters. + This command line parameter can be abused by malware like industroyer2, adversaries, and red teamers to add a + crontab entry to their malicious code to execute to the schedule they want. This event can also be executed by administrator + or normal user for automation purposes so filter is needed. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes + where Processes.process_name = "crontab" Processes.process= "* -l*" + by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.dest Processes.user + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `linux_adding_crontab_using_list_parameter_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 application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + - Linux Privilege Escalation + - Linux Persistence Techniques + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 50 + context: + - Source:Endpoint + - Stage:Privilege Escalation + - Stage:Persistence + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.003/crontab_list_parameter/sysmon_linux.log + impact: 50 + kill_chain_phases: + - Exploitation + message: A possible crontab list command $process$ executed on $dest$ + mitre_attack_id: + - T1053.003 + - T1053 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + risk_score: 25 + security_domain: endpoint diff --git a/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml b/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml new file mode 100644 index 0000000000..7bd4f5126e --- /dev/null +++ b/detections/endpoint/linux_deleting_critical_directory_using_rm_command.yml @@ -0,0 +1,72 @@ +name: Linux Deleting Critical Directory Using RM Command +id: 33f89303-cc6f-49ad-921d-2eaea38a6f7a +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: TTP +datamodel: +- Endpoint +description: The following analytic identifies a suspicious deletion of a critical folder in Linux machine using rm command. + This technique was seen in industroyer2 campaign to wipe or destroy energy facilities of a targeted sector. Deletion in these list of folder + is not so common since it need some elevated privileges to access some of it. We recommend to look further events specially in file access or file deletion, + process commandline that may related to this technique. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes + where Processes.process_name =rm AND Processes.process= "* -rf *" AND Processes.process IN ("*/boot/*", "*/var/log/*", "*/etc/*", "*/dev/*") + by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `linux_deleting_critical_directory_using_rm_command_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 application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + - Data Destruction + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 80 + context: + - Source:Endpoint + - Stage:Privilege Escalation + - Stage:Persistence + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log + impact: 80 + kill_chain_phases: + - Exploitation + message: A deletion in known critical list of folder using rm command $process$ executed on $dest$ + mitre_attack_id: + - T1485 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + risk_score: 64 + security_domain: endpoint diff --git a/detections/endpoint/linux_disable_services.yml b/detections/endpoint/linux_disable_services.yml new file mode 100644 index 0000000000..5893081854 --- /dev/null +++ b/detections/endpoint/linux_disable_services.yml @@ -0,0 +1,71 @@ +name: Linux Disable Services +id: f2e08a38-6689-4df4-ad8c-b51c16262316 +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: TTP +datamodel: +- Endpoint +description: The following analytic is to detect events that attempts to disable a service. + This is typically identified in parallel with other instances of service enumeration of + attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 + malware to terminate security services or other related services to continue there objective as a destructive payload. +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", "svcadm") Processes.process = "* disable*" + by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `linux_disable_services_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 application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 70 + context: + - Source:Endpoint + - Stage:Defense Evasion + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log + impact: 70 + kill_chain_phases: + - Exploitation + message: An instance of $parent_process_name$ spawning $process_name$ was identified + attempting to disable services on endpoint $dest$ by $user$. + mitre_attack_id: + - T1489 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + risk_score: 49 + security_domain: endpoint diff --git a/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml b/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml new file mode 100644 index 0000000000..97af6add1c --- /dev/null +++ b/detections/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.yml @@ -0,0 +1,89 @@ +name: Linux High Frequency Of File Deletion In Boot Folder +id: e27fbc5d-0445-4c4a-bc39-87f060d5c602 +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: TTP +datamodel: +- Endpoint +description: This analytic is to detect a high frequency of file deletion relative to process name and process id /boot/ folder. + These events was seen in industroyer2 wiper malware where it tries to delete all files in a critical directory in linux directory. + This detection already contains some filter that might cause false positive during our testing. +search: '| tstats `security_content_summariesonly` values(Filesystem.file_name) as deletedFileNames values(Filesystem.file_path) as deletedFilePath dc(Filesystem.file_path) as numOfDelFilePath count min(_time) as firstTime max(_time) as lastTime + FROM datamodel=Endpoint.Filesystem + where Filesystem.action=deleted Filesystem.file_path = "/boot/*" + by _time span=1h Filesystem.dest Filesystem.process_guid Filesystem.action + | `drop_dm_object_name(Filesystem)` + |rename process_guid as proc_guid + |join proc_guid, _time [ + | tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.parent_process_name != unknown + NOT (Processes.parent_process_name IN ("/usr/bin/dpkg", "*usr/bin/python*", "*/usr/bin/apt-*", "/bin/rm", "*splunkd", "/usr/bin/mandb")) + by _time span=1h Processes.process_id Processes.process_name Processes.process Processes.dest Processes.parent_process_name Processes.parent_process Processes.process_path 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 registry_key_name action] + | table process_name process proc_guid action _time deletedFileNames deletedFilePath numOfDelFilePath parent_process_name parent_process process_path dest user + | where numOfDelFilePath >= 200 + | `linux_high_frequency_of_file_deletion_in_boot_folder_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: linux package installer/uninstaller may cause this event. + Please update you filter macro to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + - Data Destruction + asset_type: endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 80 + context: + - Source:Endpoint + - Stage:Defense Evasion + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_boot_dir/sysmon_linux.log + impact: 100 + kill_chain_phases: + - Exploitation + message: a $process_name$ deleting multiple files in /boot/ folder in $dest$ + mitre_attack_id: + - T1485 + - T1070.004 + - T1070 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + - Filesystem.action + - Processes.dest + - Processes.user + - Processes.parent_process_name + - Processes.parent_process + - Processes.process_name + - Processes.process_path + - Processes.process + - Processes.process_id + - Processes.parent_process_id + risk_score: 80 + security_domain: endpoint diff --git a/detections/endpoint/linux_shred_overwrite_command.yml b/detections/endpoint/linux_shred_overwrite_command.yml new file mode 100644 index 0000000000..5939039349 --- /dev/null +++ b/detections/endpoint/linux_shred_overwrite_command.yml @@ -0,0 +1,74 @@ +name: Linux Shred Overwrite Command +id: c1952cf1-643c-4965-82de-11c067cbae76 +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: TTP +datamodel: +- Endpoint +description: This analytic is to detect a shred process to overwrite a files in a linux machine. + Shred Linux application is designed to overwrite file to hide its contents or make the deleted file un-recoverable. + Weve seen this technique in industroyer2 malware that tries to wipe energy facilities of targeted sector as part of its destructive attack. + It might be some normal user may use this command for valid purposes but it is recommended to check what files, disk or folder it tries to shred + that might be good pivot for incident response in this type of destructive malware. +search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes + where Processes.process_name =shred AND Processes.process IN ("*-n*", "*-u*", "*-z*", "*-s*") + by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `linux_shred_overwrite_command_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 application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + - Linux Privilege Escalation + - Linux Persistence Techniques + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 70 + context: + - Source:Endpoint + - Stage:Privilege Escalation + - Stage:Persistence + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/rm_shred_critical_dir/sysmon_linux.log + impact: 70 + kill_chain_phases: + - Exploitation + message: A possible shred overwrite command $process$ executed on $dest$ + mitre_attack_id: + - T1485 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + risk_score: 49 + security_domain: endpoint diff --git a/detections/endpoint/linux_stop_services.yml b/detections/endpoint/linux_stop_services.yml new file mode 100644 index 0000000000..49d7dce761 --- /dev/null +++ b/detections/endpoint/linux_stop_services.yml @@ -0,0 +1,72 @@ +name: Linux Stop Services +id: d05204a5-9f1c-4946-a7f3-4fa58d76d5fd +version: 1 +date: '2022-04-22' +author: Teoderick Contreras, Splunk +type: TTP +datamodel: +- Endpoint +description: The following analytic is to detect events that attempt to stop or clear a service. + This is typically identified in parallel with other instances of service enumeration of + attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 + malware to terminate security services or other related services to continue there objective as a destructive payload. +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", "svcadm") Processes.process ="*stop*" + by Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id + Processes.process_guid Processes.dest Processes.user + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `linux_stop_services_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 application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + asset_type: Endpoint + cis20: + - CIS 3 + - CIS 5 + - CIS 16 + confidence: 70 + context: + - Source:Endpoint + - Stage:Defense Evasion + dataset: + - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_service_stop_disable/sysmon_linux.log + impact: 70 + kill_chain_phases: + - Exploitation + message: An instance of $parent_process_name$ spawning $process_name$ was identified + attempting to stop services on endpoint $dest$ by $user$. + mitre_attack_id: + - T1489 + nist: + - DE.CM + observable: + - name: dest + type: Hostname + role: + - Victim + 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 + risk_score: 49 + security_domain: endpoint diff --git a/tests/endpoint/linux_adding_crontab_using_list_parameter.test.yml b/tests/endpoint/linux_adding_crontab_using_list_parameter.test.yml new file mode 100644 index 0000000000..d6dbcd0bec --- /dev/null +++ b/tests/endpoint/linux_adding_crontab_using_list_parameter.test.yml @@ -0,0 +1,12 @@ +name: Linux Adding Crontab Using List Parameter Unit Test +tests: +- name: Linux Adding Crontab Using List Parameter + file: endpoint/linux_adding_crontab_using_list_parameter.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.003/crontab_list_parameter/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux diff --git a/tests/endpoint/linux_deleting_critical_directory_using_rm_command.test.yml b/tests/endpoint/linux_deleting_critical_directory_using_rm_command.test.yml new file mode 100644 index 0000000000..df0185175d --- /dev/null +++ b/tests/endpoint/linux_deleting_critical_directory_using_rm_command.test.yml @@ -0,0 +1,12 @@ +name: Linux Deleting Critical Directory Using RM Command Unit Test +tests: +- name: Linux Deleting Critical Directory Using RM Command + file: endpoint/linux_deleting_critical_directory_using_rm_command.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/T1485/rm_shred_critical_dir/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux diff --git a/tests/endpoint/linux_disable_services.test.yml b/tests/endpoint/linux_disable_services.test.yml new file mode 100644 index 0000000000..1dbbfb651a --- /dev/null +++ b/tests/endpoint/linux_disable_services.test.yml @@ -0,0 +1,12 @@ +name: Linux Disable Services Unit Test +tests: +- name: Linux Disable Services + file: endpoint/linux_disable_services.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/T1489/linux_service_stop_disable/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux diff --git a/tests/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.test.yml b/tests/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.test.yml new file mode 100644 index 0000000000..665fe0690b --- /dev/null +++ b/tests/endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.test.yml @@ -0,0 +1,12 @@ +name: Linux High Frequency Of File Deletion In Boot Folder Unit Test +tests: +- name: Linux High Frequency Of File Deletion In Boot Folder + file: endpoint/linux_high_frequency_of_file_deletion_in_boot_folder.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/T1485/rm_boot_dir/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux \ No newline at end of file diff --git a/tests/endpoint/linux_shred_overwrite_command.test.yml b/tests/endpoint/linux_shred_overwrite_command.test.yml new file mode 100644 index 0000000000..f007246b53 --- /dev/null +++ b/tests/endpoint/linux_shred_overwrite_command.test.yml @@ -0,0 +1,12 @@ +name: Linux Shred Overwrite Command Unit Test +tests: +- name: Linux Shred Overwrite Command + file: endpoint/linux_shred_overwrite_command.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/T1485/rm_shred_critical_dir/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux diff --git a/tests/endpoint/linux_stop_services.test.yml b/tests/endpoint/linux_stop_services.test.yml new file mode 100644 index 0000000000..f740b597a5 --- /dev/null +++ b/tests/endpoint/linux_stop_services.test.yml @@ -0,0 +1,12 @@ +name: Linux Stop Services Unit Test +tests: +- name: Linux Stop Services + file: endpoint/linux_stop_services.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/T1489/linux_service_stop_disable/sysmon_linux.log + source: Syslog:Linux-Sysmon/Operational + sourcetype: sysmon_linux