Find the Leaked AWS Key: Why Redacting the File Is Not Remediation
The challenge
A team claims they cleaned a secret out of their public repo. Open the sources and correlate them: the current config file looks scrubbed, but commit history and an old backup tell a different story. Find the AWS access key id that is still exposed and submit it.
What you'll learn
- Recognise that redacting a file in a new commit does not remove the secret from history
- Use git log to find earlier revisions of a file
- View a file at a specific commit to recover a removed value
- Correlate a public paste backup with repo history
- Understand that rotation, not redaction, is the real remediation
Skills tested
Prerequisites
- Basic git concepts (commits, log, file revisions)
- Awareness of what an AWS access key id looks like
How it works
Version control is append-only by design: every change is a new commit layered on top of the old ones, and the old content is still reachable. That is why deleting a secret from a file and committing the deletion does almost nothing for security - the previous commit, with the secret in plaintext, is still in the history that anyone who clones the repo receives. Attackers and security scanners both know to look in history first.
Here the live config.yml shows REDACTED values and a comment claiming the secrets moved to environment variables in commit 4f1a. The git log exposes the cleanup and points back to the initial commit d33a5f1. Running git show d33a5f1:config.yml prints the original file, where the access key id AKIA5TQQ3NLEAKED1 is hardcoded in plaintext. A public Pastebin labelled 'prod env backup' independently confirms the same key id and is still indexed by search engines, so the leak exists in two places at once.
The OSINT board gives you each artifact as a card. The current file is a decoy - it is genuinely scrubbed. The answer only appears when you read the old revision and corroborate it with the paste, both showing AKIA5TQQ3NLEAKED1.
Common mistakes
- Trusting the current file. The live
config.ymlis redacted; the secret is in history, not the working tree. - Believing the 'moved to env vars' comment. The comment describes the latest commit, not what is still in older commits.
- Skipping git log. Without listing earlier commits you never find the initial revision that holds the key.
- Submitting the secret key instead of the access key id. The question asks for the
AKIA...access key id.
How to defend against it
The only safe response to a committed secret is to assume it is compromised and rotate it immediately - redacting the file does not help, because the old commit and any paste or mirror still hold the value. Treat exposure, not deletion, as the event that matters.
- Rotate and revoke the leaked key in AWS IAM the moment it is found.
- Purge the secret from history (filter-repo / BFG) and force-push, but rotate first - history rewrites do not reach clones, forks, or pastes.
- Add a pre-commit secret scanner and CI scanning so keys never get committed.
- Use short-lived credentials or a secrets manager instead of hardcoding keys.