Amazon RDS - CraftedSignal Threat Feed

AWS RDS Snapshot Deletion Detected

hello@craftedsignal.io — Wed, 03 Jul 2024 12:00:00 +0000

This rule detects the deletion of AWS RDS DB snapshots or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting "backupRetentionPeriod=0" has a similar impact by preventing future restore points. A threat actor with sufficient AWS permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. The rule focuses on successful snapshot deletions and backup disabling events within AWS RDS. The scope includes any AWS environment utilizing RDS for database services.

Attack Chain

The attacker gains access to an AWS account with sufficient permissions to manage RDS instances and snapshots, possibly through compromised credentials or an IAM role with excessive privileges.
The attacker enumerates available RDS DB instances and snapshots within the target AWS account using AWS CLI or API calls (e.g., DescribeDBSnapshots, DescribeDBInstances).
The attacker identifies target DB instances and their associated snapshots that are critical for recovery or contain valuable forensic data.
The attacker deletes RDS DB snapshots using the DeleteDBSnapshot API call, effectively removing restore points.
Alternatively, the attacker modifies the DB instance configuration using the ModifyDBInstance API call, setting backupRetentionPeriod to 0 to disable automated backups and prevent future restore points.
The attacker may then delete the RDS instance itself using DeleteDBInstance.
The attacker attempts to cover their tracks by deleting relevant CloudTrail logs or disabling CloudTrail logging.
The attacker's objective is to prevent restoration to a known-good state and destroy forensic evidence of attacker actions, potentially as part of a ransomware attack or data exfiltration attempt.

Impact

Successful deletion of RDS snapshots or disabling of backups can lead to significant data loss and prolonged downtime, making recovery from security incidents or operational failures difficult or impossible. This can impact business continuity, data integrity, and regulatory compliance. The precise impact depends on the criticality of the affected databases and the availability of alternative backup mechanisms. If successful, this can result in total data loss for the organization.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious DeleteDBSnapshot, DeleteDBClusterSnapshot, or ModifyDBInstance events setting backupRetentionPeriod=0 in AWS CloudTrail logs.
Restrict IAM permissions for rds:DeleteDBSnapshot, rds:DeleteDBClusterSnapshot, and rds:ModifyDBInstance (especially backup and deletion-related parameters) to a small set of privileged roles, as described in the remediation steps.
Use AWS Config rules and/or Security Hub controls to detect instances with backupRetentionPeriod=0, as recommended in the hardening and preventive controls section.

AWS RDS DB Instance or Cluster Deleted

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The deletion of Amazon RDS DB instances, Aurora clusters, or global database clusters can lead to permanent data loss and major service disruption. This activity is often carried out by adversaries who have gained sufficient permissions within an AWS environment. The motivation behind such actions can range from impeding recovery efforts following a ransomware attack, destroying critical evidence to hinder forensic investigations, or directly inflicting operational impact on the targeted environment. Defenders should be aware that these actions are irreversible without backups, making swift detection and validation essential to mitigate potential damage.

Attack Chain

An adversary gains initial access to the AWS environment, potentially through compromised credentials or an IAM role with excessive permissions.
The attacker enumerates existing RDS DB instances, Aurora clusters, or global database clusters within the target AWS account to identify valuable targets.
The attacker modifies the deletionProtection setting on the target RDS resource to false to allow deletion.
The attacker may disable or modify backup configurations to prevent recovery options, such as setting backupRetentionPeriod to 0.
The attacker executes the DeleteDBInstance, DeleteDBCluster, or DeleteGlobalCluster API call to initiate the deletion process.
If configured, the attacker may attempt to delete any final snapshots created during the deletion process to further hinder recovery.
The targeted RDS resource is permanently deleted, resulting in data loss and potential service disruption.
The attacker may attempt to cover their tracks by deleting relevant CloudTrail logs or modifying IAM policies.

Impact

The deletion of RDS DB instances or clusters can lead to significant data loss, disrupting critical business operations. Depending on the size and importance of the deleted resources, organizations may face substantial financial losses, reputational damage, and regulatory penalties. If backups are unavailable or have also been compromised, data recovery may be impossible, leading to long-term business disruption. The impact can affect organizations of any size that rely on AWS RDS for data storage and retrieval.

Recommendation

Deploy the Sigma rule AWS RDS DB Instance or Cluster Deleted to your SIEM and tune for your environment to detect unauthorized RDS resource deletions.
Enable deletionProtection on all critical RDS instances and clusters to prevent accidental or malicious deletion.
Enforce MFA for IAM users with RDS privileges to reduce the risk of compromised credentials (reference the additional information links).
Monitor CloudTrail logs for changes to deletionProtection settings and backup retention policies.
Regularly review and audit IAM policies to ensure that users and roles have only the necessary permissions.
Implement a process for validating unexpected RDS resource deletions with the service owner or database administrator.
Enable Sysmon process-creation logging to correlate with CloudTrail logs in case CLI or SDK tools are used for deletion.

AWS RDS Master User Password Reset Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

This analytic detects the resetting of the master user password for an Amazon RDS DB instance. The detection leverages AWS CloudTrail logs ingested via Amazon Security Lake to identify events where the ModifyDBInstance or ModifyDBCluster API calls include a new masterUserPassword parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, which may contain sensitive information such as credit card numbers, PII, or protected health information. If the password reset is confirmed to be malicious, it could lead to data breaches, regulatory non-compliance, and significant reputational damage. This detection is based on version 8 of the Splunk Security Content analytic "ASL AWS Credential Access RDS Password reset" published on April 15, 2026.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials (T1110) or phishing (T1586.003).
The attacker leverages the AWS Management Console or AWS CLI to interact with the RDS service.
The attacker issues a ModifyDBInstance or ModifyDBCluster API call.
Within the ModifyDBInstance or ModifyDBCluster API call, the attacker includes the masterUserPassword parameter.
The RDS service processes the request and resets the master user password for the specified database instance or cluster.
The attacker uses the newly reset master user password to authenticate to the RDS database instance.
The attacker gains access to sensitive data stored within the RDS database.
The attacker exfiltrates or manipulates the data for malicious purposes.

Impact

A successful attack resulting in unauthorized password reset can lead to a complete compromise of the RDS database instance. This could result in data breaches with millions of records exposed, regulatory fines for non-compliance (e.g., GDPR, HIPAA), and severe reputational damage affecting customer trust and stock prices. Sectors heavily reliant on RDS databases, such as finance, healthcare, and e-commerce, are particularly vulnerable.

Recommendation

Deploy the Sigma rule AWS RDS Master User Password Reset to your SIEM and tune for your environment using AWS CloudTrail logs ingested via Amazon Security Lake.
Investigate any detected instances of ModifyDBInstance or ModifyDBCluster API calls containing the masterUserPassword parameter by pivoting to the originating IP address (src_endpoint.ip) and user agent (http_request.user_agent) from the Sigma rule.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with permissions to manage RDS instances, to mitigate compromised credential attacks (T1110).
Review and enforce the principle of least privilege for IAM roles, ensuring that users only have the necessary permissions to perform their job functions.
Monitor AWS CloudTrail logs for other suspicious API calls related to RDS, such as modifications to security groups or network ACLs.