AWS RDS DB Instance Restored

  1[metadata]
  2creation_date = "2021/06/29"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/12/01"
  6
  7[rule]
  8author = ["Austin Songer", "Elastic"]
  9description = """
 10Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to
 11valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate
 12sensitive data from a duplicated environment. This rule detects successful restoration operations using
 13"RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or
 14post-compromise defense evasion.
 15"""
 16false_positives = [
 17    """
 18    Restoring an RDS DB instance may be performed legitimately during troubleshooting, development refresh processes,
 19    migrations, or disaster-recovery drills. Validate the user identity, source IP, automation context, and whether the
 20    restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. Expected
 21    behavior can be exempted through rule exceptions.
 22    """,
 23]
 24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "AWS RDS DB Instance Restored"
 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 DB Instance Restored
 35
 36Restoring 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. 
 37
 38This 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.
 39
 40#### Possible investigation steps
 41
 42- **Identify the actor and execution context**
 43  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.
 44  - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK).
 45
 46- **Understand what was restored and why**
 47  - Inspect `aws.cloudtrail.request_parameters` to identify:
 48    - Snapshot identifier or S3 location used as the restore source.
 49    - The new DB instance identifier and configuration parameters.
 50  - Determine:
 51    - Whether the snapshot/backup used for the restore contains sensitive or high-value data.
 52    - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes.
 53
 54- **Reconstruct the activity flow**
 55  - Use `@timestamp` to correlate the restore event with:
 56    - Snapshot creation, copy, or export events.
 57    - IAM policy changes or privilege escalations.
 58    - Deletion or modification of the original database.
 59    - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes.
 60  - Look for signs of attacker staging:
 61    - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`).
 62    - Recent logins from unusual IPs or federated sessions without MFA.
 63
 64- **Correlate with broader behavior**
 65  - Pivot in CloudTrail on:
 66    - The same snapshot identifier.
 67    - The same actor or access key ID.
 68    - The newly created DB instance identifier.
 69  - Examine:
 70    - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled).
 71    - Whether there were large-volume read operations or export actions following the restore.
 72    - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions).
 73
 74- **Validate intent with owners**
 75  - Confirm with the application/database/platform teams:
 76    - Whether the restore was requested or part of an authorized operational workflow.
 77    - Whether this restore corresponds to migration, testing, DR drill, or another planned activity.
 78    - Whether the restored environment should exist (and for how long).
 79
 80### False positive analysis
 81
 82- **Legitimate maintenance and DR workflows**
 83  - Many teams restore databases for patch testing, DR validation, schema testing, or migration.
 84- **Automated restore workflows**
 85  - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments.
 86- **Third-party tooling**
 87  - 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.
 88
 89### Response and remediation
 90
 91- **Contain the restored environment**
 92  - If unauthorized:
 93    - Apply restrictive security groups to block access.
 94    - Disable public accessibility if enabled.
 95    - Evaluate whether deletion protection or backup retention is misconfigured.
 96
 97- **Assess data exposure and intent**
 98  - Work with data owners to evaluate:
 99    - The sensitivity of the restored environment.
100    - Whether any reads, dumps, or exports occurred post-restore.
101    - Whether the restore enabled the attacker to access older or deleted data.
102
103- **Investigate scope and related activity**
104  - Review CloudTrail for:
105    - Additional restores, exports, or copies.
106    - IAM changes allowing expanded privileges.
107    - Unusual authentication events or federated sessions without MFA.
108    - Related destructive actions (snapshot deletion, backup disabled, instance deletion).
109
110- **Hardening and preventive controls**
111  - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`.
112  - Use IAM conditions to restrict restore actions by network, principal, or region.
113  - Add AWS Config and Security Hub controls for monitoring:
114    - Unapproved restores.
115    - Public or misconfigured restored instances.
116  - Consider SCPs that prevent RDS restores in production accounts except through controlled roles.
117
118- **Post-incident improvements**
119  - Rotate credentials for affected IAM users/roles.
120  - Update change management processes to ensure restore actions are tracked and approved.
121  - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts.
122
123### Additional information
124
125- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
126- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
127- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
128"""
129references = [
130    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
131    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
132    "https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py",
133    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance",
134]
135risk_score = 47
136rule_id = "bf1073bf-ce26-4607-b405-ba1ed8e9e204"
137severity = "medium"
138tags = [
139    "Domain: Cloud",
140    "Data Source: AWS",
141    "Data Source: Amazon Web Services",
142    "Data Source: AWS RDS",
143    "Use Case: Asset Visibility",
144    "Tactic: Defense Evasion",
145    "Resources: Investigation Guide",
146]
147timestamp_override = "event.ingested"
148type = "query"
149
150query = '''
151event.dataset: "aws.cloudtrail"
152    and event.provider: "rds.amazonaws.com"
153    and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3")
154    and event.outcome: "success"
155'''
156
157
158[[rule.threat]]
159framework = "MITRE ATT&CK"
160[[rule.threat.technique]]
161id = "T1578"
162name = "Modify Cloud Compute Infrastructure"
163reference = "https://attack.mitre.org/techniques/T1578/"
164[[rule.threat.technique.subtechnique]]
165id = "T1578.002"
166name = "Create Cloud Instance"
167reference = "https://attack.mitre.org/techniques/T1578/002/"
168
169[[rule.threat.technique.subtechnique]]
170id = "T1578.004"
171name = "Revert Cloud Instance"
172reference = "https://attack.mitre.org/techniques/T1578/004/"
173
174
175
176[rule.threat.tactic]
177id = "TA0005"
178name = "Defense Evasion"
179reference = "https://attack.mitre.org/tactics/TA0005/"
180
181[rule.investigation_fields]
182field_names = [
183    "@timestamp",
184    "user.name",
185    "user_agent.original",
186    "source.ip",
187    "aws.cloudtrail.user_identity.arn",
188    "aws.cloudtrail.user_identity.type",
189    "aws.cloudtrail.user_identity.access_key_id",
190    "target.entity.id",
191    "event.action",
192    "event.outcome",
193    "cloud.account.id",
194    "cloud.region",
195    "aws.cloudtrail.request_parameters",
196    "aws.cloudtrail.response_elements",
197]