GitHub code-leak discovery
When it applies
Recon of an organisation whose developers publish code. Public repos, gists, and — crucially — old
commits routinely leak API keys, cloud credentials, internal hostnames, and endpoints that open a
foothold no scanner of the live app would find.
Why it works
Secrets get committed and then "removed" in a later commit — but git keeps history, so the secret is
still reachable. Developers also mirror internal tooling, config, and infrastructure names into
public repos, handing you the attack surface and sometimes the keys to it.
Method
- Map the footprint: the org's repos, its members' personal repos, and gists (org members often
leak in personal projects). Note internal domains/usernames to grep for.
- Dork the code search: combine an org/domain term with secret indicators —
"company.com" password, api_key, AKIA, BEGIN RSA PRIVATE KEY, .env, config, authorization: bearer,
s3.amazonaws.com company. Search filenames too (filename:.env, filename:credentials).
- Scan history, not just HEAD: clone and run
trufflehog/gitleaks over the full history
(trufflehog git file://.), which finds secrets in deleted/old commits and validates live ones.
- Pivot on findings: internal endpoints/hosts → new recon targets; cloud keys → verify scope and
authorization before use (
cloud-*); JS/config → app internals.
- Handle responsibly: prove validity minimally (e.g.
sts get-caller-identity for AWS if in
scope), never exfiltrate data, and report leaked secrets for rotation.
Gotchas
- Stay in scope: employees' personal repos and unrelated orgs may be out of scope — confirm
before touching, and never use a live credential you aren't authorized to use.
- Many hits are dead/rotated keys — validate before reporting, but report even revoked ones as a
process finding when the program wants it.
- GitHub code search rate-limits and truncates — combine the web UI, the API, and offline history scans.
Verify success
You have leaked material tied to the target — a valid credential (verified minimally and in scope),
an internal endpoint/host, or config — that advances the engagement or is a reportable exposure.
References
truffleHog & gitleaks; GitHub code-search dork lists; the classic AWS-key-in-git incident write-ups.
1---2name: recon-github-code-leaks3description: Find secrets and internal detail an organisation leaked to public code — GitHub/GitLab repos, gists, and commit history. Load during recon of a named org, on "github dorks", "leaked secrets", "find API keys", or when employees/repos are in scope. Signals: a company GitHub org, developer usernames, an internal domain to grep for.4---56# GitHub code-leak discovery78## When it applies9Recon of an organisation whose developers publish code. Public repos, gists, and — crucially — old10commits routinely leak API keys, cloud credentials, internal hostnames, and endpoints that open a11foothold no scanner of the live app would find.1213## Why it works14Secrets get committed and then "removed" in a later commit — but git keeps history, so the secret is15still reachable. Developers also mirror internal tooling, config, and infrastructure names into16public repos, handing you the attack surface and sometimes the keys to it.1718## Method191. **Map the footprint**: the org's repos, its members' personal repos, and gists (org members often20 leak in personal projects). Note internal domains/usernames to grep for.212. **Dork the code search**: combine an org/domain term with secret indicators — `"company.com"22 password`, `api_key`, `AKIA`, `BEGIN RSA PRIVATE KEY`, `.env`, `config`, `authorization: bearer`,23 `s3.amazonaws.com company`. Search filenames too (`filename:.env`, `filename:credentials`).243. **Scan history, not just HEAD**: clone and run `trufflehog`/`gitleaks` over the full history25 (`trufflehog git file://.`), which finds secrets in deleted/old commits and validates live ones.264. **Pivot on findings**: internal endpoints/hosts → new recon targets; cloud keys → verify scope and27 authorization before use (`cloud-*`); JS/config → app internals.285. **Handle responsibly**: prove validity minimally (e.g. `sts get-caller-identity` for AWS if in29 scope), never exfiltrate data, and report leaked secrets for rotation.3031## Gotchas32- **Stay in scope**: employees' *personal* repos and unrelated orgs may be out of scope — confirm33 before touching, and never use a live credential you aren't authorized to use.34- Many hits are dead/rotated keys — validate before reporting, but report even revoked ones as a35 process finding when the program wants it.36- GitHub code search rate-limits and truncates — combine the web UI, the API, and offline history scans.3738## Verify success39You have leaked material tied to the target — a valid credential (verified minimally and in scope),40an internal endpoint/host, or config — that advances the engagement or is a reportable exposure.4142## References43truffleHog & gitleaks; GitHub code-search dork lists; the classic AWS-key-in-git incident write-ups.
NoorQureshi