mirror of
https://github.com/splunk/security_content
synced 2026-06-08 17:32:49 +00:00
Merge branch 'develop' of https://github.com/splunk/security_content into develop
This commit is contained in:
@@ -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/
|
||||
|
||||
Reference in New Issue
Block a user