Shattering the Rotation Illusion: Part 5 - The Internet Archive Breach & An RDS Bonus

This is the fifth installment in our blog series, where we challenge the conventional wisdom of secret rotation and expose how attackers exploit leaked credentials. If you’re new here, we recommend starting with our Prelude, which lays out our motivations and the broader implications of secret mismanagement.

So far, we’ve demonstrated how secrets exposed on GitHub and GitLab are exploited within minutes, highlighted the risks of Package Managers like npm and Docker Hub, uncovered the dangers in Code Sharing Platforms such as GitHub Gist and Pastebin, and explored the potential for accidental leaks in developer forums like Stack Overflow and Reddit. Each post in this series reveals real-world experiments that show the speed and scale at which attackers operate—and the systemic gaps in traditional defensive strategies.

Today, we turn to two unique scenarios: replicating the Internet Archive breach and testing the security of RDS credentials.

Does Lightning Strike Twice? Reenacting The Internet Archive Breach

Following the recent publicized breach of the Internet Archive, where a.gitfolder was publicly accessible and contained secrets, we wanted to replicate the scenario to demonstrate that this isn’t an isolated incident. Allowing this to happen should be avoided at all costs; if you have a web server with exposed credentials, it’s a ticking time bomb.

As expected, our secrets were discovered and exploited within 3 days of making the .git folder accessible.

RDS: Unlikely Scenario, Alarming Results

One of AWS’s widely used services is RDS (Relational Database Service), which provides managed database instances for popular databases like PostgreSQL. RDS credentials essentially function as standard PostgreSQL credentials, including a server instance name, username, and password. Unlike AWS access keys, which can be easily recognized by attackers using prefix patterns, RDS credentials are harder to identify since successful authentication requires knowing all three elements—server name, username, and password. This makes direct detection more challenging, so we were curious to see what would happen if we "accidentally" leaked RDS credentials.

Scenarios

Our experiment involved three scenarios:

The Experiment Unfolds

To start, we set up a public RDS instance. While preparing the environment, we were caught off guard when, within 30 minutes of making the instance public—and without disclosing the instance name—our logs showed incoming access attempts. This revealed that attackers aren’t just looking for exposed credentials; they are actively scanning for publicly accessible RDS instances to potentially brute-force.

Once we overcame the initial surprise, we proceeded with the planned scenarios. The outcomes were alarming.

Results

Within just 5 minutes of placing our RDS credentials in an .env file (a scenario we dubbed Postgres .envy), attackers used them to log into the instance and begin siphoning data—5 minutes. This wasn’t the regular case of easily recognizable AWS access keys, these were plain credentials without any telltale prefix aside from the RDS instance name vaguely giving some indication.

Another scenario (RDSaster Waiting to Happen), took 16 minutes for an attacker to find and use the credentials to connect to RDS.

Interestingly, in the Terraform state file scenario (State Secrets), our RDS credentials remained untouched, suggesting that attackers may selectively focus on certain file types or credential types based on expected patterns. This contrasts with our AWS access key tests, where Terraform files were frequently exploited.

What’s Next

The results of this blog series are unequivocally clear: traditional approaches to secret management fail to protect against the speed and intent of modern attackers. The Internet Archive and RDS scenarios only reinforce the urgent need for enterprises to embrace proactive strategies, such as ephemeral secrets and Zero Trust architectures.

In our next post, we’ll take you behind enemy lines, sharing insights into the attackers’ perspective—how they operate, what they exploit, and why. As a small contribution to the community, we’ll also unveil AWSKeyLockdown, an open-source tool designed to mitigate these risks. If this effort prevents even one breach or keeps a single threat actor at bay, we’ve done our part to make the cyber ecosystem a little more secure.

If you can’t wait for the next blog post, we invite you to download the full report. It contains all scenarios, setup details, insights, adversary perspective, and the tool we built to neutralize exposed secrets instantly.