AWS RDS Cluster Creation
Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/05/20"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread
11across multiple regions.
12"""
13false_positives = [
14 """
15 Valid clusters may be created by a system or network administrator. Verify whether the user identity, user agent,
16 and/or hostname should be making changes in your environment. Cluster creations by unfamiliar users or hosts should
17 be investigated. If known behavior is causing false positives, it can be exempted from the rule.
18 """,
19]
20from = "now-60m"
21index = ["filebeat-*", "logs-aws.cloudtrail-*"]
22interval = "10m"
23language = "kuery"
24license = "Elastic License v2"
25name = "AWS RDS Cluster Creation"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> 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.
30
31### Investigating AWS RDS Cluster Creation
32
33Amazon 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.
34
35### Possible investigation steps
36
37- 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.
38- 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.
39- 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.
40- 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.
41- 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.
42- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
43
44### False positive analysis
45
46- 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.
47- 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.
48- 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.
49- 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.
50- 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.
51
52### Response and remediation
53
54- 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.
55- 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.
56- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
57- 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.
58- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
59- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
60- 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.
61
62## Setup
63
64The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
65references = [
66 "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html",
67 "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html",
68 "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html",
69 "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html",
70]
71risk_score = 21
72rule_id = "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d"
73severity = "low"
74tags = [
75 "Domain: Cloud",
76 "Data Source: AWS",
77 "Data Source: Amazon Web Services",
78 "Data Source: AWS RDS",
79 "Use Case: Asset Visibility",
80 "Tactic: Persistence",
81 "Resources: Investigation Guide",
82]
83timestamp_override = "event.ingested"
84type = "query"
85
86query = '''
87event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success
88'''
89
90
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1133"
95name = "External Remote Services"
96reference = "https://attack.mitre.org/techniques/T1133/"
97
98
99[rule.threat.tactic]
100id = "TA0003"
101name = "Persistence"
102reference = "https://attack.mitre.org/tactics/TA0003/"
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105
106[rule.threat.tactic]
107id = "TA0005"
108name = "Defense Evasion"
109reference = "https://attack.mitre.org/tactics/TA0005/"
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 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
Related rules
- AWS RDS Instance Creation
- AWS Deletion of RDS Instance or Cluster
- AWS RDS DB Instance Made Public
- AWS RDS DB Instance Restored
- AWS RDS DB Instance or Cluster Password Modified