[Rule Tunings] AWS RDS Rules (#5366)

* [Rule Tunings] AWS RDS Rules

#### AWS RDS DB Instance Made Public
- updated description and investigation guide
- added highlighted fields

#### AWS RDS DB Instance or Cluster Deletion Protection Disabled
- updated description and investigation guide
- added highlighted fields

#### AWS RDS Snapshot Deleted
- excluded `backup.amazonaws.com` as this is expected behavior. This exclusion reduces noise in telemetry by ~77%
- updated description and investigation guide
- added highlighted fields

#### AWS Deletion of RDS Instance or Cluster > AWS RDS DB Instance or Cluster Deleted
- reduced execution window
- slight name change to align with other rules
- updated description and investigation guide
- added highlighted fields

#### AWS RDS DB Instance Restored
- `event.type` used for `event_category_override` because event.category is not mapped for these API calls
- updated description and investigation guide
- added highlighted fields

#### AWS RDS DB Instance or Cluster Password Modified
- `event.type` used for `event_category_override` because event.category is not mapped for these API calls
- updated description and investigation guide
- added highlighted fields

#### AWS RDS Snapshot Export
- reduced execution window
- updated mitre mapping
- updated description and investigation guide
- added highlighted fields

* rule type change from eql to kql

changing rule type to kql since there's not eql specific functions needed for the query

rules/integrations/aws/defense_evasion_rds_instance_restored.toml

@@ -2,24 +2,130 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/12/01"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
 description = """
-An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations.
+Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to
+valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate
+sensitive data from a duplicated environment. This rule detects successful restoration operations using
+"RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or
+post-compromise defense evasion.
 """
 false_positives = [
     """
-    Restoring DB instances 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. Instance restoration by unfamiliar users or hosts
-    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Restoring an RDS DB instance may be performed legitimately during troubleshooting, development refresh processes,
+    migrations, or disaster-recovery drills. Validate the user identity, source IP, automation context, and whether the
+    restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. Expected
+    behavior can be exempted through rule exceptions.
     """,
 ]
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-language = "eql"
+language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Restored"
+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, validate and adapt it to suit your operational needs.
+
+### Investigating AWS RDS DB Instance Restored
+
+Restoring an RDS DB instance from a snapshot or from S3 is a powerful operation that recreates a full database environment. While legitimate for recovery, migrations, or cloning, adversaries may use restore actions to access historical data, duplicate sensitive environments, evade guardrails, or prepare for data exfiltration. 
+
+This rule detects successful invocation of `RestoreDBInstanceFromDBSnapshot` and `RestoreDBInstanceFromS3`, both of which may indicate attempts to rehydrate old datasets, bypass deletion protection, or establish a shadow environment for further malicious actions.
+
+#### Possible investigation steps
+
+- **Identify the actor and execution context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.
+  - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK).
+
+- **Understand what was restored and why**
+  - Inspect `aws.cloudtrail.request_parameters` to identify:
+    - Snapshot identifier or S3 location used as the restore source.
+    - The new DB instance identifier and configuration parameters.
+  - Determine:
+    - Whether the snapshot/backup used for the restore contains sensitive or high-value data.
+    - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes.
+
+- **Reconstruct the activity flow**
+  - Use `@timestamp` to correlate the restore event with:
+    - Snapshot creation, copy, or export events.
+    - IAM policy changes or privilege escalations.
+    - Deletion or modification of the original database.
+    - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes.
+  - Look for signs of attacker staging:
+    - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`).
+    - Recent logins from unusual IPs or federated sessions without MFA.
+
+- **Correlate with broader behavior**
+  - Pivot in CloudTrail on:
+    - The same snapshot identifier.
+    - The same actor or access key ID.
+    - The newly created DB instance identifier.
+  - Examine:
+    - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled).
+    - Whether there were large-volume read operations or export actions following the restore.
+    - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions).
+
+- **Validate intent with owners**
+  - Confirm with the application/database/platform teams:
+    - Whether the restore was requested or part of an authorized operational workflow.
+    - Whether this restore corresponds to migration, testing, DR drill, or another planned activity.
+    - Whether the restored environment should exist (and for how long).
+
+### False positive analysis
+
+- **Legitimate maintenance and DR workflows**
+  - Many teams restore databases for patch testing, DR validation, schema testing, or migration.
+- **Automated restore workflows**
+  - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments.
+- **Third-party tooling**
+  - Backup/DR solutions, migration tools, or observability platforms may restore DB instances for operational reasons. Tune based on `user_agent.original` or known service roles.
+
+### Response and remediation
+
+- **Contain the restored environment**
+  - If unauthorized:
+    - Apply restrictive security groups to block access.
+    - Disable public accessibility if enabled.
+    - Evaluate whether deletion protection or backup retention is misconfigured.
+
+- **Assess data exposure and intent**
+  - Work with data owners to evaluate:
+    - The sensitivity of the restored environment.
+    - Whether any reads, dumps, or exports occurred post-restore.
+    - Whether the restore enabled the attacker to access older or deleted data.
+
+- **Investigate scope and related activity**
+  - Review CloudTrail for:
+    - Additional restores, exports, or copies.
+    - IAM changes allowing expanded privileges.
+    - Unusual authentication events or federated sessions without MFA.
+    - Related destructive actions (snapshot deletion, backup disabled, instance deletion).
+
+- **Hardening and preventive controls**
+  - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`.
+  - Use IAM conditions to restrict restore actions by network, principal, or region.
+  - Add AWS Config and Security Hub controls for monitoring:
+    - Unapproved restores.
+    - Public or misconfigured restored instances.
+  - Consider SCPs that prevent RDS restores in production accounts except through controlled roles.
+
+- **Post-incident improvements**
+  - Rotate credentials for affected IAM users/roles.
+  - Update change management processes to ensure restore actions are tracked and approved.
+  - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
@@ -39,49 +145,15 @@ tags = [
     "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
-type = "eql"
+type = "query"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
-    and event.provider == "rds.amazonaws.com"
-    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
-    and event.outcome == "success"
+event.dataset: "aws.cloudtrail"
+    and event.provider: "rds.amazonaws.com"
+    and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3")
+    and event.outcome: "success"
 '''
-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 AWS RDS DB Instance Restored
-
-Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit RDS by restoring DB instances from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, signaling potential unauthorized access or data exfiltration activities, by monitoring specific API operations and outcomes.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the user or role associated with the successful `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API call by examining the `user.identity` field.
-- Check the source IP address and location from which the API call was made using the `sourceIPAddress` field to determine if it aligns with expected or known locations.
-- Investigate the timing of the restoration event by looking at the `@timestamp` field to see if it coincides with any other suspicious activities or anomalies in the environment.
-- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact.
-- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame.
-- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended.
-
-### False positive analysis
-
-- Routine database maintenance or testing activities may trigger the rule. Organizations should identify and document regular restoration activities performed by authorized personnel and exclude these from alerts.
-- Automated backup and restore processes used for disaster recovery or data migration can result in false positives. Users should configure exceptions for known automated processes by filtering based on specific user accounts or roles.
-- Development and staging environments often involve frequent restoration of databases for testing purposes. Exclude these environments by identifying and filtering out specific instance identifiers or tags associated with non-production environments.
-- Scheduled tasks or scripts that restore databases as part of regular operations can be mistaken for unauthorized activity. Ensure these tasks are well-documented and create exceptions based on the source IP or IAM role used for these operations.
-- Third-party services or integrations that require database restoration for functionality may trigger alerts. Verify these services and exclude their associated actions by identifying their unique user agents or API keys.
-
-### Response and remediation
-
-- Immediately isolate the restored RDS instance to prevent unauthorized access. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
-- Conduct a thorough review of CloudTrail logs to identify the source of the compromised credentials and any other suspicious activities associated with the same user or account.
-- Revoke the compromised credentials and issue new credentials for the affected user or service account. Ensure that multi-factor authentication (MFA) is enabled for all accounts.
-- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure.
-- Perform a security assessment of the restored RDS instance to identify any unauthorized changes or data exfiltration. This includes checking for unusual queries or data exports.
-- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly.
-- Review and update IAM policies to ensure that only authorized users have the necessary permissions to restore RDS instances, reducing the risk of future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
@@ -93,14 +165,34 @@ reference = "https://attack.mitre.org/techniques/T1578/"
 id = "T1578.002"
 name = "Create Cloud Instance"
 reference = "https://attack.mitre.org/techniques/T1578/002/"
+
 [[rule.threat.technique.subtechnique]]
 id = "T1578.004"
 name = "Revert Cloud Instance"
 reference = "https://attack.mitre.org/techniques/T1578/004/"
 
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

rules/integrations/aws/exfiltration_rds_snapshot_export.toml

@@ -2,62 +2,132 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
-description = "Identifies the export of an Amazon Relational Database Service (RDS) Aurora database snapshot."
+description = """
+Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or
+migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage.
+Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can
+indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information.
+"""
 false_positives = [
     """
-    Exporting snapshots 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. Snapshot exports from unfamiliar users or hosts should
-    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Snapshot exports may be performed by administrators, automation pipelines, or data engineering workflows. Confirm
+    whether the export was expected and initiated by an authorized user, role, or automation process. Snapshot exports
+    by unfamiliar principals or from unexpected networks should be investigated. If known behavior causes false
+    positives, it can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot Export"
 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.
+> 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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS Snapshot Export
 
-Amazon RDS Snapshot Export allows users to export Aurora database snapshots to Amazon S3, facilitating data analysis and backup. However, adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots without authorization. The detection rule monitors successful export tasks in AWS CloudTrail logs, flagging potential misuse by identifying unexpected or unauthorized snapshot exports.
+Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed
+RDS service boundary. While legitimate for analytics or migration, this action can also be a mechanism for data
+exfiltration. Because snapshot exports produce files that can be downloaded, shared, or accessed by other AWS principals,
+unauthorized exports may indicate staging for data theft or attempts to bypass database access controls.
 
-### Possible investigation steps
+This rule detects successful `StartExportTask` events. Activity of this type should be validated to ensure that only
+authorized database, platform engineering, or analytics workflows initiated the export.
 
-- Review the AWS CloudTrail logs for the specific event.action:StartExportTask to identify the user or role that initiated the export task.
-- Check the event.provider:rds.amazonaws.com logs to verify the source IP address and location from which the export task was initiated, looking for any anomalies or unexpected locations.
-- Investigate the event.dataset:aws.cloudtrail logs to determine the specific database snapshot that was exported and assess its sensitivity or criticality.
-- Cross-reference the event.outcome:success with IAM policies and permissions to ensure the user or role had legitimate access to perform the export task.
-- Analyze any recent changes in IAM roles or policies that might have inadvertently granted export permissions to unauthorized users.
-- Contact the data owner or relevant stakeholders to confirm whether the export task was authorized and aligns with business needs.
+#### Possible investigation steps
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal initiated the export.
+  - Look at `source.ip`, `user.name`, and `user_agent.original` to understand where the export originated (console, CLI, SDK, automation).
+  - Check whether the principal has historically performed snapshot exports.
+
+- **Determine what was exported**
+  - Examine `aws.cloudtrail.request_parameters`:
+    - Snapshot identifier being exported.
+    - S3 bucket name and path.
+    - KMS key used (or absence of encryption).
+  - Map the snapshot and destination bucket to:
+    - Application/owner team.
+    - Environment (prod/staging/dev).
+    - Data classification (PII, PHI, PCI, internal).
+
+- **Reconstruct timing and surrounding context**
+  - Use `@timestamp` to correlate the export with:
+    - Recent RDS modifications (`ModifyDBInstance`, `ModifyDBCluster`), snapshot deletions, or retention changes.
+    - IAM role changes, access key issuance, or privilege escalation attempts.
+    - Unusual authentication patterns (e.g., successful logins from new locations, failed console logins).
+  - Check whether the export timing aligns with approved deployments or maintenance windows.
+
+- **Correlate with broader CloudTrail activity**
+  - Pivot on the same user, role, or access key ID to look for:
+    - Prior reconnaissance (e.g., `DescribeDBSnapshots`, `DescribeDBClusters`, `ListBuckets`).
+    - Permission changes (`PutRolePolicy`, `AttachUserPolicy`).
+    - Public exposure (e.g., S3 bucket ACL changes).
+  - Determine whether multiple snapshots were exported around the same time.
+
+- **Validate intent with stakeholders**
+  - Confirm with the database owner, analytics team, or platform engineering team whether:
+    - The export was planned and authorized.
+    - The target S3 bucket is approved for storing database contents.
+    - Encryption and access controls meet organizational policy.
 
 ### False positive analysis
 
-- Routine data exports for legitimate business purposes may trigger alerts. Users should review export tasks to confirm they align with expected business operations and consider whitelisting known, authorized export activities.
-- Automated backup processes that regularly export snapshots to S3 can be mistaken for unauthorized actions. Identify and document these processes, then create exceptions in the monitoring system to prevent false alerts.
-- Development and testing environments often involve frequent snapshot exports for testing purposes. Ensure these environments are clearly identified and excluded from alerts by setting up specific rules or tags that differentiate them from production environments.
-- Exports initiated by third-party services or integrations that have been granted access to RDS snapshots might be flagged. Verify these integrations and adjust the detection rule to recognize and exclude these trusted services.
+- **Authorized data analytics or ETL workflows**
+  - Many organizations export snapshots for reporting, ML pipelines, or external data processing.
+  - Validate that the export aligns with documented ETL or analytics processes.
+
+- **Automated snapshot export tools**
+  - Backup pipelines, cost optimization, or data replication systems may export snapshots.
+  - Tune the rule by excluding known IAM roles or automation user agents.
+
+- **CloudFormation or IaC triggers**
+  - Infrastructure-as-code pipelines may trigger snapshot exports as part of stack updates.
+  - Correlate with CloudFormation events to confirm legitimacy.
 
 ### Response and remediation
 
-- Immediately revoke access to the AWS account or IAM role that initiated the unauthorized snapshot export to prevent further data exfiltration.
-- Conduct a thorough review of AWS CloudTrail logs to identify any other unauthorized activities associated with the same account or IAM role, and assess the scope of the potential data breach.
-- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized export and any other suspicious activities discovered.
-- Restore the affected database from a known good backup if data integrity is suspected to be compromised, ensuring that the restored data is free from unauthorized changes.
-- Implement stricter IAM policies and permissions to limit who can perform snapshot exports, ensuring that only authorized personnel have the necessary permissions.
-- Enhance monitoring and alerting mechanisms to detect any future unauthorized snapshot export attempts, ensuring timely response to similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve readiness for future incidents.
+- **Contain potential exfiltration**
+  - Review access to the destination S3 bucket and confirm that:
+    - Bucket is encrypted with the expected KMS key.
+    - Access is restricted to authorized principals.
+    - No unusual downloads or cross-account accesses occurred.
 
-## Setup
+- **Investigate scope and impact**
+  - Use CloudTrail to enumerate:
+    - All export tasks started by the same actor.
+    - Other snapshot or data-access API calls in the same time window.
+  - Validate whether sensitive or regulated data may have been included.
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Credential and access remediation**
+  - If activity appears unauthorized:
+    - Revoke or rotate compromised IAM credentials.
+    - Review STS session activity related to the actor.
+    - Inspect IAM role policies for privilege escalation.
+
+- **Hardening and preventive controls**
+  - Restrict the ability to call `StartExportTask` using:
+    - IAM least-privilege policies.
+    - Service Control Policies (SCPs) in production accounts.
+    - Conditional IAM (e.g., requiring MFA, restricting by VPC endpoint or IP range).
+  - Enable guardrails:
+    - AWS Config/Security Hub controls for monitoring snapshot policy changes.
+    - Alerts for exports to buckets outside approved accounts.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+
+"""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html"]
 risk_score = 21
 rule_id = "119c8877-8613-416d-a98a-96b6664ee73a"
@@ -67,6 +137,7 @@ tags = [
     "Data Source: AWS",
     "Data Source: Amazon Web Services",
     "Use Case: Asset Visibility",
+    "Tactic: Collection",
     "Tactic: Exfiltration",
     "Resources: Investigation Guide",
 ]
@@ -74,7 +145,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:StartExportTask and event.outcome:success
+event.dataset: aws.cloudtrail 
+    and event.provider: rds.amazonaws.com 
+    and event.action: StartExportTask 
+    and event.outcome: success
 '''
 
 
@@ -85,4 +159,38 @@ framework = "MITRE ATT&CK"
 id = "TA0010"
 name = "Exfiltration"
 reference = "https://attack.mitre.org/tactics/TA0010/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1213"
+name = "Data from Information Repositories"
+reference = "https://attack.mitre.org/techniques/T1213/"
+[[rule.threat.technique.subtechnique]]
+id = "T1213.006"
+name = "Databases"
+reference = "https://attack.mitre.org/techniques/T1213/006/"
+
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
 

rules/integrations/aws/impact_rds_instance_cluster_deletion.toml

@@ -2,71 +2,137 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora database cluster, global database cluster,
-or database instance.
+Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these
+resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient
+permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the
+environment.
 """
 false_positives = [
     """
-    Clusters or instances may be deleted by a system administrator. Verify whether the user identity, user agent, and/or
-    hostname should be making changes in your environment. Cluster or instance deletions by unfamiliar users or hosts
-    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    RDS instances or clusters may be intentionally deleted by database administrators or during planned decommissioning
+    activities. Verify the user identity, source IP, and change context to ensure the deletion is expected.
+    CloudFormation stack removals and automated cleanup workflows may also trigger these events and can be exempted if
+    known and authorized.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
-name = "AWS Deletion of RDS Instance or Cluster"
+name = "AWS RDS DB Instance or Cluster 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.
+> 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, validate and adapt it to suit your operational needs.
 
-### Investigating AWS Deletion of RDS Instance or Cluster
+### Investigating AWS RDS DB Instance or Cluster Deleted
 
-Amazon RDS simplifies database management by automating tasks like setup and scaling. However, adversaries can exploit this by deleting RDS instances or clusters, causing data loss and service disruption. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity aimed at data destruction.
+This rule detects the deletion of an RDS DB instance, Aurora DB cluster, or global database cluster. These operations permanently remove stored data and backups unless final snapshots are explicitly retained. Adversaries may delete RDS resources as part of a destructive attack, to eliminate forensic evidence, or to disrupt critical workloads. Because deletions are irreversible without backups, immediate review is required to determine whether the action was authorized and assess potential data loss.
 
-### Possible investigation steps
+#### Possible investigation steps
 
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider as rds.amazonaws.com and event.action values such as DeleteDBCluster, DeleteGlobalCluster, or DeleteDBInstance.
-- Identify the user or role responsible for the deletion by examining the user identity information in the CloudTrail logs, and verify if the action aligns with their typical behavior or responsibilities.
-- Check the event time and correlate it with any other suspicious activities or alerts in the AWS environment to determine if the deletion is part of a broader attack pattern.
-- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as IAM policy changes or unusual login attempts, to assess if the account may have been compromised.
-- Assess the impact of the deletion by identifying the specific RDS instance or cluster affected and determining the potential data loss or service disruption caused by the action.
-- Contact the responsible team or individual to verify if the deletion was intentional and authorized, and if not, initiate incident response procedures to mitigate further risk.
+**Identify the Actor**
+- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action.
+- Validate:
+  - Is this user/role authorized to delete DB instances or clusters?
+  - Does this action align with past behavior?
+
+**Review the Deletion Event**
+- Confirm which action was invoked: `DeleteDBInstance`, `DeleteDBCluster` or `DeleteGlobalCluster`
+- Examine `aws.cloudtrail.request_parameters` and `target.entity.id`. Identify which resource was deleted and whether a final snapshot was created before deletion.
+
+**Analyze Source and Access Context**
+- Check `source.ip`, `source.geo` fields and `user_agent.original`
+- Validate whether:
+  - The request originated from a known network or VPN.
+  - The user normally logs in from this location.
+  - The call was made via AWS Console vs CLI vs SDK.
+
+**Correlate Surrounding Activity**
+Search CloudTrail for:
+- Recent IAM role or policy changes.
+- Privilege escalation events (STS AssumeRole, CreateAccessKey, AttachUserPolicy).
+- Disablement of related safety controls:
+  - deletionProtection modified to `false`
+  - backupRetentionPeriod set to `0`
+- Suspicious sequencing:
+  - Snapshots deleted before the instance/cluster deletion.
+  - Network security group modifications enabling broader access before deletion.
+
+**Validate Organizational Intent**
+- Contact the service owner or DB administrator to confirm whether the deletion is expected.
+
+**Assess Impact and Data Recovery Path**
+- Identify which DB instance or cluster was deleted (`target.entity.id`)
+- Evaluate:
+  - Whether automated backups existed.
+  - Whether point-in-time recovery is still possible.
+  - Whether a final snapshot was created.
 
 ### False positive analysis
 
-- Routine maintenance activities by database administrators can trigger alerts when they intentionally delete RDS instances or clusters. To manage this, create exceptions for known maintenance windows or specific administrator actions.
-- Automated scripts or tools used for testing and development purposes might delete RDS resources as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
-- Scheduled decommissioning of outdated or unused RDS instances can also result in false positives. Maintain an updated list of decommissioning schedules and exclude these from the detection rule.
-- CloudFormation stack deletions that include RDS resources can lead to alerts. Monitor CloudFormation activities and correlate them with RDS deletions to differentiate between legitimate and suspicious actions.
+- **Planned decommissioning**:  
+  - Confirm if this action aligns with a scheduled removal or environment cleanup.
+- **CloudFormation stack deletion**:  
+  - Stack teardown often deletes RDS resources; confirm if this occurred.
+- **Automated testing or ephemeral environments**:  
+  - Test/dev pipelines may frequently create and delete clusters.
+- **Infrastructure-as-code workflows**:  
+  - Terraform destroys or GitOps cleanup jobs can generate legitimate deletion events.
 
 ### Response and remediation
 
-- Immediately isolate the affected AWS account to prevent further unauthorized actions. This can be done by revoking access keys and disabling any suspicious IAM user accounts or roles involved in the deletion.
-- Initiate a recovery process for the deleted RDS instance or cluster using available backups or snapshots. Ensure that the restoration is performed in a secure environment to prevent further compromise.
-- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the deletion event. This will help in understanding the scope of the breach and identifying potential entry points.
-- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected.
-- Implement enhanced monitoring and alerting for AWS RDS and other critical resources to detect similar deletion attempts in the future. This includes setting up alerts for any unauthorized changes to IAM policies or roles.
-- Review and strengthen IAM policies to ensure the principle of least privilege is enforced, reducing the risk of unauthorized deletions by limiting permissions to only those necessary for specific roles.
-- Communicate with stakeholders and affected parties about the incident, outlining the steps taken for recovery and measures implemented to prevent future occurrences.
+**If the deletion was unauthorized:**
+**Immediately restrict the actor**
+   - Disable or revoke the user’s access keys.
+   - Revoke active session tokens.
 
-## Setup
+**Attempt recovery**
+   - Restore from:
+     - Final snapshot (if created)
+     - Automated backups
+   - Rebuild cluster/instance configurations based on IaC or documented templates.
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+**Perform full log review**
+   - CloudTrail, RDS Enhanced Monitoring, and VPC Flow Logs
+   - Identify lateral movement or privilege escalation preceding the deletion.
+
+**Scope and contain the incident**
+   - Determine whether:
+     - Additional RDS resources were targeted
+     - IAM permissions were modified
+     - Other destructive API calls were made
+
+**Hardening actions**
+   - Enable deletionProtection on all critical instances/clusters.
+   - Require final snapshot creation for all deletion operations.
+   - Enforce MFA for IAM users with RDS privileges.
+   - Limit RDS modification/deletion permissions to specific IAM roles.
+
+**Documentation and Follow-Up**
+   - Update incident response runbooks.
+   - Communicate with service owners and leadership.
+   - Add enhanced monitoring rules around:
+     - Snapshot deletions
+     - Backup retention modifications
+     - RDS role changes
+     - DeletionProtection disable events
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
-    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-cluster.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html",
-    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-global-cluster.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html",
-    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-instance.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html",
 ]
 risk_score = 47
