AWS RDS DB Instance Made Public

This detection identifies the creation or modification of an Amazon RDS DB instance or cluster with the publiclyAccessible attribute set to true. While legitimate use cases exist, unexpected public exposure of a database to the internet introduces significant security risks. An adversary with access to AWS credentials might modify a DB instance's public accessibility to exfiltrate data, establish persistence, or bypass internal network restrictions. The rule focuses on ModifyDBInstance, CreateDBInstance, and CreateDBCluster events within AWS CloudTrail logs. Defenders should investigate any unexpected changes to RDS instance accessibility. This activity can indicate compromised credentials or insider threats, and might be correlated with other IAM and network configuration changes to assess the overall impact.

Attack Chain

1. An attacker gains unauthorized access to AWS credentials (e.g., via phishing or credential stuffing).
2. The attacker uses the compromised credentials to authenticate to the AWS Management Console or via the AWS CLI/API.
3. The attacker identifies a target RDS DB instance or cluster.
4. The attacker executes a ModifyDBInstance API call, setting the PubliclyAccessible parameter to true in the request_parameters.
5. Alternatively, the attacker executes a CreateDBInstance or CreateDBCluster API call with the PubliclyAccessible parameter set to true.
6. The attacker modifies associated security groups using AuthorizeSecurityGroupIngress to allow inbound traffic from 0.0.0.0/0 or other broad IP ranges.
7. The now publicly accessible RDS instance is used to exfiltrate data or as a pivot point to attack other internal resources.
8. The attacker leverages the publicly exposed database for persistent access and further reconnaissance.

Impact

If an attacker successfully makes an RDS DB instance publicly accessible, they can potentially exfiltrate sensitive data, pivot to other internal resources, or establish persistent access to the environment. The number of affected instances depends on the scope of the credential compromise. Sectors that heavily rely on cloud infrastructure, such as finance, healthcare, and technology, are at higher risk. The impact can range from data breaches and compliance violations to significant financial losses and reputational damage.

Recommendation

• Deploy the Sigma rule "AWS RDS DB Instance Made Public" to your SIEM using filebeat-* and logs-aws.cloudtrail-* indices to detect modifications to RDS instance accessibility.
• Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.type in the SIEM to identify the IAM principal that made the change and validate its legitimacy.
• Monitor for AuthorizeSecurityGroupIngress events in CloudTrail logs that allow inbound traffic from 0.0.0.0/0 to associated security groups of RDS instances.
• Implement AWS Config rules (e.g., rds-instance-public-access-check) to automatically detect and remediate publicly accessible RDS instances.
• Enforce Service Control Policies (SCPs) to prevent the creation of publicly accessible RDS instances.
• Refer to the provided AWS IR Playbooks and AWS Customer Playbook Framework documentation for incident response guidance.