AWS RDS DB Instance Restored
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/06/29"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Austin Songer", "Elastic"]
9description = """
10An 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.
11"""
12false_positives = [
13 """
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.
17 """,
18]
19index = ["filebeat-*", "logs-aws.cloudtrail-*"]
20language = "eql"
21license = "Elastic License v2"
22name = "AWS RDS DB Instance Restored"
23references = [
24 "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
25 "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
26 "https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py",
27 "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance",
28]
29risk_score = 47
30rule_id = "bf1073bf-ce26-4607-b405-ba1ed8e9e204"
31severity = "medium"
32tags = [
33 "Domain: Cloud",
34 "Data Source: AWS",
35 "Data Source: Amazon Web Services",
36 "Data Source: AWS RDS",
37 "Use Case: Asset Visibility",
38 "Tactic: Defense Evasion",
39 "Resources: Investigation Guide",
40]
41timestamp_override = "event.ingested"
42type = "eql"
43
44query = '''
45any where event.dataset == "aws.cloudtrail"
46 and event.provider == "rds.amazonaws.com"
47 and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
48 and event.outcome == "success"
49'''
50note = """## 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
57Amazon 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
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."""
85
86[[rule.threat]]
87framework = "MITRE ATT&CK"
88[[rule.threat.technique]]
89id = "T1578"
90name = "Modify Cloud Compute Infrastructure"
91reference = "https://attack.mitre.org/techniques/T1578/"
92[[rule.threat.technique.subtechnique]]
93id = "T1578.002"
94name = "Create Cloud Instance"
95reference = "https://attack.mitre.org/techniques/T1578/002/"
96[[rule.threat.technique.subtechnique]]
97id = "T1578.004"
98name = "Revert Cloud Instance"
99reference = "https://attack.mitre.org/techniques/T1578/004/"
100
101
102[rule.threat.tactic]
103id = "TA0005"
104name = "Defense Evasion"
105reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating AWS RDS 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
orRestoreDBInstanceFromS3
API call by examining theuser.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.
References
Related rules
- AWS Deletion of RDS Instance or Cluster
- AWS RDS Cluster Creation
- AWS RDS DB Instance Made Public
- AWS RDS DB Instance or Cluster Password Modified
- AWS RDS Instance Creation