@@ -85,8 +151,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance)
-and event.outcome:success
+event.dataset: aws.cloudtrail 
+    and event.provider: rds.amazonaws.com 
+    and event.action: (DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance)
+    and event.outcome: success
 '''
 
 
@@ -103,3 +171,21 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml

@@ -2,16 +2,21 @@
 creation_date = "2024/06/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment.
+Identifies the modification of an AWS RDS DB instance or cluster to disable the deletionProtection feature. Deletion
+protection prevents accidental or unauthorized deletion of RDS resources. Adversaries with sufficient permissions may
+disable this protection as a precursor to destructive actions, including the deletion of databases containing sensitive
+or business-critical data. This rule alerts when deletionProtection is explicitly set to false on an RDS DB instance or
+cluster.
 """
 false_positives = [
     """
-    The deletionProtection feature must be disabled as a prerequisite for deletion of a DB instance or cluster. Ensure that the instance should not be modified in this way before taking action.
+    The deletionProtection feature must be disabled as a prerequisite for deletion of a DB instance or cluster. Ensure
+    that the instance should not be modified in this way before taking action.
     """,
 ]
 from = "now-6m"
@@ -19,40 +24,79 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled"
-note = """
-## Triage and analysis
+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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
+ 
+Deletion protection is designed to safeguard RDS DB instances and clusters from accidental or unauthorized deletion. An adversary with privileged access in a compromised environment, can disable this safeguard before issuing a `DeleteDBInstance` or `DeleteDBCluster` action. This rule detects successful attempts to modify deletionProtection and set it to false on any RDS instance or cluster.
 
-This rule identifies when the deletion protection feature is removed from an RDS DB instance or cluster. Removing deletion protection is a prerequisite for deleting a DB instance. Adversaries may exploit this feature to permanently delete data in a compromised environment.
+#### Possible investigation steps
 
-#### Possible Investigation Steps
+- **Identify the Actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change.
+  - Validate whether this principal normally performs RDS lifecycle operations.
 
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance` actions where the deletionProtection parameter was changed.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB instance or cluster identifier and any other modifications made to the instance.
-- **Verify the Modified Instance**: Check the DB instance that was modified and its contents to determine the sensitivity of the data stored within it.
-- **Contextualize with Recent Changes**: Compare this modification event against recent changes in RDS DB instance or cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Interview Relevant Personnel**: If the modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
-### False Positive Analysis
+- **Review Event Details**
+  - Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` to confirm the targeted DB instance or cluster identifier.
+  - Confirm that the request explicitly contains `deletionProtection=false`.
 
-- **Legitimate Instance Modification**: Confirm if the DB instance modification aligns with legitimate tasks.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+- **Contextualize the Change**
+  - Determine if recent activities justify the removal of deletion protection (migration, decommissioning, or maintenance).
+  - Compare the timestamp to normal operational hours or deployment windows.
 
-### Response and Remediation
+- **Correlate with Additional Activity**
+  - Look for subsequent or preceding RDS actions such as:
+    - `DeleteDBInstance`
+    - `DeleteDBCluster`
+    - Security group modifications
+    - Changes to parameter groups or backup retention policies.
+  - Sudden removal of backups or snapshots may indicate imminent destructive activity.
 
-- **Immediate Review and Reversal**: If the change was unauthorized, reset deletionProtection to true.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
-- **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+- **Verify Environmental Risk**
+  - Assess the sensitivity of data stored in the affected DB instance or cluster.
+  - Determine if the instance is production, customer-facing, or mission-critical.
 
-### Additional Information:
+- **Interview Relevant Personnel**
+  - Confirm with service owners or DB administrators whether the modification was intended and approved.
 
-For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
-- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
-- [Deleting AWS RDS DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html)
+### False positive analysis
+
+- **Expected Decommissioning**
+  - Instances undergoing teardown or migration legitimately require deletion protection to be disabled first.
+
+- **Inconsistent Historical Behavior**
+  - Compare the action to historical modification patterns for the user or role. If the action aligns with past legitimate changes, it may not be suspicious.
+
+### Response and remediation
+
+- **Immediate Remediation**
+  - If unauthorized, re-enable deletion protection (`deletionProtection=true`) on the affected DB instance or cluster.
+  - Review security groups, backup retention, and snapshot policies for additional unauthorized changes.
+
+- **Access Review**
+  - Investigate credential exposure for the IAM principal that performed the action.
+  - Rotate access keys or temporarily revoke permissions if compromise is suspected.
+
+- **Containment**
+  - If destructive intent is suspected, apply guardrails (e.g., IAM condition keys, SCPs) to prevent DB deletion.
+
+- **Audit and Harden**
+  - Ensure RDS instances adhere to least-privilege principles.
+  - Restrict who can modify `ModifyDBInstance` or `ModifyDBCluster` destructive settings, such as deletion protection, backup retention, and public accessibility.
+
+- **Incident Response Activation**
+  - Treat unauthorized removal of deletion protection as a high-risk precursor to data destruction.
+  - Trigger IR processes for containment, root cause analysis, and post-incident hardening.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
 """
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
@@ -95,3 +139,21 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

rules/integrations/aws/impact_rds_snapshot_deleted.toml

@@ -2,16 +2,22 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of an AWS RDS DB snapshot. Snapshots contain a full backup of an entire DB instance. Unauthorized deletion of snapshots can make it impossible to recover critical or sensitive data. This rule detects deleted snapshots and instances modified so that backupRetentionPeriod is set to 0 which disables automated backups and is functionally similar to deleting the system snapshot.
+Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a
+DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting
+"backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate
+permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for
+follow-on destructive actions such as instance or cluster deletion.
 """
 false_positives = [
     """
-    Snapshots may be deleted by a system administrator. Verify whether the user identity should be making changes in your environment. Snapshot deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Snapshots may be deleted by a system administrator. Verify whether the user identity should be making changes in
+    your environment. Snapshot 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-6m"
@@ -19,6 +25,103 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot 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, validate and adapt it to suit your operational needs.
+
+### Investigating AWS RDS Snapshot Deleted
+
+AWS RDS snapshots (manual or automated) and backup retention settings are core to database recovery and incident response. Deleting snapshots or disabling automated backups (`backupRetentionPeriod=0`) can prevent restoration to a known-good state and destroy forensic evidence of attacker actions.
+
+This rule detects successful snapshot deletions and configuration changes that disable automated backups. Activity that matches this pattern may indicate destructive actions, ransomware preparation, cleanup after data theft, or an operator misconfiguration that materially weakens recovery options.
+
+#### Possible investigation steps
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action.
+  - Check `user.name`, `source.ip`, and `user_agent.original` to understand where and how the change was made (console, CLI, SDK, automation).
+
+- **Determine what was affected**
+  - Inspect `aws.cloudtrail.request_parameters` to identify:
+    - The snapshot or cluster snapshot identifier (`DeleteDBSnapshot` / `DeleteDBClusterSnapshot`).
+    - The DB instance identifier and the new `backupRetentionPeriod` value for `ModifyDBInstance`.
+  - Map the snapshot/instance to:
+    - Application/owner team.
+    - Environment (prod, staging, dev).
+    - Data sensitivity or criticality.
+
+- **Reconstruct intent and timing**
+  - Use `@timestamp` to correlate the event with:
+    - Recent `ModifyDBInstance`, `ModifyDBCluster`, `DeleteDBInstance`, or `DeleteDBCluster` events.
+    - Other data-impacting changes (e.g., `deletionProtection=false`, security group changes, public accessibility, or RDS parameter modifications).
+  - Compare the timing against approved maintenance/change windows and deployment pipelines.
+
+- **Correlate with broader activity**
+  - In CloudTrail, pivot on:
+    - The same `aws.cloudtrail.user_identity.arn` or access key ID.
+    - The same DB instance/cluster identifiers.
+  - Look for:
+    - Suspicious reads or exports before deletion (`DescribeDBSnapshots`, `CopyDBSnapshot`, data export, or large `SELECT` / dump activity visible via other telemetry).
+    - Follow-on destructive actions (DB instance deletion, subnet/security group changes that isolate monitoring tools, or IAM policy changes).
+  - Verify whether other snapshots for the same instance or account were deleted in the same time window.
+
+- **Validate intent with owners**
+  - Confirm with the DB/application owner and platform/DBA teams whether:
+    - The snapshot deletion or backup change was requested and approved.
+    - There are parallel infrastructure changes (migrations, environment teardown, or cost-optimization tasks) that explain the activity.
+
+### False positive analysis
+
+- **Planned lifecycle and cost optimization**
+  - Many environments routinely prune old snapshots or adjust backup retention for non-production workloads.
+
+- **Automated backup and housekeeping tools**
+  - Backup or housekeeping services may manage snapshots and retention. This rule already excludes typical `backup.amazonaws.com` events, but you should:
+    - Identify any additional in-house or third-party automation roles.
+    - Tune the rule with exceptions based on `user_agent.original`, `aws.cloudtrail.user_identity.arn`, or known service roles.
+
+### Response and remediation
+
+- **Contain and restore protection**
+  - If activity appears unauthorized:
+    - Immediately review the affected DB instances and clusters and restore `backupRetentionPeriod` to an appropriate value.
+    - Verify that deletion protection and other guardrails are enabled where applicable.
+  - For snapshot deletions, assess:
+    - Whether alternate snapshots (manual or automated) are still available.
+    - Whether point-in-time recovery is still possible based on transaction logs and remaining backups.
+
+- **Investigate scope and impact**
+  - Use CloudTrail to:
+    - Enumerate all recent snapshot deletions and backup configuration changes by the same actor or from the same `source.ip`.
+    - Identify any subsequent `DeleteDBInstance`, `DeleteDBCluster`, or public exposure (`publiclyAccessible=true`) events.
+  - Engage the application and data owners to:
+    - Evaluate potential data loss, downtime impact, and regulatory implications.
+    - Determine if any sensitive or compliance-bound data may be unrecoverable.
+
+- **Hardening and preventive controls**
+  - Restrict RDS administration:
+    - Limit `rds:DeleteDBSnapshot`, `rds:DeleteDBClusterSnapshot`, and `rds:ModifyDBInstance` (especially backup and deletion-related parameters) to a small set of privileged roles.
+    - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:RequestedRegion`) to constrain where and by whom destructive actions can be performed.
+  - Add guardrails:
+    - Use AWS Config rules and/or Security Hub controls to detect:
+      - Instances with `backupRetentionPeriod=0`.
+      - Instances lacking deletion protection or cross-region/cross-AZ backup strategy.
+    - Consider SCPs in AWS Organizations to block or tightly control destructive RDS APIs in production accounts.
+
+- **Post-incident improvements**
+  - If malicious or unsafe behavior is confirmed:
+    - Rotate credentials for the involved principals and review STS session usage.
+    - Update runbooks and change management to explicitly track snapshot and backup policy changes.
+    - Refine this rule’s exceptions, tags, or severity to better align with your environment while preserving coverage for truly risky events.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSnapshot.html",
@@ -46,41 +149,11 @@ any where event.dataset == "aws.cloudtrail"
         event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
+    and not (
+        user_agent.original == "backup.amazonaws.com" 
+        and source.address == "backup.amazonaws.com"
+    )
 '''
