You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#### 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
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.
10
+
Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to
11
+
valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate
12
+
sensitive data from a duplicated environment. This rule detects successful restoration operations using
13
+
"RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or
14
+
post-compromise defense evasion.
11
15
"""
16
+
event_category_override = "event.type"
12
17
false_positives = [
13
18
"""
14
-
Restoring DB instances may be done by a system or network administrator. Verify whether the user identity, user agent,
15
-
and/or hostname should be making changes in your environment. Instance restoration by unfamiliar users or hosts
16
-
should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
19
+
Restoring an RDS DB instance may be performed legitimately during troubleshooting, development refresh processes,
20
+
migrations, or disaster-recovery drills. Validate the user identity, source IP, automation context, and whether the
21
+
restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. Expected
22
+
behavior can be exempted through rule exceptions.
17
23
""",
18
24
]
19
25
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
20
26
language = "eql"
21
27
license = "Elastic License v2"
22
28
name = "AWS RDS DB Instance Restored"
29
+
note = """## Triage and analysis
30
+
31
+
> **Disclaimer**:
32
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance.
33
+
> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
34
+
35
+
### Investigating AWS RDS DB Instance Restored
36
+
37
+
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.
38
+
39
+
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.
40
+
41
+
#### Possible investigation steps
42
+
43
+
- **Identify the actor and execution context**
44
+
- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.
45
+
- Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK).
46
+
47
+
- **Understand what was restored and why**
48
+
- Inspect `aws.cloudtrail.request_parameters` to identify:
49
+
- Snapshot identifier or S3 location used as the restore source.
50
+
- The new DB instance identifier and configuration parameters.
51
+
- Determine:
52
+
- Whether the snapshot/backup used for the restore contains sensitive or high-value data.
53
+
- Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes.
54
+
55
+
- **Reconstruct the activity flow**
56
+
- Use `@timestamp` to correlate the restore event with:
57
+
- Snapshot creation, copy, or export events.
58
+
- IAM policy changes or privilege escalations.
59
+
- Deletion or modification of the original database.
60
+
- Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes.
- Recent logins from unusual IPs or federated sessions without MFA.
64
+
65
+
- **Correlate with broader behavior**
66
+
- Pivot in CloudTrail on:
67
+
- The same snapshot identifier.
68
+
- The same actor or access key ID.
69
+
- The newly created DB instance identifier.
70
+
- Examine:
71
+
- Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled).
72
+
- Whether there were large-volume read operations or export actions following the restore.
73
+
- Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions).
74
+
75
+
- **Validate intent with owners**
76
+
- Confirm with the application/database/platform teams:
77
+
- Whether the restore was requested or part of an authorized operational workflow.
78
+
- Whether this restore corresponds to migration, testing, DR drill, or another planned activity.
79
+
- Whether the restored environment should exist (and for how long).
80
+
81
+
### False positive analysis
82
+
83
+
- **Legitimate maintenance and DR workflows**
84
+
- Many teams restore databases for patch testing, DR validation, schema testing, or migration.
85
+
- **Automated restore workflows**
86
+
- CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments.
87
+
- **Third-party tooling**
88
+
- 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.
89
+
90
+
### Response and remediation
91
+
92
+
- **Contain the restored environment**
93
+
- If unauthorized:
94
+
- Apply restrictive security groups to block access.
95
+
- Disable public accessibility if enabled.
96
+
- Evaluate whether deletion protection or backup retention is misconfigured.
97
+
98
+
- **Assess data exposure and intent**
99
+
- Work with data owners to evaluate:
100
+
- The sensitivity of the restored environment.
101
+
- Whether any reads, dumps, or exports occurred post-restore.
102
+
- Whether the restore enabled the attacker to access older or deleted data.
103
+
104
+
- **Investigate scope and related activity**
105
+
- Review CloudTrail for:
106
+
- Additional restores, exports, or copies.
107
+
- IAM changes allowing expanded privileges.
108
+
- Unusual authentication events or federated sessions without MFA.
109
+
- Related destructive actions (snapshot deletion, backup disabled, instance deletion).
110
+
111
+
- **Hardening and preventive controls**
112
+
- Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`.
113
+
- Use IAM conditions to restrict restore actions by network, principal, or region.
114
+
- Add AWS Config and Security Hub controls for monitoring:
115
+
- Unapproved restores.
116
+
- Public or misconfigured restored instances.
117
+
- Consider SCPs that prevent RDS restores in production accounts except through controlled roles.
118
+
119
+
- **Post-incident improvements**
120
+
- Rotate credentials for affected IAM users/roles.
121
+
- Update change management processes to ensure restore actions are tracked and approved.
122
+
- Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts.
123
+
124
+
### Additional information
125
+
126
+
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
48
155
and event.outcome == "success"
49
156
'''
50
-
note = """## Triage and analysis
51
-
52
-
> **Disclaimer**:
53
-
> 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.
54
-
55
-
### Investigating AWS RDS DB Instance Restored
56
-
57
-
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.
58
-
59
-
### Possible investigation steps
60
157
61
-
- 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.
62
-
- 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.
63
-
- 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.
64
-
- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact.
65
-
- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame.
66
-
- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended.
67
-
68
-
### False positive analysis
69
-
70
-
- 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.
71
-
- 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.
72
-
- 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.
73
-
- 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.
74
-
- 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.
75
-
76
-
### Response and remediation
77
-
78
-
- 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.
79
-
- 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.
80
-
- 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.
81
-
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure.
82
-
- 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.
83
-
- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly.
84
-
- 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."""
0 commit comments