diff --git a/detections/application/email_attachments_with_lots_of_spaces.yml b/detections/application/email_attachments_with_lots_of_spaces.yml index 68b4b36694..e75c27439a 100644 --- a/detections/application/email_attachments_with_lots_of_spaces.yml +++ b/detections/application/email_attachments_with_lots_of_spaces.yml @@ -29,7 +29,7 @@ how_to_implement: "You need to ingest data from emails. Specifically, the sender this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/` and add the correct hostname to the \"\ Phantom Instance\" field in the Adaptive Response Actions when configuring this - detection search. The notable event will be sent to Phantom and the playbook will + detection search. The finding based event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox." diff --git a/detections/application/okta_risk_threshold_exceeded.yml b/detections/application/okta_risk_threshold_exceeded.yml index 5e36be6c59..f96b59ed7a 100644 --- a/detections/application/okta_risk_threshold_exceeded.yml +++ b/detections/application/okta_risk_threshold_exceeded.yml @@ -28,9 +28,9 @@ search: '| tstats `security_content_summariesonly` values(All_Risk.analyticstori | search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`' how_to_implement: This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" - analytic stories are enabled. TTPs may be set to Notables for point detections; - anomalies should not be notables but rather risk generators. The correlation relies - on risk before generating a notable. Modify the value as needed. + analytic stories are enabled. TTPs may be set to finding for point detections; + anomalies should not be findings but rather intermediate findings. The correlation relies + on intermediate findings before generating a findings. Modify the value as needed. known_false_positives: False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization. diff --git a/detections/application/suspicious_email_attachment_extensions.yml b/detections/application/suspicious_email_attachment_extensions.yml index 0f01351ca0..3a44f76bfa 100644 --- a/detections/application/suspicious_email_attachment_extensions.yml +++ b/detections/application/suspicious_email_attachment_extensions.yml @@ -26,7 +26,7 @@ how_to_implement: "You need to ingest data from emails. Specifically, the sender Delete\" can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, and add the correct hostname to the \"Phantom Instance\" field in the Adaptive Response - Actions when configuring this detection search. The notable event will be sent to + Actions when configuring this detection search. The finding event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox.'" diff --git a/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml b/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml index 70c74ac118..0ccbb9b85a 100644 --- a/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml +++ b/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml @@ -34,7 +34,7 @@ how_to_implement: You must install the latest version of Splunk Add-on for Micro known_false_positives: "False positives have been minimized by removing attempts that result in 'MFA successfully completed messages', which were found to be generated when a user opts to use a different MFA method than the default.\nFurther reductions - in notable events can be achieved through filtering 'MFA denied; duplicate authentication + in finding events can be achieved through filtering 'MFA denied; duplicate authentication attempt' messages within the auth_msg field, as they could arguably be considered as false positives." references: diff --git a/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml b/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml index 04e8be45b6..853d302d85 100644 --- a/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml +++ b/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml @@ -19,13 +19,11 @@ how_to_implement: "This search requires you to be ingesting web-traffic logs. Yo which contains a non-exhaustive list of dynamic DNS providers. Consider periodically updating this local lookup file with new domains.\nThis search produces fields (`isDynDNS`) that are not yet supported by ES Incident Review and therefore cannot be viewed - when a notable event is raised. These fields contribute additional context to the - notable. To see the additional metadata, add the following fields, if not already + when a finding event is raised. These fields contribute additional context to the + finding. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n* **Label:** IsDynamicDNS, **Field:** - isDynDNS\nDetailed documentation on how to create a new field within Incident Review - may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details` - Deprecated because duplicate." + isDynDNS\n Deprecated because duplicate." known_false_positives: It is possible that list of dynamic DNS providers is outdated and/or that the URL being requested is legitimate. references: [] diff --git a/detections/endpoint/batch_file_write_to_system32.yml b/detections/endpoint/batch_file_write_to_system32.yml index 8702c43326..b7fa5f29ff 100644 --- a/detections/endpoint/batch_file_write_to_system32.yml +++ b/detections/endpoint/batch_file_write_to_system32.yml @@ -30,7 +30,7 @@ how_to_implement: To successfully implement this search you need to be ingesting 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: It is possible for this search to generate a notable event +known_false_positives: It is possible for this search to generate a finding event for a batch file write to a path that includes the string "system32", but is not the actual Windows system directory. As such, you should confirm the path of the batch file identified by the search. In addition, a false positive may be generated diff --git a/detections/endpoint/common_ransomware_extensions.yml b/detections/endpoint/common_ransomware_extensions.yml index f13150655f..281a998ed1 100644 --- a/detections/endpoint/common_ransomware_extensions.yml +++ b/detections/endpoint/common_ransomware_extensions.yml @@ -27,8 +27,7 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_ how_to_implement: 'You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint Filesystem data model node. To see the additional metadata, add the following fields, if not already present, please review - the detailed documentation on how to create a new field within Incident Review may - be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`' + the detailed documentation on how to create a new field within Incident Review' known_false_positives: It is possible for a legitimate file with these extensions to be created. If this is a true ransomware attack, there will be a large number of files created with these extensions. diff --git a/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml b/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml index 3fd5724dd5..5062079c03 100644 --- a/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml +++ b/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml @@ -29,9 +29,9 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_ | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where source_count >= 4 | `linux_persistence_and_privilege_escalation_risk_behavior_filter`' how_to_implement: Ensure Linux anomaly and TTP analytics are enabled. TTP may be set - to Notables for point detections, anomaly should not be notables but risk generators. + to finding for point detections, anomaly should not be findings but risk generators. The correlation relies on more than x amount of distict detection names generated - before generating a notable. Modify the value as needed. Default value is set to + before generating a finding. Modify the value as needed. Default value is set to 4. This value may need to be increased based on activity in your environment. known_false_positives: False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers. diff --git a/detections/endpoint/powershell_start_or_stop_service.yml b/detections/endpoint/powershell_start_or_stop_service.yml index 01a0fa23c4..4779e1c10c 100644 --- a/detections/endpoint/powershell_start_or_stop_service.yml +++ b/detections/endpoint/powershell_start_or_stop_service.yml @@ -23,7 +23,7 @@ how_to_implement: To successfully implement this analytic, you will need to enab https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. known_false_positives: This behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, - it is recommended not to enable this analytic as a direct notable or TTP. Instead, + it is recommended not to enable this analytic as a direct finding Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats. references: diff --git a/detections/endpoint/windows_drivers_loaded_by_signature.yml b/detections/endpoint/windows_drivers_loaded_by_signature.yml index b5ebbbb517..7e3badca4e 100644 --- a/detections/endpoint/windows_drivers_loaded_by_signature.yml +++ b/detections/endpoint/windows_drivers_loaded_by_signature.yml @@ -23,8 +23,8 @@ how_to_implement: To successfully implement this search, you need to be ingestin 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. +known_false_positives: This analytic is meant to assist with identifying and hunting drivers loaded + in the environment. references: - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/ - https://attack.mitre.org/techniques/T1014/ diff --git a/detections/endpoint/windows_process_injection_with_public_source_path.yml b/detections/endpoint/windows_process_injection_with_public_source_path.yml index 02c9d32e09..6ff6638edb 100644 --- a/detections/endpoint/windows_process_injection_with_public_source_path.yml +++ b/detections/endpoint/windows_process_injection_with_public_source_path.yml @@ -25,7 +25,7 @@ how_to_implement: To successfully implement this search, you must be ingesting d in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. known_false_positives: Some security products or third party applications may utilize - CreateRemoteThread, filter as needed before enabling as a notable. + CreateRemoteThread, filter as needed. references: - https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/ tags: diff --git a/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml b/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml index 512144998e..d6193ca528 100644 --- a/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml +++ b/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml @@ -23,8 +23,7 @@ how_to_implement: To successfully implement this search, you need to be ingestin logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: This event is really notable but we found minimal number of - normal application from system32 folder like svchost.exe accessing it too. In this +known_false_positives: There are som minimal number of normal applications from system32 folder like svchost.exe accessing the MBR. In this case we used 'system32' and 'syswow64' path as a filter for this detection. references: - https://blog.talosintelligence.com/2022/02/threat-advisory-hermeticwiper.html diff --git a/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml b/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml index f5262cc967..3692033d81 100644 --- a/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml +++ b/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml @@ -23,8 +23,7 @@ how_to_implement: To successfully implement this search, you need to be ingestin logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. -known_false_positives: This event is really notable but we found minimal number of - normal application from system32 folder like svchost.exe accessing it too. In this +known_false_positives: There are som minimal number of normal applications from system32 folder like svchost.exe accessing the MBR. In this case we used 'system32' and 'syswow64' path as a filter for this detection. references: - https://www.splunk.com/en_us/blog/security/threat-advisory-strt-ta02-destructive-software.html diff --git a/detections/endpoint/windows_runmru_command_execution.yml b/detections/endpoint/windows_runmru_command_execution.yml index 83723be901..f673019307 100644 --- a/detections/endpoint/windows_runmru_command_execution.yml +++ b/detections/endpoint/windows_runmru_command_execution.yml @@ -35,7 +35,7 @@ known_false_positives: This detection may generate a few false positives, such a legitimate software updates or legitimate system maintenance activities that modify the RunMRU key. However, the exclusion of MRUList value changes helps reduce the number of false positives by focusing only on actual command entries. Add any specific - false positives to the built in filter to reduce notables as needed. + false positives to the built in filter to reduce findings as needed. references: - https://medium.com/@ahmed.moh.farou2/fake-captcha-campaign-on-arabic-pirated-movie-sites-delivers-lumma-stealer-4f203f7adabf - https://medium.com/@shaherzakaria8/downloading-trojan-lumma-infostealer-through-capatcha-1f25255a0e71 diff --git a/detections/endpoint/windows_system_file_on_disk.yml b/detections/endpoint/windows_system_file_on_disk.yml index 385415afd9..8550359fdd 100644 --- a/detections/endpoint/windows_system_file_on_disk.yml +++ b/detections/endpoint/windows_system_file_on_disk.yml @@ -24,7 +24,7 @@ how_to_implement: To successfully implement this search you need to be ingesting In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. In addition, filtering may occur by adding NOT (Filesystem.file_path IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", "system32\*")). - This will level out the noise generated to potentally lead to generating notables. + This will level out the noise generated to potentally lead to generating findings. known_false_positives: False positives will be present. Filter as needed. references: - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/ diff --git a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml index c8886d955a..c5f4d94b92 100644 --- a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml +++ b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml @@ -26,13 +26,12 @@ how_to_implement: "First, you'll need to ingest data from your DNS operations. T which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`.\n This search produces fields (query, answer, isDynDNS) that are not yet supported - by ES Incident Review and therefore cannot be viewed when a notable event is raised. - These fields contribute additional context to the notable event. To see the additional + by ES Incident Review and therefore cannot be viewed when a finding is raised. + These fields contribute additional context to the finding. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n* **Label:** DNS Query, **Field:** query\n* **Label:** DNS Answer, - **Field:** answer\n* **Label:** IsDynamicDNS, **Field:** isDynDNS\nDetailed documentation - on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`" + **Field:** answer\n* **Label:** IsDynamicDNS, **Field:** isDynDNS\n" known_false_positives: Some users and applications may leverage Dynamic DNS to reach out to some domains on the Internet since dynamic DNS by itself is not malicious, however this activity must be verified. diff --git a/detections/network/detect_outbound_smb_traffic.yml b/detections/network/detect_outbound_smb_traffic.yml index 3f581ed759..3a2cbf6989 100644 --- a/detections/network/detect_outbound_smb_traffic.yml +++ b/detections/network/detect_outbound_smb_traffic.yml @@ -30,7 +30,7 @@ how_to_implement: This search also requires you to be ingesting your network tra known_false_positives: It is likely that the outbound Server Message Block (SMB) traffic is legitimate, if the company's internal networks are not well-defined in the Assets and Identity Framework. Categorize the internal CIDR blocks as `internal` in the - lookup file to avoid creating notable events for traffic destined to those CIDR + lookup file to avoid creating findings for traffic destined to those CIDR blocks. Any other network connection that is going out to the Internet should be investigated and blocked. Best practices suggest preventing external communications of all SMB versions and related protocols at the network boundary. diff --git a/detections/network/dns_query_length_outliers___mltk.yml b/detections/network/dns_query_length_outliers___mltk.yml index 0aad3d7e34..629215e272 100644 --- a/detections/network/dns_query_length_outliers___mltk.yml +++ b/detections/network/dns_query_length_outliers___mltk.yml @@ -31,13 +31,12 @@ how_to_implement: "To successfully implement this search, you will need to ensur available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\nThis search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident - Review and therefore cannot be viewed when a notable event is raised. These fields - contribute additional context to the notable. To see the additional metadata, add + Review and therefore cannot be viewed when a finding event is raised. These fields + contribute additional context to the finding. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n * **Label:** DNS Query, **Field:** query\n* **Label:** DNS Query Length, **Field:** - query_length\n* **Label:** Number of events, **Field:** count\nDetailed documentation - on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`" + query_length\n* **Label:** Number of events, **Field:** count\n" known_false_positives: If you are seeing more results than desired, you may consider reducing the value for threshold in the search. You should also periodically re-run the support search to re-build the ML model on the latest data. diff --git a/detections/network/smb_traffic_spike___mltk.yml b/detections/network/smb_traffic_spike___mltk.yml index f8b5a6e950..0ec7d9fe16 100644 --- a/detections/network/smb_traffic_spike___mltk.yml +++ b/detections/network/smb_traffic_spike___mltk.yml @@ -31,12 +31,11 @@ how_to_implement: "To successfully implement this search, you will need to ensur should periodically re-run the support search to rebuild the model with the latest data available in your environment.\nThis search produces a field (Number of events,count) that are not yet supported by ES Incident Review and therefore cannot be viewed - when a notable event is raised. This field contributes additional context to the - notable. To see the additional metadata, add the following field, if not already + when a finding is raised. This field contributes additional context to the + finding. To see the additional metadata, add the following field, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n* **Label:** Number of events, **Field:** - count\nDetailed documentation on how to create a new field within Incident Review - is found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`" + count" known_false_positives: If you are seeing more results than desired, you may consider reducing the value of the threshold in the search. You should also periodically re-run the support search to re-build the ML model on the latest data. Please update diff --git a/detections/web/exploit_public_facing_application_via_apache_commons_text.yml b/detections/web/exploit_public_facing_application_via_apache_commons_text.yml index f9e9808237..d9b87dfcf0 100644 --- a/detections/web/exploit_public_facing_application_via_apache_commons_text.yml +++ b/detections/web/exploit_public_facing_application_via_apache_commons_text.yml @@ -33,7 +33,7 @@ how_to_implement: To implement, one must be collecting network traffic that is n and tie to a specific network source type to hunt in. Tune as needed, or remove the other_lookups statement. known_false_positives: False positives are present when the values are set to 1 for - utf and lookup. It's possible to raise this to TTP (direct notable) if removal of + utf and lookup. It's possible to raise this to TTP (direct finding) if removal of other_lookups occur and Score is raised to 2 (down from 4). references: - https://sysdig.com/blog/cve-2022-42889-text4shell/