-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 AWS RDS Snapshot Deleted
-
-AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the user or role associated with the event.action values "DeleteDBSnapshot" or "DeleteDBClusterSnapshot" to determine if the action was authorized or expected.
-- Check the timestamp of the deletion event to correlate with any known maintenance activities or incidents that might explain the snapshot deletion.
-- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns.
-- Examine the AWS IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and to identify any potential over-permissioning.
-- Look for any recent changes in the AWS environment, such as modifications to IAM roles or policies, that could have allowed unauthorized snapshot deletions.
-- If the event.action is "ModifyDBInstance" with "backupRetentionPeriod=0", verify if there was a legitimate reason for disabling automated backups and assess the impact on data recovery capabilities.
-
-### False positive analysis
-
-- Routine maintenance activities by database administrators may involve deleting old or unnecessary snapshots. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated IAM roles or user accounts.
-- Testing environments often involve frequent creation and deletion of snapshots. Consider excluding specific RDS instances or environments used solely for testing purposes to reduce noise in alerts.
-- Scheduled cleanup jobs that remove outdated snapshots to manage storage costs can trigger false positives. Document these jobs and adjust the detection rule to ignore actions performed by these jobs' IAM roles.
-
-### Response and remediation
-
-- Immediately revoke access to AWS accounts or roles suspected of unauthorized activity to prevent further malicious actions.
-- Restore the deleted RDS snapshots from any available backups or replicas to ensure data recovery and continuity.
-- Enable and configure automated backups for the affected RDS instances to prevent future data loss, ensuring the backupRetentionPeriod is set to a non-zero value.
-- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the snapshot deletion.
-- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources were compromised.
-- Implement stricter IAM policies and multi-factor authentication for accessing AWS RDS resources to enhance security and prevent unauthorized deletions.
-- Update and test the incident response plan to include specific procedures for handling AWS RDS snapshot deletions, ensuring rapid response in future incidents."""
 
 
 [[rule.threat]]
@@ -96,3 +169,20 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

rules/integrations/aws/persistence_rds_db_instance_password_modified.toml

@@ -2,16 +2,23 @@
 creation_date = "2024/06/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation.
+Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password
+is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain
+access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment.
+Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to
+sensitive data stores.
 """
