Hunt for Secrets in Git Repos

What this lab covers

You search a repository for credentials the way an attacker would, using the same scanning tools that appear in real engagements, and then turn the finding into access against a live cloud environment.

The lab covers both directions. You find the secret, understand why scanning the working tree alone would have missed it, and then work through what the engineering team should have done to prevent and detect it.

It assumes no prior AWS experience and suits developers, platform engineers and security practitioners equally. If you have ever wondered whether your own repositories are clean, this is the practical version of that question.

How credential leaks in git actually happen

Almost nobody commits a secret deliberately. It arrives in a config file used for local testing, a terraform state file, a notebook, a CI script, or a hardcoded fallback added during an outage and never removed. The commit passes review because reviewers read the diff for logic, not for entropy.

The critical property is persistence. Git is content-addressable and append-only in practice, so removing a secret in a later commit leaves the original blob intact and reachable. A repository can look clean at HEAD while every historical version remains available to anyone who clones it.

Scanners take two approaches, and both matter. Pattern matching catches credentials with recognizable formats, such as cloud access key identifiers. Entropy analysis catches high-randomness strings that match no known pattern, which is how generic API tokens and passwords are found. Tools like TruffleHog combine both and walk the full commit history rather than the checked-out tree.

How to detect this in your own environment

Scan history, not just the working copy. A scan of the current checkout will report a repository as clean when a live credential sits three commits back. Run the scanner across all branches and the full commit graph, including branches that were merged and deleted.

For AWS specifically, the strongest detection is not in the repository at all. It is in the account. Watch for a first-time use of an access key from an unfamiliar network, and for keys belonging to human users being used programmatically. If a key leaks publicly, automated scrapers typically use it within minutes, so the account-side signal usually arrives faster than any repository audit.

Plant a canary. A deliberately fake AWS key committed to a repository, wired to alert on any use, tells you immediately that someone is scanning or has cloned your code. It costs nothing and produces zero false positives.

How to prevent it

Prevention belongs at commit time, because everything after that is cleanup. Pre-commit hooks and server-side push protection reject the commit before the secret ever enters history, which is the only intervention that avoids rotation entirely.

Remove the need for the secret. Most committed credentials exist because a developer needed local access to a cloud resource. Short-lived credentials from an identity provider, or per-developer roles, take the long-lived key out of circulation so there is nothing durable to leak.

Assume any committed secret is already compromised and rotate it first. Rewriting history is worth doing, but it is slow, it breaks forks and clones, and it does nothing about the copy an attacker may already hold. Rotate, then clean up, in that order.

Real-world context

The 2016 Uber breach is the clearest case. Attackers used credentials to reach a private source code repository, found an AWS access key in it, and used that to copy data on approximately 57 million riders and drivers, according to the US Federal Trade Commission's enforcement action. The company later paid a 148 million dollar settlement, and its former security chief was convicted in 2022 of obstruction relating to the handling of the incident.

A more recent example shows how long exposure can persist. In October 2022 Toyota disclosed that source code containing a data server access key had been public on GitHub from December 2017 until September 2022, potentially exposing email addresses and customer management numbers for 296,019 T-Connect users. Nobody noticed until an external report arrived.

The technique maps to MITRE ATT&CK T1552.001 Credentials In Files and T1078 Valid Accounts. It remains a common initial access route because it requires no exploit, though it sits alongside exploitation of internet-facing applications, which is now an equally significant way into cloud environments.

Applying this at work

• Run a history-aware secret scan across every repository your organization owns, including archived ones. Archived repositories are still clonable.
• Enable push protection or a pre-commit hook so new secrets are blocked rather than found later.
• Build a rotation runbook before you need it. The slow part of a leaked credential is usually deciding who is allowed to rotate it.
• Replace long-lived developer access keys with short-lived credentials from your identity provider.
• Commit a canary token to a couple of internal repositories and alert on any use.

Frequently asked questions

Does deleting a secret from a file remove it from git?

No. The previous commit still contains it and remains readable to anyone with a clone of the repository. Only rewriting history removes the object, and even then, existing clones and forks are unaffected. Rotating the credential is the only reliable remediation.

What is the difference between TruffleHog and git-secrets?

git-secrets matches known credential patterns and is typically used as a pre-commit hook to block them. TruffleHog scans full commit history and combines pattern matching with entropy analysis, so it also finds high-randomness secrets that match no known format.

How quickly are leaked AWS keys abused?

Publicly exposed keys are commonly used within minutes, because automated scrapers monitor public repositories continuously. Treat any public exposure as an active incident rather than a theoretical risk.

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 credential discovery and AWS attack paths in full, and is assessed hands-on in a live AWS account.