Plunder Public RDS Snapshots

What this lab covers

You locate a database snapshot that was shared more widely than intended, restore it into an environment you control, and query it directly to establish what it contains.

The uncomfortable part is how ordinary each step is. Restoring a snapshot is a documented operation and querying your own database is not an attack, so the entire technique consists of using AWS exactly as designed against data that should never have been shared.

It assumes no prior AWS or database experience beyond basic SQL, and is one of the clearest demonstrations of why a single sharing setting deserves as much attention as a firewall rule.

How public RDS snapshot exposure works

An RDS snapshot is a complete point-in-time copy of a database instance. Snapshots are taken automatically on a schedule and manually before changes, and they persist independently of the instance they came from, including after that instance is deleted.

Snapshots carry their own sharing attribute. They can be private, shared with named AWS accounts, or public, and public means restorable by any AWS account in the same region. Because they can be listed, discovery is systematic rather than opportunistic.

Once restored, the attacker owns the instance. Application-level access controls, query rate limits and audit logging all belonged to the original deployment and none of them apply to a fresh restore in someone else's account. The database is queried directly, completely and invisibly to the original owner.

How to detect this in your own environment

Alert on the sharing change, because that is the only reliable moment of visibility. Modifying snapshot attributes is a management event recorded in CloudTrail, and an alert on any snapshot being made public catches the mistake immediately rather than at the next audit.

Inventory continuously across all regions. Public snapshots in regions your organization does not actively use are a recurring finding, precisely because nobody looks there. This check is a scheduled query rather than a project.

Accept that use is largely undetectable. Once a snapshot is restored into another account, activity happens entirely outside your environment, so detection has to happen at the configuration stage rather than the exploitation stage.

How to prevent it

Audit and remove public sharing as a standing control rather than a one-off exercise, in every region. Automated remediation that flips a public snapshot back to private is well worth building, because the exposure window is what determines whether it is discovered.

Encrypt database instances. Encrypted snapshots cannot be shared publicly, which converts an encryption decision into a hard preventive control and removes the possibility of the mistake entirely.

Treat any snapshot sharing with an external account as time-bound and documented. Sharing arranged for a migration or a vendor investigation is rarely revoked once the work is finished.

Real-world context

Research published by Mitiga examined public RDS snapshots over a one month period in 2022 and found that of 2,783 snapshots observed, 810 were public for the entire window, with over 250 exposed for 30 days. That is a substantial number of complete databases exposed to anyone who looked.

The reason the numbers are high is that the setting is easy to reach and its consequence is not obvious from the interface. Making a snapshot public sounds like a sharing convenience rather than a decision to publish an entire production dataset.

The pattern maps to MITRE ATT&CK T1530 Data from Cloud Storage Object and T1580 Cloud Infrastructure Discovery.

Applying this at work

• Run a cross-region inventory of RDS snapshots with public sharing today, including regions you believe you do not use.
• Enable encryption on database instances, which prevents their snapshots from being shared publicly at all.
• Add a CloudTrail alert on snapshot attribute modification, and consider automated remediation to revert public sharing.
• Review snapshots shared with named external accounts and revoke those whose purpose has passed.
• Include snapshots in your data inventory. Many organizations classify databases carefully and never consider their copies.

Frequently asked questions

What happens when an RDS snapshot is public?

Any AWS account in the same region can restore it into their own environment and query the resulting database directly. They obtain the complete dataset, without your application's access controls or logging.

Can I detect someone restoring my public snapshot?

Not reliably. The restore and all subsequent queries happen in the other party's account. This is why detection must focus on the configuration change that made it public, not on the use.

Does encryption prevent public snapshot sharing?

Yes. Encrypted snapshots cannot be made public, which makes enabling encryption a hard preventive control against this specific exposure rather than only a data-at-rest measure.

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 data exposure and privilege escalation paths in full, and is assessed hands-on in a live AWS account.