mirror of
https://github.com/splunk/security_content
synced 2026-06-08 17:32:49 +00:00
research bot
805 lines
77 KiB
Plaintext
805 lines
77 KiB
Plaintext
#############
|
||
# Automatically generated by generator.py in splunk/security_content
|
||
# On Date: 2021-08-18T16:28:20 UTC
|
||
# Author: Splunk Security Research
|
||
# Contact: research@splunk.com
|
||
#############
|
||
|
||
### STORIES ###
|
||
|
||
[analytic_story://AWS IAM Privilege Escalation]
|
||
category = Cloud Security
|
||
last_updated = 2021-03-08
|
||
version = 1
|
||
references = ["https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/", "https://www.cyberark.com/resources/threat-research-blog/the-cloud-shadow-admin-threat-10-permissions-to-protect", "https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Create Policy Version to allow all resources - Rule", "ESCU - AWS CreateAccessKey - Rule", "ESCU - AWS CreateLoginProfile - Rule", "ESCU - AWS IAM Assume Role Policy Brute Force - Rule", "ESCU - AWS IAM Delete Policy - Rule", "ESCU - AWS IAM Failure Group Deletion - Rule", "ESCU - AWS IAM Successful Group Deletion - Rule", "ESCU - AWS SetDefaultPolicyVersion - Rule", "ESCU - AWS UpdateLoginProfile - Rule"]
|
||
description = This analytic story contains detections that query your AWS Cloudtrail for activities related to privilege escalation.
|
||
narrative = Amazon Web Services provides a neat feature called Identity and Access Management (IAM) that enables organizations to manage various AWS services and resources in a secure way. All IAM users have roles, groups and policies associated with them which governs and sets permissions to allow a user to access specific restrictions.\
|
||
However, if these IAM policies are misconfigured and have specific combinations of weak permissions; it can allow attackers to escalate their privileges and further compromise the organization. Rhino Security Labs have published comprehensive blogs detailing various AWS Escalation methods. By using this as an inspiration, Splunk’s research team wants to highlight how these attack vectors look in AWS Cloudtrail logs and provide you with detection queries to uncover these potentially malicious events via this Analytic Story. \
|
||
|
||
[analytic_story://AWS Network ACL Activity]
|
||
category = Cloud Security
|
||
last_updated = 2018-05-21
|
||
version = 2
|
||
references = ["https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html", "https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - AWS Network ACL Details from ID - Rule", "ESCU - AWS Network Access Control List Created with All Open Ports - Rule", "ESCU - AWS Network Access Control List Deleted - Rule", "ESCU - AWS Network Interface details via resourceId - Rule", "ESCU - Get All AWS Activity From IP Address - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS Network ACL Details from ID - Response Task", "ESCU - AWS Network Interface details via resourceId - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task"]
|
||
description = Monitor your AWS network infrastructure for bad configurations and malicious activity. Investigative searches help you probe deeper, when the facts warrant it.
|
||
narrative = AWS CloudTrail is an AWS service that helps you enable governance, compliance, and operational/risk auditing of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. It is crucial for a company to monitor events and actions taken in the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs to ensure that your servers are not vulnerable to attacks. This analytic story contains detection searches that leverage CloudTrail logs from AWS to check for bad configurations and malicious activity in your AWS network access controls.
|
||
|
||
[analytic_story://AWS Security Hub Alerts]
|
||
category = Cloud Security
|
||
last_updated = 2020-08-04
|
||
version = 1
|
||
references = ["https://aws.amazon.com/security-hub/features/"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - Detect Spike in AWS Security Hub Alerts for EC2 Instance - Rule", "ESCU - Get EC2 Instance Details by instanceId - Rule", "ESCU - Get EC2 Launch Details - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task"]
|
||
description = This story is focused around detecting Security Hub alerts generated from AWS
|
||
narrative = AWS Security Hub collects and consolidates findings from AWS security services enabled in your environment, such as intrusion detection findings from Amazon GuardDuty, vulnerability scans from Amazon Inspector, S3 bucket policy findings from Amazon Macie, publicly accessible and cross-account resources from IAM Access Analyzer, and resources lacking WAF coverage from AWS Firewall Manager.
|
||
|
||
[analytic_story://Cloud Cryptomining]
|
||
category = Cloud Security
|
||
last_updated = 2019-10-02
|
||
version = 1
|
||
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate Security Hub alerts by dest - Rule", "ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - Abnormally High Number Of Cloud Instances Launched - Rule", "ESCU - Cloud Compute Instance Created By Previously Unseen User - Rule", "ESCU - Cloud Compute Instance Created In Previously Unused Region - Rule", "ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule", "ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule", "ESCU - Get EC2 Instance Details by instanceId - Rule", "ESCU - Get EC2 Launch Details - Rule", "ESCU - Investigate AWS activities via region name - Rule", "ESCU - AWS Investigate Security Hub alerts by dest - Response Task", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
|
||
description = Monitor your cloud compute instances for activities related to cryptojacking/cryptomining. New instances that originate from previously unseen regions, users who launch abnormally high numbers of instances, or compute instances started by previously unseen users are just a few examples of potentially malicious behavior.
|
||
narrative = Cryptomining is an intentionally difficult, resource-intensive business. Its complexity was designed into the process to ensure that the number of blocks mined each day would remain steady. So, it's par for the course that ambitious, but unscrupulous, miners make amassing the computing power of large enterprises--a practice known as cryptojacking--a top priority. \
|
||
Cryptojacking has attracted an increasing amount of media attention since its explosion in popularity in the fall of 2017. The attacks have moved from in-browser exploits and mobile phones to enterprise cloud services, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure. It's difficult to determine exactly how widespread the practice has become, since bad actors continually evolve their ability to escape detection, including employing unlisted endpoints, moderating their CPU usage, and hiding the mining pool's IP address behind a free CDN. \
|
||
When malicious miners appropriate a cloud instance, often spinning up hundreds of new instances, the costs can become astronomical for the account holder. So it is critically important to monitor your systems for suspicious activities that could indicate that your network has been infiltrated. \
|
||
This Analytic Story is focused on detecting suspicious new instances in your cloud environment to help prevent cryptominers from gaining a foothold. It contains detection searches that will detect when a previously unused instance type or AMI is used. It also contains support searches to build lookup files to ensure proper execution of the detection searches.
|
||
|
||
[analytic_story://Cloud Federated Credential Abuse]
|
||
category = Cloud Security
|
||
last_updated = 2021-01-26
|
||
version = 1
|
||
references = ["https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps", "https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf", "https://us-cert.cisa.gov/ncas/alerts/aa21-008a"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS SAML Access by Provider User and Principal - Rule", "ESCU - AWS SAML Update identity provider - Rule", "ESCU - O365 Add App Role Assignment Grant User - Rule", "ESCU - O365 Added Service Principal - Rule", "ESCU - O365 Excessive SSO logon errors - Rule", "ESCU - O365 New Federated Domain Added - Rule"]
|
||
description = This analytical story addresses events that indicate abuse of cloud federated credentials. These credentials are usually extracted from endpoint desktop or servers specially those servers that provide federation services such as Windows Active Directory Federation Services. Identity Federation relies on objects such as Oauth2 tokens, cookies or SAML assertions in order to provide seamless access between cloud and perimeter environments. If these objects are either hijacked or forged then attackers will be able to pivot into victim's cloud environements.
|
||
narrative = This story is composed of detection searches based on endpoint that addresses the use of Mimikatz, Escalation of Privileges and Abnormal processes that may indicate the extraction of Federated directory objects such as passwords, Oauth2 tokens, certificates and keys. Cloud environment (AWS, Azure) related events are also addressed in specific cloud environment detection searches.
|
||
|
||
[analytic_story://Office 365 Detections]
|
||
category = Cloud Security
|
||
last_updated = 2020-12-16
|
||
version = 1
|
||
references = ["https://i.blackhat.com/USA-20/Thursday/us-20-Bienstock-My-Cloud-Is-APTs-Cloud-Investigating-And-Defending-Office-365.pdf"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Patrick Bareiss"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - O365 Add App Role Assignment Grant User - Rule", "ESCU - O365 Added Service Principal - Rule", "ESCU - O365 Bypass MFA via Trusted IP - Rule", "ESCU - O365 Disable MFA - Rule", "ESCU - O365 Excessive Authentication Failures Alert - Rule", "ESCU - O365 Excessive SSO logon errors - Rule", "ESCU - O365 New Federated Domain Added - Rule", "ESCU - O365 PST export alert - Rule", "ESCU - O365 Suspicious Admin Email Forwarding - Rule", "ESCU - O365 Suspicious Rights Delegation - Rule", "ESCU - O365 Suspicious User Email Forwarding - Rule"]
|
||
description = This story is focused around detecting Office 365 Attacks.
|
||
narrative = More and more companies are using Microsofts Office 365 cloud offering. Therefore, we see more and more attacks against Office 365. This story provides various detections for Office 365 attacks.
|
||
|
||
[analytic_story://Ransomware Cloud]
|
||
category = Malware
|
||
last_updated = 2020-10-27
|
||
version = 1
|
||
references = ["https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/", "https://github.com/d1vious/git-wild-hunt", "https://www.youtube.com/watch?v=PgzNib37g0M"]
|
||
maintainers = [{"company": "David Dorsey, Splunk", "email": "-", "name": "Rod Soto"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule", "ESCU - AWS Detect Users with KMS keys performing encryption S3 - Rule"]
|
||
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to ransomware. These searches include cloud related objects that may be targeted by malicious actors via cloud providers own encryption features.
|
||
narrative = Ransomware is an ever-present risk to the enterprise, wherein an infected host encrypts business-critical data, holding it hostage until the victim pays the attacker a ransom. There are many types and varieties of ransomware that can affect an enterprise.Cloud ransomware can be deployed by obtaining high privilege credentials from targeted users or resources.
|
||
|
||
[analytic_story://Suspicious AWS Login Activities]
|
||
category = Cloud Security
|
||
last_updated = 2019-05-01
|
||
version = 1
|
||
references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task"]
|
||
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]
|
||
category = Cloud Security
|
||
last_updated = 2018-07-24
|
||
version = 2
|
||
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf", "https://www.tripwire.com/state-of-security/security-data-protection/cloud/public-aws-s3-buckets-writable/"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - AWS S3 Bucket details via bucketName - Rule", "ESCU - Detect New Open S3 Buckets over AWS CLI - Rule", "ESCU - Detect New Open S3 buckets - Rule", "ESCU - Get All AWS Activity From IP Address - Rule", "ESCU - Investigate AWS activities via region name - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS S3 Bucket details via bucketName - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
|
||
description = Use the searches in this Analytic Story to monitor your AWS S3 buckets for evidence of anomalous activity and suspicious behaviors, such as detecting open S3 buckets and buckets being accessed from a new IP. The contextual and investigative searches will give you more information, when required.
|
||
narrative = As cloud computing has exploded, so has the number of creative attacks on virtual environments. And as the number-two cloud-service provider, Amazon Web Services (AWS) has certainly had its share.\
|
||
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.
|
||
|
||
[analytic_story://Suspicious Cloud Authentication Activities]
|
||
category = Cloud Security
|
||
last_updated = 2020-06-04
|
||
version = 1
|
||
references = ["https://aws.amazon.com/blogs/security/aws-cloudtrail-now-tracks-cross-account-activity-to-its-origin/", "https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Cross Account Activity From Previously Unseen Account - Rule", "ESCU - Detect AWS Console Login by New User - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule", "ESCU - Investigate AWS User Activities by user field - Rule", "ESCU - Investigate AWS User Activities by user field - Response Task"]
|
||
description = Monitor your cloud authentication events. Searches within this Analytic Story leverage the recent cloud updates to the Authentication data model to help you stay aware of and investigate suspicious login activity.
|
||
narrative = It is important to monitor and control who has access to your cloud infrastructure. Detecting suspicious logins 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 compute activity whether legitimate or otherwise.\
|
||
This Analytic Story has data model versions of cloud searches leveraging Authentication data, including those looking for suspicious login activity, and cross-account activity for AWS.
|
||
|
||
[analytic_story://Suspicious Cloud Instance Activities]
|
||
category = Cloud Security
|
||
last_updated = 2020-08-25
|
||
version = 1
|
||
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule", "ESCU - Abnormally High Number Of Cloud Instances Launched - Rule", "ESCU - Cloud Instance Modified By Previously Unseen User - Rule", "ESCU - Detect shared ec2 snapshot - Rule", "ESCU - Get All AWS Activity From IP Address - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task"]
|
||
description = Monitor your cloud infrastructure provisioning activities for behaviors originating from unfamiliar or unusual locations. These behaviors may indicate that malicious activities are occurring somewhere within your cloud environment.
|
||
narrative = Monitoring your cloud infrastructure logs allows you enable governance, compliance, and risk auditing. It is crucial for a company to monitor events and actions taken in the their cloud environments to ensure that your instances are not vulnerable to attacks. This Analytic Story identifies suspicious activities in your cloud compute instances and helps you respond and investigate those activities.
|
||
|
||
[analytic_story://Suspicious Cloud Provisioning Activities]
|
||
category = Cloud Security
|
||
last_updated = 2018-08-20
|
||
version = 1
|
||
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - Cloud Provisioning Activity From Previously Unseen City - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen Country - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen IP Address - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen Region - Rule"]
|
||
description = Monitor your cloud infrastructure provisioning activities for behaviors originating from unfamiliar or unusual locations. These behaviors may indicate that malicious activities are occurring somewhere within your cloud environment.
|
||
narrative = Because most enterprise cloud infrastructure activities originate from familiar geographic locations, monitoring for activity from unknown or unusual regions is an important security measure. This indicator can be especially useful in environments where it is impossible to add specific IPs to an allow list because they vary.\
|
||
This Analytic Story was designed to provide you with flexibility in the precision you employ in specifying legitimate geographic regions. It can be as specific as an IP address or a city, or as broad as a region (think state) or an entire country. By determining how precise you want your geographical locations to be and monitoring for new locations that haven't previously accessed your environment, you can detect adversaries as they begin to probe your environment. Since there are legitimate reasons for activities from unfamiliar locations, this is not a standalone indicator. Nevertheless, location can be a relevant piece of information that you may wish to investigate further.
|
||
|
||
[analytic_story://Suspicious Cloud User Activities]
|
||
category = Cloud Security
|
||
last_updated = 2020-09-04
|
||
version = 1
|
||
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf", "https://redlock.io/blog/cryptojacking-tesla"]
|
||
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
|
||
spec_version = 3
|
||
searches = ["ESCU - AWS IAM AccessDenied Discovery Events - Rule", "ESCU - AWS Investigate User Activities By ARN - Rule", "ESCU - Abnormally High Number Of Cloud Infrastructure API Calls - Rule", "ESCU - Abnormally High Number Of Cloud Security Group API Calls - Rule", "ESCU - Cloud API Calls From Previously Unseen User Roles - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task"]
|
||
description = Detect and investigate suspicious activities by users and roles in your cloud environments.
|
||
narrative = It seems obvious that it is critical to monitor and control the users who have access to your cloud infrastructure. Nevertheless, it's all too common for enterprises to lose track of ad-hoc accounts, leaving their servers vulnerable to attack. In fact, this was the very oversight that led to Tesla's cryptojacking attack in February, 2018.\
|
||
In addition to compromising the security of your data, when bad actors leverage your compute resources, it can incur monumental costs, since you will be billed for any new instances and increased bandwidth usage.
|
||
|
||
### END STORIES ###
|
||
|
||
### DETECTIONS ###
|
||
|
||
[savedsearch://ESCU - AWS Create Policy Version to allow all resources - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS CreateAccessKey - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user A who has already permission to create access keys, makes an API call to create access keys for another user B. Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B)
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1136.003"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS CreateLoginProfile - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1136.003"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a login profile for another user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Cross Account Activity From Previously Unseen Account - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for AssumeRole events where an IAM role in a different account is requested for the first time.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen AWS Cross Account Activity - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen AWS Cross Account Activity - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `aws_cross_account_activity_from_previously_unseen_account_filter` macro.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "nist": ["PR.AC", "PR.DS", "DE.AE"]}
|
||
known_false_positives = Using multiple AWS accounts and roles is perfectly valid behavior. It's suspicious when an account requests privileges of an account it hasn't before. You should validate with the account owner that this is a legitimate request.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
|
||
annotations = {"mitre_attack": ["T1486"]}
|
||
known_false_positives = unknown
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Detect Users with KMS keys performing encryption S3 - Rule]
|
||
type = detection
|
||
asset_type = S3 Bucket
|
||
confidence = medium
|
||
explanation = This search provides detection of users with KMS keys performing encryption specifically against S3 buckets.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
|
||
annotations = {"mitre_attack": ["T1486"]}
|
||
known_false_positives = bucket with S3 encryption
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Excessive Security Scanning - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events and analyse the amount of eventNames which starts with Describe by a single user. This indicates that this user scans the configuration of your AWS cloud environment.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1526"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS IAM AccessDenied Discovery Events - Rule]
|
||
type = detection
|
||
asset_type =
|
||
confidence = medium
|
||
explanation = The following detection identifies excessive AccessDenied events within an hour timeframe. It is possible that an access key to AWS may have been stolen and is being misused to perform discovery events. In these instances, the access is not available with the key stolen therefore these events will be generated.
|
||
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
|
||
annotations = {"kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1580"]}
|
||
known_false_positives = It is possible to start this detection will need to be tuned by source IP or user. In addition, change the count values to an upper threshold to restrict false positives.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS IAM Assume Role Policy Brute Force - Rule]
|
||
type = detection
|
||
asset_type =
|
||
confidence = medium
|
||
explanation = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`. Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing.
|
||
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs. Set the `where count` greater than a value to identify suspicious activity in your environment.
|
||
annotations = {"kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1580", "T1110"]}
|
||
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS IAM Delete Policy - Rule]
|
||
type = detection
|
||
asset_type =
|
||
confidence = medium
|
||
explanation = The following detection identifes when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy.
|
||
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
|
||
annotations = {"kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1098"]}
|
||
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS IAM Failure Group Deletion - Rule]
|
||
type = detection
|
||
asset_type =
|
||
confidence = medium
|
||
explanation = This detection identifies failure attempts to delete groups. We want to identify when a group is attempting to be deleted, but either access is denied, there is a conflict or there is no group. This is indicative of administrators performing an action, but also could be suspicious behavior occurring. Review parallel IAM events - recently added users, new groups and so forth.
|
||
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
|
||
annotations = {"kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1098"]}
|
||
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege).
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS IAM Successful Group Deletion - Rule]
|
||
type = detection
|
||
asset_type =
|
||
confidence = medium
|
||
explanation = The following query uses IAM events to track the success of a group being deleted on AWS. This is typically not indicative of malicious behavior, but a precurser to additional events thay may unfold. Review parallel IAM events - recently added users, new groups and so forth. Inversely, review failed attempts in a similar manner.
|
||
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
|
||
annotations = {"kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1069.003", "T1098"]}
|
||
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege).
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Network Access Control List Created with All Open Ports - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = The search looks for AWS CloudTrail events to detect if any network ACLs were created with all the ports open to a specified CIDR.
|
||
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, and configure your AWS CloudTrail inputs.
|
||
annotations = {"cis20": ["CIS 11"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1562.007"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = It's possible that an admin has created this ACL with all ports open for some legitimate purpose however, this should be scoped and not allowed in production environment.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS Network Access Control List Deleted - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the AWS console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the AWS CloudTrail logs to detect users deleting network ACLs.
|
||
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 AWS CloudTrail inputs.
|
||
annotations = {"cis20": ["CIS 11"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1562.007"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = It's possible that a user has legitimately deleted a network ACL.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS SAML Access by Provider User and Principal - Rule]
|
||
type = detection
|
||
asset_type = AWS Federated Account
|
||
confidence = medium
|
||
explanation = This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
|
||
annotations = {"mitre_attack": ["T1078"]}
|
||
known_false_positives = Attacks using a Golden SAML or SAML assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source IP sourceIPAddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS SAML Update identity provider - Rule]
|
||
type = detection
|
||
asset_type = AWS Federated Account
|
||
confidence = medium
|
||
explanation = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"mitre_attack": ["T1078"]}
|
||
known_false_positives = Updating a SAML provider or creating a new one may not necessarily be malicious however it needs to be closely monitored.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS SetDefaultPolicyVersion - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately set a default policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - AWS UpdateLoginProfile - Rule]
|
||
type = detection
|
||
asset_type = AWS Account
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B)
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1136.003"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Abnormally High Number Of Cloud Infrastructure API Calls - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search will detect a spike in the number of API calls made to your cloud infrastructure environment by a user.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Infrastructure API Calls Per User` to create the probability density function.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["DE.DP", "DE.CM", "PR.AC"]}
|
||
known_false_positives =
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule]
|
||
type = detection
|
||
asset_type = Cloud Instance
|
||
confidence = medium
|
||
explanation = This search finds for the number successfully destroyed cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Destroyed` to create the probability density function.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = Many service accounts configured within a cloud infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Abnormally High Number Of Cloud Instances Launched - Rule]
|
||
type = detection
|
||
asset_type = Cloud Instance
|
||
confidence = medium
|
||
explanation = This search finds for the number successfully created cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Launched` to create the probability density function.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Abnormally High Number Of Cloud Security Group API Calls - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search will detect a spike in the number of API calls made to your cloud infrastructure environment about security groups by a user.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Security Group API Calls Per User` to create the probability density function model.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1078.004"], "nist": ["DE.DP", "DE.CM", "PR.AC"]}
|
||
known_false_positives =
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud API Calls From Previously Unseen User Roles - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for new commands from each user role.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud API Calls Per User Role - Initial` to build the initial table of user roles, commands, and times. You must also enable the second baseline search `Previously Seen Cloud API Calls Per User Role - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `cloud_api_calls_from_previously_unseen_user_roles_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_api_calls_from_previously_unseen_user_roles_filter`
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078"], "nist": ["ID.AM"]}
|
||
known_false_positives = .
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Compute Instance Created By Previously Unseen User - Rule]
|
||
type = detection
|
||
asset_type = Cloud Compute Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud compute instances created by users who have not created them before.
|
||
how_to_implement = You must be ingesting the appropriate cloud-infrastructure logs Run the "Previously Seen Cloud Compute Creations By User" support search to create of baseline of previously seen users.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078.004"], "nist": ["ID.AM"]}
|
||
known_false_positives = It's possible that a user will start to create compute instances for the first time, for any number of reasons. Verify with the user launching instances that this is the intended behavior.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Compute Instance Created In Previously Unused Region - Rule]
|
||
type = detection
|
||
asset_type = Cloud Compute Instance
|
||
confidence = medium
|
||
explanation = This search looks at cloud-infrastructure events where an instance is created in any region within the last hour and then compares it to a lookup file of previously seen regions where instances have been created.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Regions - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Regions - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_in_previously_unused_region_filter` macro.
|
||
annotations = {"cis20": ["CIS 12"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1535"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = It's possible that a user has unknowingly started an instance in a new region. Please verify that this activity is legitimate.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule]
|
||
type = detection
|
||
asset_type = Cloud Compute Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud compute instances being created with previously unseen image IDs.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Images - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Images - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_image_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "nist": ["ID.AM"]}
|
||
known_false_positives = After a new image is created, the first systems created with that image will cause this alert to fire. Verify that the image being used was created by a legitimate user.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule]
|
||
type = detection
|
||
asset_type = Cloud Compute Instance
|
||
confidence = medium
|
||
explanation = Find EC2 instances being created with previously unseen instance types.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Instance Types - Initial` to build the initial table of instance types observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Instance Types - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_instance_type_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "nist": ["ID.AM"]}
|
||
known_false_positives = It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Instance Modified By Previously Unseen User - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud instances being modified by users who have not previously modified them.
|
||
how_to_implement = This search has a dependency on other searches to create and update a baseline of users observed to be associated with this activity. The search "Previously Seen Cloud Instance Modifications By User - Update" should be enabled for this detection to properly work.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078.004"], "nist": ["ID.AM"]}
|
||
known_false_positives = It's possible that a new user will start to modify EC2 instances when they haven't before for any number of reasons. Verify with the user that is modifying instances that this is the intended behavior.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen City - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud provisioning activities from previously unseen cities. Provisioning activities are defined broadly as any event that runs or creates something.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_city_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078"], "nist": ["ID.AM"]}
|
||
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
|
||
This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen Country - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud provisioning activities from previously unseen countries. Provisioning activities are defined broadly as any event that runs or creates something.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_country_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078"], "nist": ["ID.AM"]}
|
||
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
|
||
This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen IP Address - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud provisioning activities from previously unseen IP addresses. Provisioning activities are defined broadly as any event that runs or creates something.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_ip_address_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078"], "nist": ["ID.AM"]}
|
||
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
|
||
This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen Region - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for cloud provisioning activities from previously unseen regions. Provisioning activities are defined broadly as any event that runs or creates something.
|
||
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_region_filter` macro.
|
||
annotations = {"cis20": ["CIS 1"], "mitre_attack": ["T1078"], "nist": ["ID.AM"]}
|
||
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
|
||
This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect AWS Console Login by New User - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
|
||
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect AWS Console Login by User from New City - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
|
||
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_city_filter` macro.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1535"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect AWS Console Login by User from New Country - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
|
||
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_country_filter` macro.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1535"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect AWS Console Login by User from New Region - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
|
||
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_region_filter` macro.
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1535"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect New Open S3 Buckets over AWS CLI - Rule]
|
||
type = detection
|
||
asset_type = S3 Bucket
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user has created an open/public S3 bucket over the aws cli.
|
||
how_to_implement =
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1530"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a public bucket for a specific purpose. That said, AWS strongly advises against granting full control to the "All Users" group.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect New Open S3 buckets - Rule]
|
||
type = detection
|
||
asset_type = S3 Bucket
|
||
confidence = medium
|
||
explanation = This search looks for AWS CloudTrail events where a user has created an open/public S3 bucket.
|
||
how_to_implement = You must install the AWS App for Splunk.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1530"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a public bucket for a specific purpose. That said, AWS strongly advises against granting full control to the "All Users" group.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect Spike in AWS Security Hub Alerts for EC2 Instance - Rule]
|
||
type = detection
|
||
asset_type = AWS Instance
|
||
confidence = medium
|
||
explanation = This search looks for a spike in number of of AWS security Hub alerts for an EC2 instance in 4 hours intervals
|
||
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 Security Hub inputs. The threshold_value should be tuned to your environment and schedule these searches according to the bucket span interval.
|
||
annotations = {"cis20": ["CIS 13"], "nist": ["DE.DP"]}
|
||
known_false_positives = None
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - Detect shared ec2 snapshot - Rule]
|
||
type = detection
|
||
asset_type = EC2 Snapshot
|
||
confidence = medium
|
||
explanation = The following analytic utilizes AWS CloudTrail events to identify when an EC2 snapshot permissions are modified to be shared with a different AWS account. This method is used by adversaries to exfiltrate the EC2 snapshot.
|
||
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
|
||
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["PR.DS", "PR.AC", "DE.CM"]}
|
||
known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with others for a specific purpose.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Add App Role Assignment Grant User - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects the creation of a new Federation setting by alerting about an specific event related to its creation.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1136.003"]}
|
||
known_false_positives = The creation of a new Federation is not necessarily malicious, however this events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Added Service Principal - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects the creation of a new Federation setting by alerting about an specific event related to its creation.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1136.003"]}
|
||
known_false_positives = The creation of a new Federation is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Bypass MFA via Trusted IP - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects newly added IP addresses/CIDR blocks to the list of MFA Trusted IPs to bypass multi factor authentication. Attackers are often known to use this technique so that they can bypass the MFA system.
|
||
how_to_implement = You must install Splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1562.007"]}
|
||
known_false_positives = Unless it is a special case, it is uncommon to continually update Trusted IPs to MFA configuration.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Disable MFA - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects when multi factor authentication has been disabled, what entitiy performed the action and against what user
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1556"]}
|
||
known_false_positives = Unless it is a special case, it is uncommon to disable MFA or Strong Authentication
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Excessive Authentication Failures Alert - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects when an excessive number of authentication failures occur this search also includes attempts against MFA prompt codes
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Not Applicable"], "mitre_attack": ["T1110"]}
|
||
known_false_positives = The threshold for alert is above 10 attempts and this should reduce the number of false positives.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Excessive SSO logon errors - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects accounts with high number of Single Sign ON (SSO) logon errors. Excessive logon errors may indicate attempts to bruteforce of password or single sign on token hijack or reuse.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1556"]}
|
||
known_false_positives = Logon errors may not be malicious in nature however it may indicate attempts to reuse a token or password obtained via credential access attack.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 New Federated Domain Added - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects the addition of a new Federated domain.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity.
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1136.003"]}
|
||
known_false_positives = The creation of a new Federated domain is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a similar or different cloud provider.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 PST export alert - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects when a user has performed an Ediscovery search or exported a PST file from the search. This PST file usually has sensitive information including email body content
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"kill_chain_phases": ["Actions on Objective"], "mitre_attack": ["T1114"]}
|
||
known_false_positives = PST export can be done for legitimate purposes but due to the sensitive nature of its content it must be monitored.
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Suspicious Admin Email Forwarding - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects when an admin configured a forwarding rule for multiple mailboxes to the same destination.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1114.003"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = unknown
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Suspicious Rights Delegation - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects the assignment of rights to accesss content from another mailbox. This is usually only assigned to a service account.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1114.002"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = Service Accounts
|
||
providing_technologies = []
|
||
|
||
[savedsearch://ESCU - O365 Suspicious User Email Forwarding - Rule]
|
||
type = detection
|
||
asset_type = Office 365
|
||
confidence = medium
|
||
explanation = This search detects when multiple user configured a forwarding rule to the same destination.
|
||
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
|
||
annotations = {"cis20": ["CIS 16"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1114.003"], "nist": ["DE.DP", "DE.AE"]}
|
||
known_false_positives = unknown
|
||
providing_technologies = []
|
||
|
||
### END DETECTIONS ###
|
||
|
||
### RESPONSE TASKS ###
|
||
|
||
[savedsearch://ESCU - AWS Investigate Security Hub alerts by dest - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - AWS Investigate User Activities By ARN - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - AWS Investigate User Activities By AccessKeyId - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - AWS Network ACL Details from ID - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
how_to_implement = In order to implement this search, 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) and configure your AWS description inputs.
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - AWS Network Interface details via resourceId - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
how_to_implement = In order to implement this search, 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) and configure your AWS configuration inputs
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - AWS S3 Bucket details via bucketName - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
how_to_implement = To implement this search, 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) and configure your AWS inputs.
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Amazon EKS Kubernetes activity by src ip - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 Cloud Watch EKS inputs.
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get All AWS Activity From City - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get All AWS Activity From Country - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get All AWS Activity From IP Address - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get All AWS Activity From Region - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get EC2 Instance Details by instanceId - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
how_to_implement = In order to implement this search, 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) and configure your AWS description inputs.
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Get EC2 Launch Details - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
how_to_implement = In order to implement this search, 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) and configure your AWS description inputs.
|
||
known_false_positives = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Investigate AWS User Activities by user field - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
[savedsearch://ESCU - Investigate AWS activities via region name - Response Task]
|
||
type = investigation
|
||
explanation = none
|
||
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 = not defined
|
||
earliest_time_offset = 14400
|
||
latest_time_offset = 0
|
||
|
||
### END RESPONSE TASKS ###
|