Merge branch 'develop' of https://github.com/splunk/security_content into develop

This commit is contained in:
pyth0n1c
2025-01-24 17:09:21 -08:00
20 changed files with 32 additions and 40 deletions
@@ -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."
@@ -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.
@@ -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.'"
@@ -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:
@@ -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: []
@@ -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
@@ -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.
@@ -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.
@@ -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:
@@ -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/
@@ -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:
@@ -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
@@ -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
@@ -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
@@ -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/
@@ -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.
@@ -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.
@@ -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.
@@ -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
@@ -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/