+event_category_override = "event.type"
 false_positives = [
     """
-    Master password change is a legitimate means to regain access to a DB instance in the case of a lost password. Ensure that the instance should not be modified in this way before taking action.
+    Master password modification may occur during legitimate administrative recovery (e.g., a lost password, rotation
+    event, or Secrets Manager reassociation). Validate whether the change was expected, approved, and performed by
+    authorized personnel. If known workflows routinely perform this action, consider adding targeted exceptions.
     """,
 ]
 from = "now-6m"
@@ -19,40 +26,86 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Password Modified"
-note = """
-## Triage and analysis
+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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS DB Instance or Cluster Password Modified
 
-This rule identifies when an RDS DB instance or cluster password is modified. While changing the master password is a legitimate means to regain access in the case of a lost password, adversaries may exploit this feature to maintain persistence or evade defenses in a compromised environment.
+The RDS master user password controls privileged access to a database instance or cluster. Modifying it can immediately shift access from one operator to another, break application functionality, or allow an adversary to regain control over a compromised DB instance. Because RDS never returns the password via API, this operation is a strong signal of intentional access reconfiguration.
 
-#### Possible Investigation Steps
+This rule detects successful password-modification events via `ModifyDBInstance` or `ModifyDBCluster`. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion.
 
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance` actions where the masterUserPassword parameter was changed.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB Instance Identifier and any other modifications made to the instance.
-- **Verify the Modified Instance**: Check the DB instance that was modified and its contents to determine the sensitivity of the data stored within it.
-- **Contextualize with Recent Changes**: Compare this modification event against recent changes in RDS DB or Cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Interview Relevant Personnel**: If the modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
-### False Positive Analysis
+#### Possible investigation steps
 
-- **Legitimate Instance Modification**: Confirm if the DB instance modification aligns with legitimate tasks.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+- **Identify the actor and execution context**  
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+  - Inspect `user.name`, `source.ip`, and `user_agent.original` to determine whether the modification originated from expected networks, automation roles, or unusual sources.
 
-### Response and Remediation
+- **Determine what was modified**  
+  - Examine `aws.cloudtrail.request_parameters` to identify:  
+    - The DB instance or cluster identifier.  
+    - Whether other parameters were modified in the same call (e.g., `manageMasterUserPassword`, engine version, instance class, parameter group).  
+  - Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact.
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance password. If the master user password was managed with AWS Secrets Manager, determine whether the `manageMasterUserPassword` attribute was changed to false and revert if necessary.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
-- **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+- **Reconstruct timing and associated actions**  
+  - Use `@timestamp` to compare the event against:  
+    - Recent configuration changes such as `ModifyDBInstance`, `ModifyDBCluster`, or networking/security group updates.  
+    - Other access-related operations (e.g., `AddRoleToDBInstance`, changes to Secrets Manager associations, disabling deletion protection).  
+  - Check for signs of credential misuse leading up to the event (e.g., `DescribeDBInstances`, `GetCallerIdentity`, unauthorized console logins).
 
-### Additional Information:
+- **Correlate with broader activity**  
+  - Pivot in CloudTrail using the same access key, principal ARN, or source IP.  
+  - Look for:  
+    - Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation).  
+    - Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion.  
+    - Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions).
 
-For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
-- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
-- [Amazon RDS and Secrets Manager](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html)
+- **Validate intent with operational owners**  
+  - Confirm with DBAs, platform engineers, and application owners whether the password change:  
+    - Was requested or scheduled.  
+    - Aligns with pending migrations, credential rotations, or recovery actions.  
+  - If not recognized, treat this as a high-risk event requiring deeper containment.
+
+### False positive analysis
+
+- **Recovery or maintenance tasks**  
+  - Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow.
+- **Secrets Manager integration changes**  
+  - When `manageMasterUserPassword` is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change.
+- **Non-production workloads**  
+  - Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation.
+
+### Response and remediation
+
+- **Contain unauthorized access**  
+  - If activity is suspicious:  
+    - Immediately rotate the master password again using a secure, validated workflow.  
+    - Verify whether Secrets Manager integration was disabled (`manageMasterUserPassword=false`) and restore it if necessary.  
+    - Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily.
+
+- **Investigate surrounding activity**  
+  - Review CloudTrail to identify:  
+    - Who accessed the instance after the password change.  
+    - Whether any destructive or data-exfiltrating RDS actions occurred.  
+    - Other IAM or STS activity tied to the same user or session.
+
+- **Restore guardrails and enhance monitoring**  
+  - Ensure deletion protection, backup retention, and networking controls are correctly configured.  
+  - Add real-time alerts for password-related modifications and high-risk RDS API actions.
+
+- **Strengthen IAM and operational controls**  
+  - Limit permissions for `rds:ModifyDBInstance` and `rds:ModifyDBCluster`, especially when modifying authentication parameters.  
+  - Require MFA and role-based access for DB administrators.  
+  - Tighten SCPs or Config rules to restrict unauthorized DB configuration changes.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
 """
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
@@ -77,7 +130,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.action in ("ModifyDBInstance", "ModifyDBCluster")
     and event.outcome == "success"
