Pillage Exposed RDS Instances

What this lab covers

You discover a database service reachable from the internet, establish credentials for it, and read what it holds, using ordinary network tooling rather than anything cloud-specific.

The point is how mundane the path is. There is no exploit, no misconfigured policy and no privilege escalation, just a service that should not have been reachable and a password that was not strong enough.

It assumes no prior AWS or database experience and is a useful reminder that classic network security problems did not disappear when infrastructure moved.

How exposed databases are found

RDS instances have a publicly accessible setting that determines whether they receive a public endpoint. Combined with a security group permitting inbound traffic, that places the database service on the internet at a resolvable hostname.

Discovery is not targeted. The entire internet is scanned continuously by researchers, services and attackers, and databases on standard ports are identified within hours of appearing. Nobody needs to be looking for you specifically.

Once reachable, the attack is a credential attack. Databases frequently carry default or weak passwords, particularly where the instance was created for testing and then quietly kept, and many have no lockout, no multi-factor authentication and limited logging of failed attempts.

How to detect this in your own environment

Alert on the configuration change that creates the exposure. Modifying an instance to be publicly accessible is a control plane event, it is rare, and it is far more actionable than discovering the exposure later.

Enable database audit logging and watch for failed authentication volume, which is the signature of brute forcing and is frequently not collected at all on managed databases.

Scan your own external perimeter regularly. Knowing what of yours is reachable from the internet is a basic control that many organizations cannot actually perform on demand.

How to prevent it

Do not give databases public endpoints. Access should come from within the network, over a private connection or through a bastion, and the publicly accessible setting should be disabled by policy rather than by convention.

Use IAM database authentication where supported, which removes the static password entirely and ties access to cloud identity with short-lived credentials.

Restrict security groups to specific sources rather than broad ranges, and use organization policies or preventive guardrails so a publicly accessible database cannot be created accidentally in the first place.

Real-world context

Exposed databases have been behind a long series of disclosed breaches, and internet-wide scanning services routinely publish counts of publicly reachable database instances across every provider, consistently in the tens of thousands.

The common thread is lifecycle rather than ignorance. Instances created for a migration, a test or a demonstration are made reachable for convenience and then persist, with the exposure surviving long after the reason for it.

The pattern maps to MITRE ATT&CK T1595 Active Scanning, T1110 Brute Force and T1078 Valid Accounts.

Applying this at work

• List every database instance in your accounts with public accessibility enabled, in every region.
• Add a preventive guardrail so publicly accessible databases cannot be created without an explicit exception.
• Enable database audit logging and alert on failed authentication volume.
• Move to IAM database authentication where supported, removing static passwords.
• Run an external scan of your own perimeter and compare the result against what you expected to find.

Frequently asked questions

Are RDS databases private by default?

The publicly accessible setting controls whether an instance receives a public endpoint. When enabled, combined with a permissive security group, the database is reachable from the internet at a resolvable hostname.

How quickly is an exposed database found?

Typically within hours. The internet is scanned continuously by multiple parties, and services on standard database ports are identified automatically. Discovery does not require anyone to be targeting your organization.

What is the strongest control here?

Not giving databases public endpoints at all, enforced by a preventive guardrail rather than convention. Where cloud identity authentication is supported, it also removes the static password that brute forcing targets.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.