---
title: AWS RDS DB Instance Restored
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...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/aws/defense_evasion_rds_instance_restored
---

# 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.
**Rule type**: eql
**Rule indices**:
- filebeat-*
- logs-aws.cloudtrail-*

**Rule Severity**: medium
**Risk Score**: 47
**Runs every**: 
**Searches indices from**: ``
**Maximum alerts per execution**: ?
**References**:
- [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
- [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
- [https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py](https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py)
- [https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance)

**Tags**:
- Domain: Cloud
- Data Source: AWS
- Data Source: Amazon Web Services
- Data Source: AWS RDS
- Use Case: Asset Visibility
- Tactic: Defense Evasion
- Resources: Investigation Guide

**Version**: ?
**Rule authors**:
- Austin Songer
- Elastic

**Rule license**: Elastic License v2

## Investigation guide


## 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 Query

```eql
any where event.dataset == "aws.cloudtrail"
    and event.provider == "rds.amazonaws.com"
    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
    and event.outcome == "success"
```

**Framework:** MITRE ATT&CK
- Tactic:  
  - Name: Defense Evasion
  - Id: TA0005
  - Reference URL: [https://attack.mitre.org/tactics/TA0005/](https://attack.mitre.org/tactics/TA0005/)
- Technique:  
  - Name: Modify Cloud Compute Infrastructure
  - Id: T1578
  - Reference URL: [https://attack.mitre.org/techniques/T1578/](https://attack.mitre.org/techniques/T1578/)
- Sub Technique:  
  - Name: Create Cloud Instance
  - Id: T1578.002
  - Reference URL: [https://attack.mitre.org/techniques/T1578/002/](https://attack.mitre.org/techniques/T1578/002/)
- Sub Technique:  
  - Name: Revert Cloud Instance
  - Id: T1578.004
  - Reference URL: [https://attack.mitre.org/techniques/T1578/004/](https://attack.mitre.org/techniques/T1578/004/)
