GitHub recon: finding leaked secrets in your scope

Developers leak. A hardcoded key in a commit, a config file pushed by accident, an internal hostname in a comment: public code holds recon value for a scope you own or a program you joined. The work is finding the repos and users tied to your target, then scanning them with tools built for secrets. Keep it scoped. You read public code, and you never log in with anything you find.

#Find the repos and users

Start from the organisation and the domain. The GitHub web code search, while logged in, takes qualifiers you can combine.

"example.com" org:example-inc
"api_key" "example.com"
filename:.env "example.com"

github-search scripts the same idea with a token, pulling users, repos and code matches for a term. Its github-subdomains script finds hostnames mentioned anywhere in public code, a source the DNS tools miss.

github-subdomains -d example.com -t $GITHUB_TOKEN -o gh-subs.txt

Widen the net to the people around the org. Employees list their work on their profiles, so a search for the company name across users surfaces accounts whose personal repos sometimes mention internal tools. Keep those leads, but remember whose data they are and treat a personal account with more care than a company one.

#Scan clones for secrets

Once you have repos, clone the in-scope ones and scan locally. gitleaks reads the full git history, not just the current files, so a secret removed later still turns up.

gitleaks detect --source ./example-repo --report-path leaks.json

trufflehog goes further and verifies many secret types by testing whether the credential still works, which cuts false positives sharply.

trufflehog git https://github.com/example-inc/example-repo --only-verified

A verified hit is a live credential. Do not use it. Record it, with the commit and the file, for the report, and let the owner rotate it. Scanning a large monorepo takes a while, so start with the repos your dorks already tied to the target rather than every fork and mirror.

#Write good queries with the chat

Dorking GitHub is a language problem: the right qualifier finds the leak, the wrong one buries it. Ask the NotHoly chat to expand a seed into a query set.

My scope roots are example.com and example.net, org example-inc.
Write 15 GitHub code-search queries to find leaked secrets,
internal hostnames and config files tied to these. Vary the
qualifiers (org, filename, path, language). One per line.

You paste the queries back into GitHub search yourself, not into a tool that runs them for you. The model also reads a gitleaks report well: paste the JSON and ask it to group hits by secret type and rank them by how likely each is real and in scope.

#Scope and privacy

Public code often belongs to individuals, not the target company. An employee's personal repo is a person's data, and their old side project is not in your scope. Stay on repos owned by the org or clearly tied to the target's infrastructure. Never authenticate with a leaked credential, never push a commit, and report secrets through the program's channel so they get rotated.

#Frequently asked questions

#Is reading a found secret a problem?

Reading public code is one thing; using a credential you found is another, and it can cross a computer-misuse line even inside a bug bounty program. Report it and do not test it by logging in.

#What about old commits that were deleted?

Git keeps history. A secret removed in a later commit still sits in the earlier one, which is exactly why gitleaks and trufflehog scan the whole history rather than the current tree.

Code search rounds out your automated sources. Next, sharpen your manual skills in search-engine dorking that works. Back to certificate transparency and DNS history.