Prerequisites
- Target system, dependencies and environment configured.
Usage
Purpose
Developers commit secrets. Then they force-push a fix and think it's gone — but git keeps history, and public mirrors keep copies. This skill covers finding an org's leaked credentials and infra details across public repos, so you find them before someone hostile does.
When to use it
External recon on an org that ships code publicly, or a self-audit of your own GitHub presence. High signal, because a live cloud key in a repo is often a straight line to production.
Search only public data, and never use a credential you find during unauthorised recon — finding it is recon, using it is intrusion. Report it.
Procedure
- List the org's public repos, and don't stop at the main org — check personal accounts of known employees and forks, where leaks hide:
gh repo list <org> --limit 200 --json name,url
- Scan a repo's full history, not just the current tree. The secret is usually in an old commit that a later commit "removed":
trufflehog github --repo=https://github.com/org/repo
- Run a second scanner over a local clone — different tools catch different patterns:
git clone --mirror https://github.com/org/repo repo.git
gitleaks detect --source repo.git
- Beyond credentials, read for infrastructure leaks: internal hostnames, S3 bucket names, CI config,
.env.example files that reveal the shape of the real .env.
- Verify a hit is real and live before you raise it — scanners flag test/placeholder values too. Confirm the format, and if it's your own authorised audit, check whether the key still authenticates.
Cheatsheet
trufflehog github --org=<org> --only-verified
trufflehog github --repo=https://github.com/org/repo
git clone --mirror <url> r.git && gitleaks detect --source r.git -v
gh api -X GET search/code -f q="org:<org> password"
--only-verified in trufflehog actively checks whether a found key still works — huge for cutting false positives, but it does make a request with the credential, so only use it on your own authorised audit.
Reading the output
- A verified live key (AWS, Stripe, a signing secret) is critical — treat it as an active exposure, not a hypothetical.
- A hit in old history but not the current file is still a real leak; the credential must be rotated, deleting the commit isn't enough.
- Placeholder-looking values (
AKIAEXAMPLE, changeme) are usually noise — confirm before reporting.
- Internal hostnames and bucket names aren't secrets but widen the attack surface for other domains here.
The fix (for your own leaks)
Rotate first, always — the secret is compromised the moment it's public, and history rewriting doesn't un-leak it. Then purge it from history (git filter-repo or BFG) and force-push. Prevent the next one with a pre-commit secret scanner and a server-side push protection rule, plus a .gitignore that actually covers .env and key files. Move real secrets into a secret manager, not the repo.
Pitfalls
- Scanning current tree only. Misses the majority of leaks, which live in history.
- Ignoring employee personal repos. A lot of leaks are in someone's side project, not the org account.
- Treating history deletion as remediation. Rotate the credential — mirrors and forks already have the old commit.
- Alert fatigue. Without verification you drown in test values. Verify, then prioritise the live ones.
References
- OWASP WSTG-INFO — Review Webpage Content / source for leaks
- trufflehog and gitleaks documentation
- GitHub docs — Secret scanning and push protection
Inputs
- Relevant source code, logs, network traces, or system specifications.
Outputs
- Analysis findings, security audit report, or generated code artifacts.
1---2name: github-secret-recon3description: Use when checking whether an organisation has leaked API keys, credentials, or internal infrastructure details in public git repositories.4---5678## Prerequisites9- Target system, dependencies and environment configured.1011## Usage12### Purpose1314Developers commit secrets. Then they force-push a fix and think it's gone — but git keeps history, and public mirrors keep copies. This skill covers finding an org's leaked credentials and infra details across public repos, so you find them before someone hostile does.1516### When to use it1718External recon on an org that ships code publicly, or a self-audit of your own GitHub presence. High signal, because a live cloud key in a repo is often a straight line to production.1920Search only public data, and never *use* a credential you find during unauthorised recon — finding it is recon, using it is intrusion. Report it.2122### Procedure23241. List the org's public repos, and don't stop at the main org — check personal accounts of known employees and forks, where leaks hide:25 ```26 gh repo list <org> --limit 200 --json name,url27 ```282. Scan a repo's **full history**, not just the current tree. The secret is usually in an old commit that a later commit "removed":29 ```30 trufflehog github --repo=https://github.com/org/repo31 ```323. Run a second scanner over a local clone — different tools catch different patterns:33 ```34 git clone --mirror https://github.com/org/repo repo.git35 gitleaks detect --source repo.git36 ```374. Beyond credentials, read for infrastructure leaks: internal hostnames, S3 bucket names, CI config, `.env.example` files that reveal the shape of the real `.env`.385. Verify a hit is real and live before you raise it — scanners flag test/placeholder values too. Confirm the format, and if it's your own authorised audit, check whether the key still authenticates.3940### Cheatsheet4142```bash43trufflehog github --org=<org> --only-verified4445trufflehog github --repo=https://github.com/org/repo4647git clone --mirror <url> r.git && gitleaks detect --source r.git -v4849gh api -X GET search/code -f q="org:<org> password"50```5152`--only-verified` in trufflehog actively checks whether a found key still works — huge for cutting false positives, but it does make a request with the credential, so only use it on your own authorised audit.5354### Reading the output5556- A **verified live key** (AWS, Stripe, a signing secret) is critical — treat it as an active exposure, not a hypothetical.57- **A hit in old history but not the current file** is still a real leak; the credential must be rotated, deleting the commit isn't enough.58- **Placeholder-looking values** (`AKIAEXAMPLE`, `changeme`) are usually noise — confirm before reporting.59- **Internal hostnames and bucket names** aren't secrets but widen the attack surface for other domains here.6061### The fix (for your own leaks)6263Rotate first, always — the secret is compromised the moment it's public, and history rewriting doesn't un-leak it. Then purge it from history (`git filter-repo` or BFG) and force-push. Prevent the next one with a pre-commit secret scanner and a server-side push protection rule, plus a `.gitignore` that actually covers `.env` and key files. Move real secrets into a secret manager, not the repo.6465### Pitfalls6667- **Scanning current tree only.** Misses the majority of leaks, which live in history.68- **Ignoring employee personal repos.** A lot of leaks are in someone's side project, not the org account.69- **Treating history deletion as remediation.** Rotate the credential — mirrors and forks already have the old commit.70- **Alert fatigue.** Without verification you drown in test values. Verify, then prioritise the live ones.7172### References7374- OWASP WSTG-INFO — Review Webpage Content / source for leaks75- trufflehog and gitleaks documentation76- GitHub docs — Secret scanning and push protection7778## Inputs79- Relevant source code, logs, network traces, or system specifications.8081## Outputs82- Analysis findings, security audit report, or generated code artifacts.
jihedbfr-art