RDS Database Enumeration
RDS hosts managed relational databases on AWS. During enumeration, identify which instances exist, whether they are reachable, and where credentials are stored. Start with instance listing to understand network exposure. Then check snapshots, subnet placement, and parameter groups.
List DB Instances
Key fields: PubliclyAccessible and Endpoint.Address. A publicly accessible instance with a security group open to 0.0.0.0/0 is directly reachable from the internet. Check the Status column: available means the instance is running. Note the engine and version. Older engine versions may have known CVEs worth noting for vulnerability discovery. The endpoint address is the hostname for direct connection. If PubliclyAccessible is false, the instance sits inside a VPC. Reaching it requires network access via a bastion, VPN, or a compromised EC2 instance in the same subnet. Instances with Encrypted: false indicate storage encryption is off. That matters if you later access snapshots or backups.
Snapshots
Snapshots are point-in-time copies of the database. They can be shared across AWS accounts, including publicly. A public snapshot is a direct path to a full database copy without needing credentials to the live instance. List manual and automated snapshots:
Public RDS snapshots can be restored by any AWS account. They frequently contain full database dumps with credentials and application data. To exploit a public snapshot, restore it into an attacker-controlled account and connect directly. The restore takes a few minutes. The resulting instance has no credential barrier beyond AWS account access. This is a high-impact finding when the snapshot belongs to a production database.
Cluster Snapshots (Aurora)
Aurora uses a cluster-based architecture. Snapshots apply at the cluster level rather than per instance. The same public-sharing risk applies. Check for public cluster snapshots using the cluster-specific API call below.
DB Subnet Groups
The output reveals the VPC ID, subnet IDs, and availability zones for each RDS deployment. Use subnet IDs to cross-reference routing tables and network ACLs. A subnet that routes to an internet gateway may expose the database even if PubliclyAccessible is false. Check ACL rules to confirm the actual exposure. Subnet group membership reveals which EC2 instances share the same network segment. Those instances can reach the database without crossing a security group boundary.
Parameter Groups
Parameter groups store DB engine configuration. Some parameters expose attack surface. On MySQL, check for settings that allow outbound connections or enable UDF loading. Log-related parameters reveal whether query activity is captured, which affects OPSEC. Get the parameter group name from the describe-db-instances output and run this for each instance:
For MySQL/MariaDB, general_log and slow_query_log settings indicate whether query logging is active. log_output=FILE means logs go to the filesystem. If both are off, query activity on the database is not captured at the engine level. For PostgreSQL, check log_statement and log_connections. Also look at max_connections to understand usage patterns. A database near its connection limit is a potential denial-of-service condition worth noting.
Master Credentials Location
RDS master passwords are not stored in the RDS API. They are typically in:
Secrets Manager (
aws secretsmanager list-secrets)SSM Parameter Store (
aws ssm describe-parameters)Environment variables of the application (Lambda, ECS, EC2 user data)
Check all three. Secret names in Secrets Manager often follow a pattern like /rds/instance-name/password or include the instance identifier. In SSM, RDS credentials frequently appear as SecureString parameters. Application environment variables sometimes contain credentials in plaintext. This is common in older ECS task definitions and Lambda configurations that predate Secrets Manager adoption. See Secrets Manager and SSM Parameter Store Enumeration.
Security Group Check
Get the security group IDs from the describe-db-instances output. Run this for each group. Look for rules with IpRanges containing 0.0.0.0/0 or ::/0, which allow inbound access from anywhere. Also check for rules scoped to another security group. Those reveal which EC2 instances or services are permitted to connect.
Port 3306 (MySQL), 5432 (PostgreSQL), 1433 (MSSQL), 1521 (Oracle) open to 0.0.0.0/0 means direct internet access to the database. When you find an open port, attempt a connection with a database client to confirm reachability. Without credentials you cannot authenticate, but you confirm the path exists. Note the engine and port. Then pivot to Secrets Manager, SSM, and application environment variables before attempting any brute-force. A database exposed to the internet with a weak or default password is a critical finding.