@@ -96,6 +149,8 @@ id = "T1098.001"
 name = "Additional Cloud Credentials"
 reference = "https://attack.mitre.org/techniques/T1098/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
@@ -114,3 +169,22 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

rules/integrations/aws/persistence_rds_instance_made_public.toml

@@ -2,16 +2,21 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the creation or modification of an AWS RDS DB instance to enable public access. DB instances may contain sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may enable public access on a DB instance to maintain persistence or evade defenses by bypassing access controls.
+Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute
+is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow
+unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM
+policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to
+establish persistence, move data outside of controlled network boundaries, or bypass internal access controls.
 """
 false_positives = [
     """
-    Public access is a common configuration used to enable access from outside a private VPC. Ensure that the instance should not be modified in this way before taking action.
+    Public access is a common configuration used to enable access from outside a private VPC. Ensure that the instance
+    should not be modified in this way before taking action.
     """,
 ]
 from = "now-6m"
@@ -19,39 +24,93 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Made Public"
-note = """
-## Triage and analysis
+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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS DB Instance Made Public
 
-This rule identifies when an RDS DB instance is created or modified to enable public access. While publicly accessible DB instances are a common practice, adversaries may exploit this feature to maintain persistence or evade defenses in a compromised environment.
+This rule detects when an Amazon RDS DB instance or cluster is created or modified with
+`publiclyAccessible=true`. While some environments operate publicly accessible RDS instances,
+unexpected exposure of a database to the internet is a meaningful security risk. Adversaries who
+gain access to AWS credentials may modify a DB instance’s public accessibility to exfiltrate data,
+establish persistence, or bypass internal network restrictions. 
 
 #### Possible Investigation Steps
 
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Creation/Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance`, `CreateDBInstance` or `CreateDBCluster` actions where the publiclyAccessible parameter was set to true.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB Instance Identifier and any other modifications made to the instance.
-- **Verify the Created/Modified Instance**: Check the DB instance that was created or modified and its contents to determine the sensitivity of the data stored within it.
-- **Contextualize with Recent Changes**: Compare this event against recent changes in RDS DB or Cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this event to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Interview Relevant Personnel**: If the modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change.
+  - Determine whether the user, role, or automation service typically manages RDS configurations.
+
+- **Examine the request parameters**
+  - Review `aws.cloudtrail.request_parameters` for:
+    - `publiclyAccessible=true`
+    - DBInstanceIdentifier / DBClusterIdentifier
+    - Additional changes included in the same modification request (e.g., master user changes, security group updates)
+
+- **Validate the target resource**
+  - Determine the sensitivity of the instance (`target.entity.id`):
+    - What data does it store?
+    - Is it production, staging, dev, or ephemeral?
+  - Confirm whether the instance was previously private.
+
+- **Assess network exposure**
+  - Check associated security groups for:
+    - `0.0.0.0/0` (unrestricted ingress)
+    - Unexpected IP ranges  
+  - Review VPC/subnet placement to determine if the instance is reachable externally.
+
+- **Correlate with other recent CloudTrail activity**
+  - Look for related events performed by the same actor:
+    - `AuthorizeSecurityGroupIngress`
+    - `ModifyDBInstance`
+    - IAM policy modifications enabling broader DB access
+  - Look for indicators of credential misuse:
+    - unusual `source.ip`
+    - unusual `user_agent.original`
+    - MFA not used (`session_context.mfa_authenticated=false`)
+
+- **Validate intent with owners**
+  - Contact the service or database owner to confirm whether the change was an approved part of a deployment or migration.
+
 ### False Positive Analysis
 
-- **Legitimate Instance Configuration**: Confirm if the DB instance creation or modification aligns with legitimate tasks.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+- **Expected public-access configuration**
+  - Some workloads intentionally require public access (e.g., internet-facing reporting tools).
+  - Validate against change management tickets, deployment pipelines, or Terraform/IaC automation logs.
 
 ### Response and Remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
-- **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+- **Containment**
+  - If exposure is unauthorized:
+    - Modify the instance to disable public access (`publiclyAccessible=false`).
+    - Restrict the security group inbound rules immediately.
+    - Snapshot the instance to preserve state if compromise is suspected.
+
+- **Investigation**
+  - Review all recent actions from the same IAM principal.
+  - Check for data access patterns (CloudWatch, RDS Enhanced Monitoring, VPC Flow Logs).
+  - Identify whether this exposure correlates with suspicious outbound network activity.
+
+- **Hardening**
+  - Require private-only RDS instances unless explicitly documented.
+  - Enforce security group least privilege and block public DB access via:
+    - AWS Config rules (`rds-instance-public-access-check`)
+    - Service Control Policies (SCPs) preventing public RDS settings
+  - Implement continuous monitoring for network or configuration drift.
+
+- **Recovery**
+  - Restore the database to a private subnet if necessary.
+  - Rotate credentials used by the DB instance and associated applications.
+  - Document the incident and update policies or IaC templates to prevent recurrence.
 
 ### Additional Information:
 
-For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
-- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
 """
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
@@ -86,6 +145,7 @@ any where event.dataset == "aws.cloudtrail"
     )
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -97,6 +157,8 @@ id = "T1556.009"
 name = "Conditional Access Policies"
 reference = "https://attack.mitre.org/techniques/T1556/009/"
 
+
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
@@ -108,3 +170,22 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+