mirror of
https://github.com/splunk/security_content
synced 2026-06-08 17:32:49 +00:00
@@ -971,7 +971,6 @@ def write_savedsearches_confv1(stories, detections, investigations, baselines, O
|
||||
output_file.write("alert.suppress.period = {0}\n"
|
||||
.format(detection['correlation_rule']['suppress']['suppress_period']))
|
||||
|
||||
output_file.write("is_visible = false\n")
|
||||
output_file.write("action.escu.earliest_time_offset = 3600\n")
|
||||
output_file.write("action.escu.latest_time_offset = 86400\n")
|
||||
output_file.write("disabled=true\n")
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#############
|
||||
# Automatically generated by generator.py in splunk/security-content
|
||||
# On Date: 2019-05-15T20:03:38 UTC
|
||||
# On Date: 2019-05-15T21:12:20 UTC
|
||||
# Author: Splunk Security Research
|
||||
# Contact: research@splunk.com
|
||||
#############
|
||||
@@ -232,7 +232,7 @@ investigative_searches = ["ESCU - Get Authentication Logs For Endpoint", "ESCU -
|
||||
support_searches = []
|
||||
data_models = ["Authentication", "Endpoint", "Network_Traffic", "Risk"]
|
||||
providing_technologies = ["Bro", "Carbon Black Response", "CrowdStrike Falcon", "Linux", "Microsoft Windows", "Splunk Enterprise Security", "Splunk Stream", "Sysmon", "Tanium", "Ziften", "macOS"]
|
||||
description = Monitor for and investigate activities--such as suspicious writes to the Windows Recycling Bin or email servers sending high amounts of traffic to specific hosts, for example--that may indicate that an adversary is harvesting and exfiltrating sensitive data.
|
||||
description = Monitor for and investigate activities--such as suspicious writes to the Windows Recycling Bin or email servers sending high amounts of traffic to specific hosts, for example--that may indicate that an adversary is harvesting and exfiltrating sensitive data.
|
||||
narrative = A common adversary goal is to identify and exfiltrate data of value from a target organization. This data may include email conversations and addresses, confidential company information, links to network design/infrastructure, important dates, and so on.\
|
||||
\
|
||||
Attacks are composed of three activities: identification, collection, and staging data for exfiltration. Identification typically involves scanning systems and observing user activity. Collection can involve the transfer of large amounts of data from various repositories. Staging/preparation includes moving data to a central location and compressing (and optionally encoding and/or encrypting) it. All of these activities provide opportunities for defenders to identify their presence. \
|
||||
@@ -270,7 +270,7 @@ investigative_searches = ["ESCU - Get Certificate logs for a domain"]
|
||||
support_searches = []
|
||||
data_models = ["Certificates", "Network_Resolution", "Web"]
|
||||
providing_technologies = ["Bro", "Censys", "Splunk Stream"]
|
||||
description = Detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. These websites are designed to fool unwitting users who have clicked on a malicious link in a phishing email.
|
||||
description = Detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. These websites are designed to fool unwitting users who have clicked on a malicious link in a phishing email.
|
||||
narrative = As most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Because phishing is a technique that relies on human psychology, you will never be able to eliminate this vulnerability 100%. But you can use automated detection to significantly reduce the risks.\
|
||||
\
|
||||
This Analytic Story focuses on detecting signs of MiTM attacks enabled by [EvilGinx2](https://github.com/kgretzky/evilginx2), a toolkit that sets up a transparent proxy between the targeted site and the user. In this way, the attacker is able to intercept credentials and two-factor identification tokens. It employs a proxy template to allow a registered domain to impersonate targeted sites, such as Linkedin, Amazon, Okta, Github, Twitter, Instagram, Reddit, Office 365, and others. It can even register SSL certificates and camouflage them via a URL shortener, making them difficult to detect. Searches in this story look for signs of MiTM attacks enabled by EvilGinx2.
|
||||
@@ -433,7 +433,7 @@ narrative = The trojan downloader known as Emotet first surfaced in 2014, when i
|
||||
\
|
||||
According to the TA, the the malware continues to be among the most costly and destructive malware affecting the private and public sectors. Researchers have linked it to the threat group Mealybug, which has also been on the security communitys radar since 2014.\
|
||||
\
|
||||
The searches in this Analytic Story will help you find executables that are rarely used in your environment, specific registry paths that malware often uses to ensure survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that Emotet or other malware has compromised your environment.
|
||||
The searches in this Analytic Story will help you find executables that are rarely used in your environment, specific registry paths that malware often uses to ensure survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that Emotet or other malware has compromised your environment.
|
||||
|
||||
[Hidden Cobra Malware]
|
||||
category = Malware
|
||||
@@ -604,10 +604,10 @@ investigative_searches = ["ESCU - Get Authentication Logs For Endpoint", "ESCU -
|
||||
support_searches = ["ESCU - Add Prohibited Processes to Enterprise Security", "ESCU - Monitor Successful Backups", "ESCU - Monitor Unsuccessful Backups", "ESCU - Windows Updates Install Failures", "ESCU - Windows Updates Install Successes"]
|
||||
data_models = ["Authentication", "Endpoint", "Risk", "Updates", "Vulnerabilities", "Web"]
|
||||
providing_technologies = ["Bluecoat", "Bro", "Carbon Black Response", "CrowdStrike Falcon", "Linux", "Microsoft Windows", "Nessus", "Netbackup", "Palo Alto Firewall", "Splunk Enterprise Security", "Splunk Stream", "Sysmon", "Tanium", "Ziften", "macOS"]
|
||||
description = Identify and investigate prohibited/unauthorized software or processes that may be concealing malicious behavior within your environment.
|
||||
description = Identify and investigate prohibited/unauthorized software or processes that may be concealing malicious behavior within your environment.
|
||||
narrative = It is critical to identify unauthorized software and processes running on enterprise endpoints and determine whether they are likely to be malicious. This Analytic Story requires the user to populate the Interesting Processes table within Enterprise Security with prohibited processes. An included support search will augment this data, adding information on processes thought to be malicious. This search requires data from endpoint detection-and-response solutions, endpoint data sources (such as Sysmon), or Windows Event Logs--assuming that the Active Directory administrator has enabled process tracking within the System Event Audit Logs.\
|
||||
\
|
||||
It is important to investigate any software identified as suspicious, in order to understand how it was installed or executed. Analyzing authentication logs or any historic notable events might elicit additional investigative leads of interest. For best results, schedule the search to run every two weeks.
|
||||
It is important to investigate any software identified as suspicious, in order to understand how it was installed or executed. Analyzing authentication logs or any historic notable events might elicit additional investigative leads of interest. For best results, schedule the search to run every two weeks.
|
||||
|
||||
[Monitor for Updates]
|
||||
category = Best Practices
|
||||
@@ -966,7 +966,7 @@ investigative_searches = ["ESCU - AWS Investigate User Activities By ARN", "ESCU
|
||||
support_searches = ["ESCU - Previously seen users in CloudTrail"]
|
||||
data_models = []
|
||||
providing_technologies = ["AWS", "Splunk Enterprise Security"]
|
||||
description = Monitor your AWS authentication events using your CloudTrail logs. Searches within this Analytic Story will help you stay aware of and investigate suspicious logins.
|
||||
description = Monitor your AWS authentication events using your CloudTrail logs. Searches within this Analytic Story will help you stay aware of and investigate suspicious logins.
|
||||
narrative = It is important to monitor and control who has access to your AWS infrastructure. Detecting suspicious logins to your AWS infrastructure will provide good starting points for investigations. Abusive behaviors caused by compromised credentials can lead to direct monetary costs, as you will be billed for any EC2 instances created by the attacker.
|
||||
|
||||
[Suspicious AWS S3 Activities]
|
||||
@@ -987,7 +987,7 @@ narrative = As cloud computing has exploded, so has the number of creative attac
|
||||
\
|
||||
Amazon's "shared responsibility" model dictates that the company has responsibility for the environment outside of the VM and the customer is responsible for the security inside of the S3 container. As such, it's important to stay vigilant for activities that may belie suspicious behavior inside of your environment.\
|
||||
\
|
||||
Among things to look out for are S3 access from unfamiliar locations and by unfamiliar users. Some of the searches in this Analytic Story help you detect suspicious behavior and others help you investigate more deeply, when the situation warrants.
|
||||
Among things to look out for are S3 access from unfamiliar locations and by unfamiliar users. Some of the searches in this Analytic Story help you detect suspicious behavior and others help you investigate more deeply, when the situation warrants.
|
||||
|
||||
[Suspicious AWS Traffic]
|
||||
category = Cloud Security
|
||||
@@ -1220,7 +1220,7 @@ investigative_searches = ["ESCU - Get Authentication Logs For Endpoint", "ESCU -
|
||||
support_searches = []
|
||||
data_models = ["Authentication", "Endpoint", "Risk"]
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Linux", "Microsoft Windows", "Splunk Enterprise Security", "Sysmon", "Tanium", "Ziften", "macOS"]
|
||||
description = Detect tactics used by malware to evade defenses on Windows endpoints. A few of these include suspicious `reg.exe` processes, files hidden with `attrib.exe` and disabling user-account control, among many others
|
||||
description = Detect tactics used by malware to evade defenses on Windows endpoints. A few of these include suspicious `reg.exe` processes, files hidden with `attrib.exe` and disabling user-account control, among many others
|
||||
narrative = Defense evasion is a tactic--identified in the MITRE ATT&CK framework--that adversaries employ in a variety of ways to bypass or defeat defensive security measures. There are many techniques enumerated by the MITRE ATT&CK framework that are applicable in this context. This Analytic Story includes searches designed to identify the use of such techniques on Windows platforms.
|
||||
|
||||
[Windows File Extension and Association Abuse]
|
||||
|
||||
@@ -5,5 +5,4 @@ chunked = true
|
||||
[runstory]
|
||||
filename = runstory.py
|
||||
chunked = true
|
||||
is_risky = true
|
||||
local = true
|
||||
is_risky = true
|
||||
+68
-227
File diff suppressed because it is too large
Load Diff
@@ -1,6 +1,6 @@
|
||||
#############
|
||||
# Automatically generated by generator.py in splunk/security-content
|
||||
# On Date: 2019-05-15T20:03:38 UTC
|
||||
# On Date: 2019-05-15T21:12:20 UTC
|
||||
# Author: Splunk Security Research
|
||||
# Contact: research@splunk.com
|
||||
#############
|
||||
@@ -177,7 +177,7 @@ references = ["https://attack.mitre.org/wiki/Collection", "https://attack.mitre.
|
||||
maintainers = [{"company": "Splunk", "email": "rvaldez@splunk.com", "name": "Rico Valdez"}]
|
||||
spec_version = 1
|
||||
searches = ["ESCU - Suspicious writes to windows Recycle Bin - Rule", "ESCU - Suspicious writes to System Volume Information - Rule", "ESCU - Email files written outside of the Outlook directory - Rule", "ESCU - Hosts receiving high volume of network traffic from email server - Rule", "ESCU - Email servers sending high volume traffic to hosts - Rule", "ESCU - Get Authentication Logs For Endpoint", "ESCU - Get Notable History", "ESCU - Get Notable Info", "ESCU - Get Parent Process Info", "ESCU - Get Process Info", "ESCU - Get Risk Modifiers For Endpoint", "ESCU - Get Risk Modifiers For User", "ESCU - Get User Information from Identity Table"]
|
||||
description = Monitor for and investigate activities--such as suspicious writes to the Windows Recycling Bin or email servers sending high amounts of traffic to specific hosts, for example--that may indicate that an adversary is harvesting and exfiltrating sensitive data.
|
||||
description = Monitor for and investigate activities--such as suspicious writes to the Windows Recycling Bin or email servers sending high amounts of traffic to specific hosts, for example--that may indicate that an adversary is harvesting and exfiltrating sensitive data.
|
||||
narrative = A common adversary goal is to identify and exfiltrate data of value from a target organization. This data may include email conversations and addresses, confidential company information, links to network design/infrastructure, important dates, and so on.\
|
||||
\
|
||||
Attacks are composed of three activities: identification, collection, and staging data for exfiltration. Identification typically involves scanning systems and observing user activity. Collection can involve the transfer of large amounts of data from various repositories. Staging/preparation includes moving data to a central location and compressing (and optionally encoding and/or encrypting) it. All of these activities provide opportunities for defenders to identify their presence. \
|
||||
@@ -205,7 +205,7 @@ references = ["https://github.com/kgretzky/evilginx2", "https://attack.mitre.org
|
||||
maintainers = [{"company": "Splunk", "email": "research@splunk.com", "name": "Splunk Research Team"}]
|
||||
spec_version = 2
|
||||
searches = ["ESCU - Detect DNS requests to Phishing Sites leveraging EvilGinx2 - Rule", "ESCU - Get Certificate logs for a domain"]
|
||||
description = Detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. These websites are designed to fool unwitting users who have clicked on a malicious link in a phishing email.
|
||||
description = Detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. These websites are designed to fool unwitting users who have clicked on a malicious link in a phishing email.
|
||||
narrative = As most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Because phishing is a technique that relies on human psychology, you will never be able to eliminate this vulnerability 100%. But you can use automated detection to significantly reduce the risks.\
|
||||
\
|
||||
This Analytic Story focuses on detecting signs of MiTM attacks enabled by [EvilGinx2](https://github.com/kgretzky/evilginx2), a toolkit that sets up a transparent proxy between the targeted site and the user. In this way, the attacker is able to intercept credentials and two-factor identification tokens. It employs a proxy template to allow a registered domain to impersonate targeted sites, such as Linkedin, Amazon, Okta, Github, Twitter, Instagram, Reddit, Office 365, and others. It can even register SSL certificates and camouflage them via a URL shortener, making them difficult to detect. Searches in this story look for signs of MiTM attacks enabled by EvilGinx2.
|
||||
@@ -328,7 +328,7 @@ narrative = The trojan downloader known as Emotet first surfaced in 2014, when i
|
||||
\
|
||||
According to the TA, the the malware continues to be among the most costly and destructive malware affecting the private and public sectors. Researchers have linked it to the threat group Mealybug, which has also been on the security communitys radar since 2014.\
|
||||
\
|
||||
The searches in this Analytic Story will help you find executables that are rarely used in your environment, specific registry paths that malware often uses to ensure survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that Emotet or other malware has compromised your environment.
|
||||
The searches in this Analytic Story will help you find executables that are rarely used in your environment, specific registry paths that malware often uses to ensure survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that Emotet or other malware has compromised your environment.
|
||||
|
||||
[analytic_story://Hidden Cobra Malware]
|
||||
category = Malware
|
||||
@@ -464,10 +464,10 @@ references = ["https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic
|
||||
maintainers = [{"company": "Splunk", "email": "davidd@splunk.com", "name": "David Dorsey"}]
|
||||
spec_version = 1
|
||||
searches = ["ESCU - Prohibited Software On Endpoint - Rule", "ESCU - Get Authentication Logs For Endpoint", "ESCU - Get Backup Logs For Endpoint", "ESCU - Get Notable History", "ESCU - Get Parent Process Info", "ESCU - Get Process Info", "ESCU - Get Process Information For Port Activity", "ESCU - Get Risk Modifiers For Endpoint", "ESCU - Get Risk Modifiers For User", "ESCU - Get Update Logs For Endpoint", "ESCU - Get User Information from Identity Table", "ESCU - Get Vulnerability Logs For Endpoint", "ESCU - Investigate Successful Remote Desktop Authentications", "ESCU - Investigate Web Activity From Host", "ESCU - Add Prohibited Processes to Enterprise Security", "ESCU - Monitor Successful Backups", "ESCU - Monitor Unsuccessful Backups", "ESCU - Windows Updates Install Failures", "ESCU - Windows Updates Install Successes"]
|
||||
description = Identify and investigate prohibited/unauthorized software or processes that may be concealing malicious behavior within your environment.
|
||||
description = Identify and investigate prohibited/unauthorized software or processes that may be concealing malicious behavior within your environment.
|
||||
narrative = It is critical to identify unauthorized software and processes running on enterprise endpoints and determine whether they are likely to be malicious. This Analytic Story requires the user to populate the Interesting Processes table within Enterprise Security with prohibited processes. An included support search will augment this data, adding information on processes thought to be malicious. This search requires data from endpoint detection-and-response solutions, endpoint data sources (such as Sysmon), or Windows Event Logs--assuming that the Active Directory administrator has enabled process tracking within the System Event Audit Logs.\
|
||||
\
|
||||
It is important to investigate any software identified as suspicious, in order to understand how it was installed or executed. Analyzing authentication logs or any historic notable events might elicit additional investigative leads of interest. For best results, schedule the search to run every two weeks.
|
||||
It is important to investigate any software identified as suspicious, in order to understand how it was installed or executed. Analyzing authentication logs or any historic notable events might elicit additional investigative leads of interest. For best results, schedule the search to run every two weeks.
|
||||
|
||||
[analytic_story://Monitor for Updates]
|
||||
category = Best Practices
|
||||
@@ -751,7 +751,7 @@ references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integ
|
||||
maintainers = [{"company": "Splunk", "email": "bpatel@splunk.com", "name": "Bhavin Patel"}]
|
||||
spec_version = 1
|
||||
searches = ["ESCU - Detect new user AWS Console Login - Rule", "ESCU - AWS Investigate User Activities By ARN", "ESCU - Get Notable History", "ESCU - Get Notable Info", "ESCU - Get User Information from Identity Table", "ESCU - Previously seen users in CloudTrail"]
|
||||
description = Monitor your AWS authentication events using your CloudTrail logs. Searches within this Analytic Story will help you stay aware of and investigate suspicious logins.
|
||||
description = Monitor your AWS authentication events using your CloudTrail logs. Searches within this Analytic Story will help you stay aware of and investigate suspicious logins.
|
||||
narrative = It is important to monitor and control who has access to your AWS infrastructure. Detecting suspicious logins to your AWS infrastructure will provide good starting points for investigations. Abusive behaviors caused by compromised credentials can lead to direct monetary costs, as you will be billed for any EC2 instances created by the attacker.
|
||||
|
||||
[analytic_story://Suspicious AWS S3 Activities]
|
||||
@@ -767,7 +767,7 @@ narrative = As cloud computing has exploded, so has the number of creative attac
|
||||
\
|
||||
Amazon's "shared responsibility" model dictates that the company has responsibility for the environment outside of the VM and the customer is responsible for the security inside of the S3 container. As such, it's important to stay vigilant for activities that may belie suspicious behavior inside of your environment.\
|
||||
\
|
||||
Among things to look out for are S3 access from unfamiliar locations and by unfamiliar users. Some of the searches in this Analytic Story help you detect suspicious behavior and others help you investigate more deeply, when the situation warrants.
|
||||
Among things to look out for are S3 access from unfamiliar locations and by unfamiliar users. Some of the searches in this Analytic Story help you detect suspicious behavior and others help you investigate more deeply, when the situation warrants.
|
||||
|
||||
[analytic_story://Suspicious AWS Traffic]
|
||||
category = Cloud Security
|
||||
@@ -940,7 +940,7 @@ references = ["https://attack.mitre.org/wiki/Defense_Evasion"]
|
||||
maintainers = [{"company": "Splunk", "email": "davidd@splunk.com", "name": "David Dorsey"}]
|
||||
spec_version = 1
|
||||
searches = ["ESCU - Suspicious Reg.exe Process - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Hiding Files And Directories With Attrib.exe - Rule", "ESCU - Reg.exe used to hide files/directories via registry keys - Rule", "ESCU - Remote Registry Key modifications - Rule", "ESCU - Get Authentication Logs For Endpoint", "ESCU - Get Notable History", "ESCU - Get Notable Info", "ESCU - Get Parent Process Info", "ESCU - Get Process Info", "ESCU - Get Risk Modifiers For Endpoint", "ESCU - Get Risk Modifiers For User", "ESCU - Get User Information from Identity Table"]
|
||||
description = Detect tactics used by malware to evade defenses on Windows endpoints. A few of these include suspicious `reg.exe` processes, files hidden with `attrib.exe` and disabling user-account control, among many others
|
||||
description = Detect tactics used by malware to evade defenses on Windows endpoints. A few of these include suspicious `reg.exe` processes, files hidden with `attrib.exe` and disabling user-account control, among many others
|
||||
narrative = Defense evasion is a tactic--identified in the MITRE ATT&CK framework--that adversaries employ in a variety of ways to bypass or defeat defensive security measures. There are many techniques enumerated by the MITRE ATT&CK framework that are applicable in this context. This Analytic Story includes searches designed to identify the use of such techniques on Windows platforms.
|
||||
|
||||
[analytic_story://Windows File Extension and Association Abuse]
|
||||
@@ -1464,7 +1464,7 @@ providing_technologies = ["Bro", "Splunk Stream"]
|
||||
|
||||
[savedsearch://ESCU - Detect Path Interception By Creation Of program.exe - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = This search queries the Endpoint file-system data model node to list out all the values of destination machines, as well as the values of file hashes and file paths that have the file "program.exe" in the C: drive. Path interception occurs when an executable is placed in a specific path so that it is executed by an application instead of by the intended target. In this case, applications vulnerable to path interception (because of unquoted service paths with spaces in Windows registry) allow attackers to execute maliciously crafted program.exes.
|
||||
how_to_implement = You must be ingesting data that records the file-system activity from your hosts to populate the Endpoint file-system data model node. This is typically populated via endpoint detection-and-response products, such as Carbon Black, or other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report file system reads and writes.
|
||||
@@ -1506,7 +1506,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon
|
||||
type = detection
|
||||
asset_type = S3 Bucket
|
||||
confidence = low
|
||||
explanation = Here the subsearch executes first and returns all successful S3 bucket-access attempts (HTTP code "200") within the last hour. It groups the results by the earliest and latest times it has seen a remote IP accessing a particular bucket. It appends this information to the historical data from the lookup file and then recalculates the `firstTime` and `lastTime` field for each remote IP accessing an S3 bucket. Next, it returns only those remote IP addresses that have first been seen accessing a specific bucket within the past hour. This is combined with the main search to return the time, bucket name, source IP, city, and country operations performed, as well as the requested URI of the resource
|
||||
explanation = Here the subsearch executes first and returns all successful S3 bucket-access attempts (HTTP code "200") within the last hour. It groups the results by the earliest and latest times it has seen a remote IP accessing a particular bucket. It appends this information to the historical data from the lookup file and then recalculates the `firstTime` and `lastTime` field for each remote IP accessing an S3 bucket. Next, it returns only those remote IP addresses that have first been seen accessing a specific bucket within the past hour. This is combined with the main search to return the time, bucket name, source IP, city, and country operations performed, as well as the requested URI of the resource
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your S3 access logs' inputs. This search works best when you run the "Previously Seen S3 Bucket Access by Remote IP" support search once to create a history of previously seen remote IPs and bucket names.
|
||||
annotations = {"mitre_attack": ["Execution", "Exfiltration"], "kill_chain_phases": ["Actions on Objectives"], "cis20": ["CIS 13", "CIS 14"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||||
known_false_positives = S3 buckets can be accessed from any IP, as long as it can make a successful connection. This will be a false postive, since the search is looking for a new IP within the past hour
|
||||
@@ -1541,7 +1541,7 @@ explanation = This search and its corresponding subsearch run through a series o
|
||||
1. Filters out anything that it determines is not a spike and returns the list of ARNs to the main search. The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike.
|
||||
annotations = {"mitre_attack": ["Credential Access", "Execution"], "kill_chain_phases": ["Actions on Objectives"], "cis20": ["CIS 16"], "nist": ["DE.DP", "DE.CM", "PR.AC"]}
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Detect Spike in Network ACL Activity - Rule]
|
||||
@@ -1960,12 +1960,12 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon
|
||||
|
||||
[savedsearch://ESCU - Hiding Files And Directories With Attrib.exe - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = This search is looking to detect command-line execution with of attrib.exe binary with the +h flag set. The +h flag is used to hide a file.
|
||||
how_to_implement = You must be ingesting data that records process activity from your hosts to populate the Endpoint data model in the Processes node. You must also be ingesting logs with both the process name and command line from your endpoints. The command-line arguments are mapped to the "process" field in the Endpoint data model.
|
||||
annotations = {"mitre_attack": ["Defense Evasion", "Persistence"], "kill_chain_phases": ["Actions on Objectives"], "cis20": ["CIS 8"], "nist": ["DE.CM"]}
|
||||
known_false_positives = Some applications and users may legitimately use attrib.exe to interact with the files.
|
||||
known_false_positives = Some applications and users may legitimately use attrib.exe to interact with the files.
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon", "Tanium", "Ziften"]
|
||||
|
||||
[savedsearch://ESCU - Hosts receiving high volume of network traffic from email server - Rule]
|
||||
@@ -2220,7 +2220,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon
|
||||
|
||||
[savedsearch://ESCU - Reg.exe used to hide files/directories via registry keys - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = Reg.exe is a binary native to Windows platform used to edit the registry hives of the system. Attackers can leverage this binary to hide files by passing in arguments that are used to hide the files. In the search, we first gather results with keywords, add, Hidden, and REG_DWORD, that will be in the raw event and filter by process and the command-line. We then leverage regular expressions on the command-line field to look for /d value as 2 which is responsible for hiding a file or directory.
|
||||
how_to_implement = You must be ingesting data that records process activity from your hosts to populate the Endpoint data model in the Processes node. You must also be ingesting logs with both the process name and command line from your endpoints. The command-line arguments are mapped to the "process" field in the Endpoint data model.
|
||||
@@ -2560,7 +2560,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon
|
||||
|
||||
[savedsearch://ESCU - Suspicious wevtutil Usage - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = This search looks for execution of wevtutil.exe with command-line arguments that indicate that it has been used to delete the setup, application, security, or system event logs. The search returns the number of times the behavior was observed, the first and last time it was seen, the host exhibiting the behavior and the user context of the process execution.
|
||||
how_to_implement = You must be ingesting data that records process activity from your hosts to populate the Endpoint data model in the Processes node. You must also be ingesting logs with both the process name and command line from your endpoints. The command-line arguments are mapped to the "process" field in the Endpoint data model.
|
||||
@@ -2640,7 +2640,7 @@ providing_technologies = ["Netbackup"]
|
||||
|
||||
[savedsearch://ESCU - Unusually Long Command Line - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = This search calculates the average and standard deviation for the length of the command lines on each of your endpoints and alerts when it detects a command line with a length over 10 times the standard deviation larger than the average command line.
|
||||
how_to_implement = You must be ingesting endpoint data that tracks process activity, including parent-child relationships, from your endpoints to populate the Endpoint data model in the Processes node. The command-line arguments are mapped to the "process" field in the Endpoint data model.
|
||||
@@ -2650,7 +2650,7 @@ providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon
|
||||
|
||||
[savedsearch://ESCU - Unusually Long Command Line - MLTK - Rule]
|
||||
type = detection
|
||||
asset_type =
|
||||
asset_type =
|
||||
confidence = medium
|
||||
explanation = This search leverages the Machine Learning Toolkit (MLTK) to identify outliers in the length of the command lines observed to be used by a specific user. The companion search, "Baseline of Command Line Length - MLTK," creates a machine-learning (ML) model built over the historical data used by this search.
|
||||
how_to_implement = You must be ingesting endpoint data that monitors command lines and populates the Endpoint data model in the Processes node. The command-line arguments are mapped to the "process" field in the Endpoint data model. In addition, MLTK version >= 4.2 must be installed on your search heads, along with any required dependencies. Finally, the support search "Baseline of Command Line Length - MLTK" must be executed before this detection search, as it builds an ML model over the historical data used by this search.
|
||||
@@ -3174,238 +3174,238 @@ latest_time_offset = 3600
|
||||
type = support
|
||||
explanation = This search outputs the interesting processes lookup table and filters out all processes in the table that haven't already been inserted by ESCU. It then appends to those results all the processes currently identified by ESCU that should be prohibited. Next, it fills in the required fields with processes identified by ESCU, and then writes the results back to the interesting process lookup table. This is done so any new processes identified that should be prohibited will be added to the lookup table without creating any duplicate entries.
|
||||
how_to_implement = This search should be run on each new install of ESCU.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Enterprise Security"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of API Calls per User ARN]
|
||||
type = support
|
||||
explanation = This search returns all log events that are API calls, pulls out the ARN that initiated each call, and collects them in one-hour groupings. Next, it calculates the number of API calls made per ARN per hour. For each ARN, it calculates the average and standard deviation of this count on a per-hour basis. It also includes the number of data points each ARN had. This table is then stored in a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of Command Line Length- MLTK]
|
||||
type = support
|
||||
explanation = Create a machine-learning (ML) model to characterize the length of the command lines used in your environment. This can help you identify unusually long ones that may indicate that attackers are executing commands on yout systems.
|
||||
how_to_implement = You must be ingesting endpoint data and populating the Endpoint data model. In addition, you must have the Machine Learning Toolkit (MLTK) version >= 4.2 installed, along with any required dependencies. Depending on the number of users in your environment, you may also need to adjust the value for max_inputs in the MLTK settings for the DensityFunction algorithm, then ensure that the search completes in a reasonable timeframe. By default, the search builds the model using the past 30 days of data. You can modify the search window to build the model over a longer period of time, which may give you better results. You may also want to periodically re-run this search to rebuild the model with the latest data.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon", "Tanium", "Ziften"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of DNS Query Length - MLTK]
|
||||
type = support
|
||||
explanation = Create a machine-learning (ML) model to characterize the length of DNS requests seen in your environment to help identify unusually long ones that may be indicative of attacker infrastrucutre or the use of DNS as a command-and-control channel in your environment.
|
||||
how_to_implement = To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, you must have the Machine Learning Toolkit (MLTK) version >= 4.2 installed, along with any required dependencies. By default, the search builds the model using the past 30 days of data. You can modify the search window to build the model over a longer period of time, which may give you better results. You may also want to periodically re-run this search to rebuild the model with the latest data.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of Network ACL Activity by ARN]
|
||||
type = support
|
||||
explanation = Use this search to create a baseline for API calls related to network ACLs for the users who initiated this activity. It returns all logged API calls for network activity, pulls out the ARN that initiated each call, and collects the `eventNames` in one-hour groupings. Next, it calculates the number of API calls made per ARN per-hour. For each ARN, it calculates the average and standard deviation of this count on a per-hour basis. It also includes the number of data points for each ARN. This table is stored in a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs. To add or remove API event names for network ACLs, edit the macro `NetworkACLEvents`.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of S3 Bucket deletion activity by ARN]
|
||||
type = support
|
||||
explanation = Use this search to create a baseline for API calls related to deleting an S3 bucket, grouped by the users who initiated this activity. It returns all logged API calls for S3 bucket-deletion activity and then pulls out the ARN that initiated each call. Next, it calculates the number of API calls made per ARN per hour. For each ARN, it calculates the average and standard deviation of this count on a per-hour basis. It also includes the number of data points for each ARN. This table is stored in a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of SMB Traffic - MLTK]
|
||||
type = support
|
||||
explanation = Create a machine-learning (ML) model to characterize the number of SMB connections observed in your environment. This may help identify spikes in SMB traffic that may be indicative of attackers scanning or attempting to propagate to other systems in your environment. By default, this model is built over 30 days of data and profiles the number of SMB connections in your environment by the hour of day/day of week that the connections occur.
|
||||
how_to_implement = You must be ingesting network traffic and populating the Network_Traffic data model. In addition, you must have the Machine Learning Toolkit (MLTK) version >= 4.2 installed, along with any required dependencies. To improve your results, you may consider adding "src" to the by clause, which will build the model for each unique source in your enviornment. However, if you have a large number of hosts in your environment, this search may be very resource intensive. In this case, you may need to raise the value of max_inputs and/or max_groups in the MLTK settings for the DensityFunction algorithm, then ensure that the search completes in a reasonable timeframe. By default, the search builds the model using the past 30 days of data. You can modify the search window to build the model over a longer period of time, which may give you better results. You may also want to periodically re-run this search to rebuild the model with the latest data.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of Security Group Activity by ARN]
|
||||
type = support
|
||||
explanation = Use this search to create a baseline for API calls related to security groups by the users who initiated this activity. It returns all logged API calls for all security-group-related activity, pulls out the ARN that initiated each call, and collects the `eventNames` in one-hour groupings. Next, it calculates the number of API calls made per ARN per hour. For each ARN, it calculates the average and standard deviation of this count on a per-hour basis. It also includes the number of data points for each ARN. This table is stored in a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs. To add or remove API event names for security groups, edit the macro `securityGroupAPIs`.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Baseline of blocked outbound traffic from AWS]
|
||||
type = support
|
||||
explanation = Use this search to create a baseline of blocked outbound network connections by each source IP in your AWS environment. This search returns all log events that correspond to a blocked outbound network connection, extracts the source IP from where the outbound connection was initiated, and collects the events in one-hour groupings. Next, it calculates the number of outbound connections blocked per hour. For each source IP, it calculates the average and standard deviation of this count on a per-hour basis. It also includes the number of data points each source IP had. This table is then stored in a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your `VPC flow logs.`.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Count of Unique IPs Connecting to Ports]
|
||||
type = support
|
||||
explanation = For each port being accessed on the network, this search gives the total number of connections observed, and the number of unique IP addresses making those connections.
|
||||
how_to_implement = To successfully implement this search, you must be ingesting network traffic, and populating the Network_Traffic data model.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Count of assets by category]
|
||||
type = support
|
||||
explanation = This search gives you the number and the names of the hosts of each host in your environment by category. It will then sort them by the count.
|
||||
how_to_implement = To successfully implement this search you must first leverage the Assets and Identity framework in Enterprise Security to populate your assets_by_str.csv file which should then be mapped to the Identity_Management data model. The Identity_Management data model will contain a list of known authorized company assets. Ensure that all inventoried systems are constantly vetted and updated.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Enterprise Security"]
|
||||
|
||||
[savedsearch://ESCU - Create a list of approved AWS service accounts]
|
||||
type = support
|
||||
explanation = We first look for all successful CloudTrail API activity caused by types of user accounts and then remove all the events caused by users in the Identity table. This generates a list of accounts--typically service accounts--configured in your AWS environment. We output this list of service accounts to `aws_service_accounts.csv`.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Please validate the service account entires in `aws_service_accounts.csv`, which is a lookup file created as a result of running this support search. Please remove the entries of service accounts that are not legitimate.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - DNSTwist Domain Names]
|
||||
type = support
|
||||
explanation = This search starts with the dnstwist command consuming domains from a file called domains.csv in the DA-ESS-SOC/lookups directory. This search then adds a domain\_abuse=true term to each permutation, removes all the valid domain names and stores all that information into a lookup file that is used in the associated detection search. Alternatively domain dnstwist permutations can be calculated from domains in the `cim_corporate_email_domains.csv` and `cim_corporate_web_domains.csv` lookups located in **Splunk\_SA\_CIM** using argument `populate_from_cim=true`. Also an individual domain can be passed using argument `domain=<domain>`
|
||||
how_to_implement = To successfully implement this search you need to update the file called domains.csv in the DA-ESS-SOC/lookup directory. Or `cim_corporate_email_domains.csv` and `cim_corporate_web_domains.csv` from **Splunk\_SA\_CIM**.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Enterprise"]
|
||||
|
||||
[savedsearch://ESCU - Discover DNS records]
|
||||
type = support
|
||||
explanation = Discover the DNS records and their answers for domains owned by the company using network traffic events. The discovered events are exported as a lookup named `discovered_dns_records.csv`
|
||||
how_to_implement = To successfully implement this search, you must be ingesting DNS logs, and populating the Network_Resolution data model. Also make sure that the cim_corporate_web_domains and cim_corporate_email_domains lookups are populated with the domains owned by your corporation
|
||||
known_false_positives = Please vet the lookup created by this baseline search
|
||||
known_false_positives = Please vet the lookup created by this baseline search
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Identify Systems Creating Remote Desktop Traffic]
|
||||
type = support
|
||||
explanation = This search counts the numbers of times the system has tried to connect to another system on TCP/3389, the default port used for RDP traffic.
|
||||
how_to_implement = To successfully implement this search, you must ingest network traffic and populate the Network_Traffic data model.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Identify Systems Receiving Remote Desktop Traffic]
|
||||
type = support
|
||||
explanation = This search counts the numbers of times the system has received a connection to TCP/ 3389, the default port used for RDP traffic.
|
||||
how_to_implement = To successfully implement this search you must ingest network traffic and populate the Network_Traffic data model. If a system receives a lot of remote desktop traffic, you can apply the category common_rdp_destination to it.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Splunk Stream", "Bro"]
|
||||
|
||||
[savedsearch://ESCU - Identify Systems Using Remote Desktop]
|
||||
type = support
|
||||
explanation = This search counts the numbers of times the remote desktop process, mstsc.exe, has run on each system. It does this by looking for the process name in the Endpoint data model.
|
||||
how_to_implement = To successfully implement this search you must be ingesting endpoint data that records process activity.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon", "Tanium", "Ziften"]
|
||||
|
||||
[savedsearch://ESCU - Monitor Successful Backups]
|
||||
type = support
|
||||
explanation = This search gives you the count and the hostname of all the systems that had a successful backup each day.
|
||||
how_to_implement = To successfully implement this search you must be ingesting your backup logs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Netbackup"]
|
||||
|
||||
[savedsearch://ESCU - Monitor Unsuccessful Backups]
|
||||
type = support
|
||||
explanation = This search gives you the count and hostname of all the systems that had a backup failure each day
|
||||
how_to_implement = To successfully implement this search you must be ingesting your backup logs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Netbackup"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen AWS Cross Account Activity]
|
||||
type = support
|
||||
explanation = In this support search, we look for **AssumeRole** events where the requesting account is different from the requested account. The first and last times these events are seen are written to a lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Validate the user name entries in `previously_seen_aws_cross_account_activity.csv`, a lookup file created by this support search.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen AWS Provisioning Activity Sources]
|
||||
type = support
|
||||
explanation = This search includes any event name that begins with "run" or "create," and then determines the first and last time these events were seen for each IP address that initiated the action. The search then consults a **GeoIP** database to determine the physical location of this IP address. This table outputs to a file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen AWS Regions]
|
||||
type = support
|
||||
explanation = In this support search, we create a table of the first time (earliest) and most recent time (latest) that this region has been seen in our dataset, grouped by the value `awsRegion`. We only look for those events where an instance has been started. All of these entries will be added to the `previously_seen_aws_regions.csv` lookup file, which will act like a baseline for detections. Please validate the entries of region names in the lookup file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen EC2 AMIs]
|
||||
type = support
|
||||
explanation = In this support search, we create a table of the earliest and latest time that a specific AMI ID has been seen. This table is then outputted to a csv file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen EC2 Instance Types]
|
||||
type = support
|
||||
explanation = In this support search, we create a table of the earliest and latest time that a specific EC2 instance type has been seen. The instanceType request field is not required and defaults to m1.small, so any time this field is null, the search defaults the field to m1.small. This table is then outputted to a csv file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen EC2 Launches By User]
|
||||
type = support
|
||||
explanation = In this support search, we create a table of the earliest and latest times that an ARN has launched a EC2 instance. This table is then outputted to a csv file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen EC2 Modifications By User]
|
||||
type = support
|
||||
explanation = In this support search, we create a table of the earliest and latest times that an ARN has modified a EC2 instance. The list of APIs that modify an EC2 are defined in the `ec2ModificationAPIs` macro for ease of use. This table is then outputted to a file.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS version (4.4.0 or later), then configure your CloudTrail inputs. To add or remove APIs that modify an EC2 instance, edit the macro `ec2ModificationAPIs`.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously Seen Running Windows Services]
|
||||
type = support
|
||||
explanation = In this support search, we look for Windows system-event code that indicates a status change of a Windows service. It extracts both the name of the service and the action taken by the service from the logs. It keeps only services that have entered the running state. Finally, it finds the first time the service has been seen running across the enterprise and writes that file to a lookup table.
|
||||
how_to_implement = While this search does not require you to adhere to Splunk CIM, you must be ingesting your Windows security-event logs for it to execute successfully.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Microsoft Windows"]
|
||||
|
||||
[savedsearch://ESCU - Previously seen API call per user roles in CloudTrail]
|
||||
type = support
|
||||
explanation = In this support search, we are looking for successful API calls made by user roles within your AWS infrastructure. The intent is to create an initial baseline cache of names of the API calls per security role for the previous 30 days--including the earliest and latest times seen in our dataset--grouped by the value of user role and the name of the API call. It is also worth noting that the role of a particular user is parsed as "userName" in the CloudTrail logs.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Please validate the user role entries in `previously_seen_api_calls_from_user_roles.csv`, which is a lookup file created as a result of running this support search.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously seen S3 bucket access by remote IP]
|
||||
type = support
|
||||
explanation = In this support search, we are looking for successful S3 bucket-access attempts made from remote IPs. The intent is to create an initial baseline cache of remote IP addresses per bucket name for the previous 30 days--including the earliest and latest times seen in our dataset--grouped by the value of remote IP and the name of the S3 bucket.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your S3 access-logs inputs. You must validate the remote IP and bucket name entries in `previously_seen_S3_access_from_remote_ip.csv`, which is a lookup file created as a result of running this support search.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Previously seen command line arguments]
|
||||
type = support
|
||||
explanation = In this support search, we look for command-line arguments using the parameter `/c` to execute processes and create an initial baseline cache for the previous 30 days. This will include the earliest and latest times a particular command-line argument is seen in our dataset, grouped by the command-line value.
|
||||
how_to_implement = You must be ingesting data that records process activity from your hosts to populate the Endpoint data model in the Processes node. You must be ingesting logs with both the process name and command line from your endpoints. The complete process name with command-line arguments are mapped to the "process" field in the Endpoint data model.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon", "Tanium", "Ziften"]
|
||||
|
||||
[savedsearch://ESCU - Previously seen users in CloudTrail]
|
||||
type = support
|
||||
explanation = In this support search, we look for console login events by a particular user and create an initial baseline cache for the previous seven days, including the earliest and latest times a particular user ARN is seen in our dataset, grouped by the ARN value.
|
||||
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Please validate the user name entries in `previously_seen_users_console_logins.csv`, which is a lookup file created as a result of running this support search.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["AWS"]
|
||||
|
||||
[savedsearch://ESCU - Systems Ready for Spectre-Meltdown Windows Patch]
|
||||
type = support
|
||||
explanation = This search looks to see if a registry key was created at `HKLM\Software\Microsoft\Windows\CurrentVersion\QualityCompat`. It will tell you when it was created and, if possible, what process created it.
|
||||
how_to_implement = You need to be ingesting logs with both the process name and command-line from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Carbon Black Response", "CrowdStrike Falcon", "Sysmon", "Tanium", "Ziften"]
|
||||
|
||||
[savedsearch://ESCU - Windows Updates Install Failures]
|
||||
type = support
|
||||
explanation = This search gives you the count of the number of systems that attempted and failed to install a Windows update each day.
|
||||
how_to_implement = You must be ingesting your Windows Update Logs
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Microsoft Windows"]
|
||||
|
||||
[savedsearch://ESCU - Windows Updates Install Successes]
|
||||
type = support
|
||||
explanation = This search gives you the count and name of all the systems that had a successful update applied each day
|
||||
how_to_implement = You must be ingesting your Windows Update Logs
|
||||
known_false_positives =
|
||||
known_false_positives =
|
||||
providing_technologies = ["Microsoft Windows"]
|
||||
|
||||
### END BASELINES ###
|
||||
Reference in New Issue
Block a user