AWS RDS Snapshot Deleted

  1[metadata]
  2creation_date = "2024/06/29"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/11/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a
 11DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting
 12"backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate
 13permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for
 14follow-on destructive actions such as instance or cluster deletion.
 15"""
 16false_positives = [
 17    """
 18    Snapshots may be deleted by a system administrator. Verify whether the user identity should be making changes in
 19    your environment. Snapshot deletions by unfamiliar users or hosts should be investigated. If known behavior is
 20    causing false positives, it can be exempted from the rule.
 21    """,
 22]
 23from = "now-6m"
 24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "AWS RDS Snapshot Deleted"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
 32> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
 33
 34### Investigating AWS RDS Snapshot Deleted
 35
 36AWS 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.
 37
 38This 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.
 39
 40#### Possible investigation steps
 41
 42- **Identify the actor and context**
 43  - 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.
 44  - Check `user.name`, `source.ip`, and `user_agent.original` to understand where and how the change was made (console, CLI, SDK, automation).
 45
 46- **Determine what was affected**
 47  - Inspect `aws.cloudtrail.request_parameters` to identify:
 48    - The snapshot or cluster snapshot identifier (`DeleteDBSnapshot` / `DeleteDBClusterSnapshot`).
 49    - The DB instance identifier and the new `backupRetentionPeriod` value for `ModifyDBInstance`.
 50  - Map the snapshot/instance to:
 51    - Application/owner team.
 52    - Environment (prod, staging, dev).
 53    - Data sensitivity or criticality.
 54
 55- **Reconstruct intent and timing**
 56  - Use `@timestamp` to correlate the event with:
 57    - Recent `ModifyDBInstance`, `ModifyDBCluster`, `DeleteDBInstance`, or `DeleteDBCluster` events.
 58    - Other data-impacting changes (e.g., `deletionProtection=false`, security group changes, public accessibility, or RDS parameter modifications).
 59  - Compare the timing against approved maintenance/change windows and deployment pipelines.
 60
 61- **Correlate with broader activity**
 62  - In CloudTrail, pivot on:
 63    - The same `aws.cloudtrail.user_identity.arn` or access key ID.
 64    - The same DB instance/cluster identifiers.
 65  - Look for:
 66    - Suspicious reads or exports before deletion (`DescribeDBSnapshots`, `CopyDBSnapshot`, data export, or large `SELECT` / dump activity visible via other telemetry).
 67    - Follow-on destructive actions (DB instance deletion, subnet/security group changes that isolate monitoring tools, or IAM policy changes).
 68  - Verify whether other snapshots for the same instance or account were deleted in the same time window.
 69
 70- **Validate intent with owners**
 71  - Confirm with the DB/application owner and platform/DBA teams whether:
 72    - The snapshot deletion or backup change was requested and approved.
 73    - There are parallel infrastructure changes (migrations, environment teardown, or cost-optimization tasks) that explain the activity.
 74
 75### False positive analysis
 76
 77- **Planned lifecycle and cost optimization**
 78  - Many environments routinely prune old snapshots or adjust backup retention for non-production workloads.
 79
 80- **Automated backup and housekeeping tools**
 81  - Backup or housekeeping services may manage snapshots and retention. This rule already excludes typical `backup.amazonaws.com` events, but you should:
 82    - Identify any additional in-house or third-party automation roles.
 83    - Tune the rule with exceptions based on `user_agent.original`, `aws.cloudtrail.user_identity.arn`, or known service roles.
 84
 85### Response and remediation
 86
 87- **Contain and restore protection**
 88  - If activity appears unauthorized:
 89    - Immediately review the affected DB instances and clusters and restore `backupRetentionPeriod` to an appropriate value.
 90    - Verify that deletion protection and other guardrails are enabled where applicable.
 91  - For snapshot deletions, assess:
 92    - Whether alternate snapshots (manual or automated) are still available.
 93    - Whether point-in-time recovery is still possible based on transaction logs and remaining backups.
 94
 95- **Investigate scope and impact**
 96  - Use CloudTrail to:
 97    - Enumerate all recent snapshot deletions and backup configuration changes by the same actor or from the same `source.ip`.
 98    - Identify any subsequent `DeleteDBInstance`, `DeleteDBCluster`, or public exposure (`publiclyAccessible=true`) events.
 99  - Engage the application and data owners to:
100    - Evaluate potential data loss, downtime impact, and regulatory implications.
101    - Determine if any sensitive or compliance-bound data may be unrecoverable.
102
103- **Hardening and preventive controls**
104  - Restrict RDS administration:
105    - Limit `rds:DeleteDBSnapshot`, `rds:DeleteDBClusterSnapshot`, and `rds:ModifyDBInstance` (especially backup and deletion-related parameters) to a small set of privileged roles.
106    - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:RequestedRegion`) to constrain where and by whom destructive actions can be performed.
107  - Add guardrails:
108    - Use AWS Config rules and/or Security Hub controls to detect:
109      - Instances with `backupRetentionPeriod=0`.
110      - Instances lacking deletion protection or cross-region/cross-AZ backup strategy.
111    - Consider SCPs in AWS Organizations to block or tightly control destructive RDS APIs in production accounts.
112
113- **Post-incident improvements**
114  - If malicious or unsafe behavior is confirmed:
115    - Rotate credentials for the involved principals and review STS session usage.
116    - Update runbooks and change management to explicitly track snapshot and backup policy changes.
117    - Refine this rule’s exceptions, tags, or severity to better align with your environment while preserving coverage for truly risky events.
118
119### Additional information
120
121- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
122- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
123- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
124"""
125references = [
126    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html",
127    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSnapshot.html",
128]
129risk_score = 47
130rule_id = "b36c99af-b944-4509-a523-7e0fad275be1"
131severity = "medium"
132tags = [
133    "Domain: Cloud",
134    "Data Source: AWS",
135    "Data Source: Amazon Web Services",
136    "Data Source: AWS RDS",
137    "Use Case: Asset Visibility",
138    "Tactic: Impact",
139    "Resources: Investigation Guide",
140]
141timestamp_override = "event.ingested"
142type = "eql"
143
144query = '''
145any where event.dataset == "aws.cloudtrail"
146    and event.provider == "rds.amazonaws.com"
147    and event.outcome == "success"
148    and (
149        event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or
150        (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
151    )
152    and not (
153        user_agent.original == "backup.amazonaws.com" 
154        and source.address == "backup.amazonaws.com"
155    )
156'''
157
158
159[[rule.threat]]
160framework = "MITRE ATT&CK"
161[[rule.threat.technique]]
162id = "T1485"
163name = "Data Destruction"
164reference = "https://attack.mitre.org/techniques/T1485/"
165
166
167[rule.threat.tactic]
168id = "TA0040"
169name = "Impact"
170reference = "https://attack.mitre.org/tactics/TA0040/"
171
172[rule.investigation_fields]
173field_names = [
174    "@timestamp",
175    "user.name",
176    "user_agent.original",
177    "source.ip",
178    "aws.cloudtrail.user_identity.arn",
179    "aws.cloudtrail.user_identity.type",
180    "aws.cloudtrail.user_identity.access_key_id",
181    "event.action",
182    "event.outcome",
183    "cloud.account.id",
184    "cloud.region",
185    "aws.cloudtrail.request_parameters",
186    "aws.cloudtrail.response_elements",
187]