security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Rule Deprecations] AWS Rule Deprecations (#5568)

Browse Source 
Completing the Deprecation process for these rules as they have been shipped at least 2 release cycles with "Deprecated - " prefix.

All have the following metadata changes

maturity = "deprecated"
updated_date = "2026/01/16"
deprecation_date = "2026/01/16"
This commit is contained in:
Isai
2026-01-20 16:05:39 -05:00
committed by GitHub
parent 9e6bf04e82
commit 5f4f9d206f
9 changed files with 27 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
-107
View File
@@ -1,107 +0,0 @@
[metadata]
creation_date = "2021/07/19"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/18"
[rule]
author = ["Austin Songer"]
description = """
Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups
have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule
should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security
Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
"""
false_positives = [
"""
A ElastiCache security group may be created by a system or network administrator. Verify whether the user identity,
user agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar
users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS ElastiCache Security Group Created"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS ElastiCache Security Group Created
AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.
### Possible investigation steps
- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group.
- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.
- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.
- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.
- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.
- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.
### False positive analysis
- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.
- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.
- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.
- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.
### Response and remediation
- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.
- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.
- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.
- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.
- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.
- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
"https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheSecurityGroup.html",
]
risk_score = 21
rule_id = "7b3da11a-60a2-412e-8aa7-011e1eb9ed47"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:"Create Cache Security Group" and
event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.007"
name = "Disable or Modify Cloud Firewall"
reference = "https://attack.mitre.org/techniques/T1562/007/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
-107
View File
@@ -1,107 +0,0 @@
[metadata]
creation_date = "2021/07/19"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/18"
[rule]
author = ["Austin Songer"]
description = """
Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache
CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups
instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying
on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based
deployments.
"""
false_positives = [
"""
A ElastiCache security group deletion may be done by a system or network administrator. Verify whether the user
identity, user agent, and/or hostname should be making changes in your environment. Security Group deletions by
unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS ElastiCache Security Group Modified or Deleted"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS ElastiCache Security Group Modified or Deleted
AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.
### Possible investigation steps
- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.
- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture.
- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.
- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.
- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.
- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.
### False positive analysis
- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.
- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.
- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.
- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.
### Response and remediation
- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.
- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.
- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.
- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.
- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.
- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.
- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html"]
risk_score = 21
rule_id = "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:("Delete Cache Security Group" or
"Authorize Cache Security Group Ingress" or "Revoke Cache Security Group Ingress" or "AuthorizeCacheSecurityGroupEgress" or
"RevokeCacheSecurityGroupEgress") and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.007"
name = "Disable or Modify Cloud Firewall"
reference = "https://attack.mitre.org/techniques/T1562/007/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
-108
View File
@@ -1,108 +0,0 @@
[metadata]
creation_date = "2021/04/22"
integration = ["aws"]
maturity = "production"
updated_date = "2025/10/23"
[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or
exfiltrate information.
"""
false_positives = [
"""
VM exports may be done by a system or network administrator. Verify whether the user identity, user agent, and/or
hostname should be making changes in your environment. VM exports from unfamiliar users or hosts should be
investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS EC2 VM Export Failure"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS EC2 VM Export Failure
AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further.
### Possible investigation steps
- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved.
- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials.
- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts.
- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt.
- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat.
### False positive analysis
- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks.
- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags.
- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations.
- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats.
### Response and remediation
- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account.
- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt.
- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise.
- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.
- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future.
- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances.
- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance"]
risk_score = 21
rule_id = "e919611d-6b6f-493b-8314-7ed6ac2e413b"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Use Case: Asset Visibility",
"Tactic: Exfiltration",
"Tactic: Collection",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:CreateInstanceExportTask and event.outcome:failure
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"
[rule.threat.tactic]
id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"
[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
rules/integrations/aws/impact_rds_group_deletion.toml
-98
View File
@@ -1,98 +0,0 @@
[metadata]
creation_date = "2021/06/05"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/21"
[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a
VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on
legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control
changes impacting RDS in VPC-based deployments.
"""
false_positives = [
"""
An RDS security group deletion may be done by a system or network administrator. Verify whether the user identity,
user agent, and/or hostname should be making changes in your environment. Security group deletions by unfamiliar
users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS RDS Security Group Deletion"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS RDS Security Group Deletion
Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.
### Possible investigation steps
- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.
- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.
- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.
- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.
- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.
### False positive analysis
- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.
- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.
### Response and remediation
- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.
- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.
- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.
- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.
- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"]
risk_score = 21
rule_id = "863cdf31-7fd3-41cf-a185-681237ea277b"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS RDS",
"Tactic: Impact",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"
[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
-100
View File
@@ -1,100 +0,0 @@
[metadata]
creation_date = "2020/05/20"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/21"
[rule]
author = ["Elastic"]
description = "Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped."
false_positives = [
"""
Valid clusters or instances may be stopped by a system administrator. Verify whether the user identity, user agent,
and/or hostname should be making changes in your environment. Cluster or instance stoppages from unfamiliar users or
hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS RDS Instance/Cluster Stoppage"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS RDS Instance/Cluster Stoppage
Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.
### Possible investigation steps
- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.
- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.
- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.
- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.
- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.
- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.
### False positive analysis
- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.
- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.
- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.
- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.
- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.
### Response and remediation
- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.
- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.
- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.
- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.
- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-cluster.html",
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html",
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-instance.html",
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBInstance.html",
]
risk_score = 47
rule_id = "ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d"
severity = "medium"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS RDS",
"Use Case: Asset Visibility",
"Tactic: Impact",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(StopDBCluster or StopDBInstance) and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"
[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
rules/integrations/aws/persistence_rds_cluster_creation.toml
-110
View File
@@ -1,110 +0,0 @@
[metadata]
creation_date = "2020/05/20"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/21"
[rule]
author = ["Elastic"]
description = """
Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread
across multiple regions.
"""
false_positives = [
"""
Valid clusters may be created by a system or network administrator. Verify whether the user identity, user agent,
and/or hostname should be making changes in your environment. Cluster creations by unfamiliar users or hosts should
be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS RDS Cluster Creation"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS RDS Cluster Creation
Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.
### Possible investigation steps
- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.
- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.
- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.
- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.
- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.
- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
### False positive analysis
- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.
- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.
- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.
### Response and remediation
- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.
- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.
- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html",
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html",
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html",
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html",
]
risk_score = 21
rule_id = "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS RDS",
"Use Case: Asset Visibility",
"Tactic: Persistence",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/integrations/aws/persistence_rds_group_creation.toml
-103
View File
@@ -1,103 +0,0 @@
[metadata]
creation_date = "2021/06/05"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/21"
[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a
VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on
legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control
changes impacting RDS in VPC-based deployments.
"""
false_positives = [
"""
An RDS security group may be created by a system or network administrator. Verify whether the user identity, user
agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or
hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS RDS Security Group Creation"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS RDS Security Group Creation
Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
### Possible investigation steps
- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
### False positive analysis
- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
### Response and remediation
- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"]
risk_score = 21
rule_id = "378f9024-8a0c-46a5-aa08-ce147ac73a4e"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS RDS",
"Tactic: Persistence",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBSecurityGroup and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1136"
name = "Create Account"
reference = "https://attack.mitre.org/techniques/T1136/"
[[rule.threat.technique.subtechnique]]
id = "T1136.003"
name = "Cloud Account"
reference = "https://attack.mitre.org/techniques/T1136/003/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules/integrations/aws/persistence_rds_instance_creation.toml
-90
View File
@@ -1,90 +0,0 @@
[metadata]
creation_date = "2021/06/06"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/21"
[rule]
author = ["Elastic", "Austin Songer"]
description = "Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance."
false_positives = [
"""
A database instance may be created by a system or network administrator. Verify whether the user identity, user
agent, and/or hostname should be making changes in your environment. Instances creations by unfamiliar users or
hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS RDS Instance Creation"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS RDS Instance Creation
Amazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility.
### Possible investigation steps
- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address.
- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns.
- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity.
- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns.
- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions.
- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards.
### False positive analysis
- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities.
- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts.
- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers.
- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls.
- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers.
### Response and remediation
- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised.
- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered.
- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected.
- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities.
- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html"]
risk_score = 21
rule_id = "f30f3443-4fbb-4c27-ab89-c3ad49d62315"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS RDS",
"Use Case: Asset Visibility",
"Tactic: Persistence",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBInstance and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules/integrations/aws/persistence_redshift_instance_creation.toml
-93
View File
@@ -1,93 +0,0 @@
[metadata]
creation_date = "2022/04/12"
integration = ["aws"]
maturity = "production"
updated_date = "2025/11/25"
[rule]
author = ["Elastic"]
description = """
Identifies the creation of an Amazon Redshift cluster. Unexpected creation of this cluster by a non-administrative user
may indicate a permission or role issue with current users. If unexpected, the resource may not properly be configured
and could introduce security vulnerabilities.
"""
false_positives = [
"""
Valid clusters may be created by a system or network administrator. Verify whether the user identity, user agent,
and/or hostname should be making changes in your environment. Cluster creations by unfamiliar users or hosts should
be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - AWS Redshift Cluster Creation"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - AWS Redshift Cluster Creation
Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. In a secure environment, only authorized users should create Redshift clusters. Adversaries might exploit misconfigured permissions to create clusters, potentially leading to data exfiltration or unauthorized data processing. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations.
### Possible investigation steps
- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:redshift.amazonaws.com to confirm the details of the CreateCluster event, including the timestamp and the user who initiated the action.
- Identify the IAM role or user associated with the event.action:CreateCluster and verify if this user is expected to have permissions to create Redshift clusters. Check for any recent changes to their permissions or roles.
- Investigate the event.outcome:success to ensure that the cluster creation was indeed successful and determine the region and account where the cluster was created.
- Examine the configuration of the newly created Redshift cluster to ensure it adheres to security best practices, such as encryption settings, VPC configurations, and access controls.
- Cross-reference the user activity with other logs or alerts to identify any unusual patterns or behaviors that might indicate misuse or compromise, such as multiple cluster creation attempts or access from unfamiliar IP addresses.
- Contact the user or team responsible for the account to verify if the cluster creation was intentional and authorized, and document their response for future reference.
### False positive analysis
- Routine maintenance or testing activities by non-admin users can trigger alerts. To manage this, create exceptions for specific users or roles known to perform these tasks regularly.
- Automated scripts or third-party tools that create clusters as part of their normal operation may cause false positives. Identify these tools and exclude their associated user accounts or roles from the detection rule.
- Development or staging environments where non-admin users are permitted to create clusters for testing purposes can lead to alerts. Implement environment-specific exclusions to prevent unnecessary alerts.
- Temporary permissions granted to non-admin users for specific projects can result in cluster creation alerts. Monitor and document these permissions, and adjust the detection rule to account for these temporary changes.
### Response and remediation
- Immediately isolate the Redshift cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
- Review the IAM roles and permissions associated with the user who created the cluster. Revoke any unnecessary permissions and ensure that the principle of least privilege is enforced.
- Conduct a thorough audit of recent CloudTrail logs to identify any other unauthorized activities or anomalies associated with the same user or related accounts.
- If data exfiltration is suspected, initiate a data integrity check and consider restoring from a known good backup to ensure no data tampering has occurred.
- Notify the security team and relevant stakeholders about the incident for further investigation and to determine if additional security measures are needed.
- Implement additional monitoring and alerting for Redshift cluster creation events, especially focusing on non-administrative users, to quickly detect similar activities in the future.
- Consider enabling multi-factor authentication (MFA) for all users with permissions to create or modify Redshift clusters to add an extra layer of security.
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateCluster.html"]
risk_score = 21
rule_id = "015cca13-8832-49ac-a01b-a396114809f6"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS Redshift",
"Use Case: Asset Visibility",
"Tactic: Persistence",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:redshift.amazonaws.com and event.action:CreateCluster and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"