git-hound is a Go-based OSINT utility that pairs GitHub dorks with regex pattern matching and commit-history analysis to find exposed API keys and credentials, primarily for bug bounty hunters and authorized security teams.
| Tool | tillson/git-hound — pattern-matching secret sniffer that scans all of public GitHub, including Gists, for leaked credentials |
| Category | GitHub OSINT and secret detection |
| Primary Use | Hunting exposed API keys and credentials during authorized bug bounty programs and internal leak audits using GitHub dorks, custom regex --rules, and --dig-commits history analysis |
| Safe Use | Intended for authorized security assessments, bug bounty programs with defined scope, and organizations auditing their own secrets on GitHub; any discovered credentials belong to their owners and must be reported through responsible channels |
| Telemetry Note | All queries hit GitHub's Code Search API using a token from config.yml, so activity is fully logged in the token owner's GitHub API audit trail; the --api-debug flag makes request counting explicit |
git-hound occupies a distinctive niche in the secret-scanning ecosystem: rather than auditing a repository you already possess, it turns GitHub's Code Search API into a global reconnaissance surface. The tool, written in Go by Tillson Galloway and released under the MIT license, has accumulated roughly 1,461 stars and tags itself with topics spanning bugbounty, osint, devsecops, and secret-management. Its self-description — a pattern-matching, patch-attacking, batch-catching secret snatcher — is unusually accurate: the tool combines dork-driven queries, a database of service-specific regexes, and a scoring pipeline that aggressively filters false positives before anything reaches your terminal.
The core architectural decision that separates git-hound from tools like trufflehog or gitleaks is scope. Those tools typically enumerate known repositories or organizations; git-hound leverages GitHub's Code Search API to sweep across all public repositories and Gists simultaneously. You feed it a query — the README's canonical example is echo "AKIA" | git-hound or git-hound --query "AKIA" — and every file and repository matching that query becomes a candidate for deeper inspection. This is dork-based OSINT at scale, not targeted auditing, and that distinction shapes where the tool legitimately fits in a workflow.
Internally, the detection logic lives in internal/app/keyword_scan.go, and the README is refreshingly candid about how it works. GitHound starts with exact regexes for well-known services like Slack and AWS, then layers on a context-sensitive generic API regex that surfaces long strings adjacent to keywords like Authorization or API-Token. Crucially, the tool assumes every candidate is a false positive until proven otherwise: it validates hits using Shannon entropy calculations, dictionary word checks, uniqueness measurements, and encoding detection. For files that obfuscate credentials, it decodes base64 strings and re-scans the plaintext for key patterns. This adversarial scoring posture is what keeps the signal-to-noise ratio usable when you are scanning the entire public GitHub corpus.
The regex database itself is not homegrown — git-hound uses the API key regex collection maintained by the authors of Gitleaks, one of the most widely deployed secret scanners in the industry. This means detection coverage for common providers inherits from a well-audited upstream source, and the --rules flag lets you point at either a flat list of custom regexes or an entire GitLeaks rules folder, with rules/ as the default. That interoperability matters for corporate use cases: if your organization issues API keys with a proprietary format, you can express that format as a custom rule and hunt for it globally.
Two flags dominate the operational profile. --dig-files instructs the tool to enumerate and grep through the files of matching repositories, while --dig-commits walks commit history to surface deleted or reverted credentials — the classic failure mode where a developer commits a key, notices the mistake, and force-pushes a cleanup that the object database still retains. Both are flagged as CPU intensive in the documentation, and --threads (default 20) controls the parallelism of that digging. The --many-results flag applies a filtering trick to exceed GitHub's normal 100-page result cap, and --languages narrows queries to a list of languages, which the README notes is useful for high-profile targets where result volume is enormous.
Configuration follows conventional patterns. The tool reads config.yml from the current directory or $HOME/.githound/, with config.example.yml as a template, and environment variables override the file: GITHOUND_GITHUB_TOKEN sets the API credential and GITHOUND_INSERT_KEY configures the optional dashboard integration. Version 3.0 introduced GitHound Explore, a web dashboard reachable via the --dashboard flag at githoundexplore.com, for real-time result visualization, alongside a browsable GitHub dorks database. The dashboard is optional — the README is explicit that the tool functions fully without it — but blue teams evaluating the tool should note that results streamed there leave the local environment.
The README's use case section is honest about the two audiences. The corporate scenario describes an organization hunting for its own exposed customer API keys: knowing your key format, you run git-hound with a custom rules file, pipe --results-only output into an internal validation script, and identify at-risk accounts. The README also correctly points to GitHub's native Push Token Scanning as the proactive complement that catches keys at push time rather than after public exposure. The bug bounty scenario demonstrates querying for leaked employee tokens within program scope, combining --dig-files, --dig-commits, --many-results, and --languages for deep coverage of in-scope targets.
From a defender's perspective, git-hound is as much a diagnostic instrument as an offensive one. The academic reference the README cites — the NDSS paper How Bad Can It Git? by Meli, McNiece, and Reaves — contextualizes the problem: secret leakage in public repositories is a measured, systemic phenomenon, not an edge case. Organizations running red-team-style leak audits against their own namespaces, or building DevSecOps hygiene programs, get direct value from the --json output flag, which makes results consumable by automation pipelines, SIEM ingestion, or ticketing workflows. The --no-api-keys, --no-files, --no-gists, and --no-keywords flags allow precise tuning of what surfaces get searched, which is useful when you are auditing one specific exposure class.
Operationally, there are things to watch. Authentication supports both a token and, in the Docker configuration examples, github_username and github_password with an optional github_totp_seed — credential-on-disk handling that demands care, and the --otp-code flag exists for accounts with authenticator-based 2FA. The --search-type flag selects between api and ui search interfaces, reflecting GitHub's evolving and rate-limited code search endpoints; --api-debug counts requests, which is essential for staying within quota during large sweeps. The --profile flag exposes pprof on localhost:6060 for performance debugging during development.
Deployment options are straightforward: prebuilt binaries ship on the GitHub releases page, go build . compiles from source, and a provided Dockerfile supports containerized runs with config.yaml and input files mounted as volumes. Installation is as simple as downloading the release binary and populating config.yml with an API token, after which ./git-hound validates the setup.
The ethical boundary here deserves explicit statement. Everything git-hound surfaces is technically public on GitHub, but public does not mean authorized to use. The legitimate workflow is discovery followed by responsible disclosure — to the bug bounty program, to the credential owner, or to your own incident response team. Testing discovered keys against live services without authorization crosses from reconnaissance into abuse, and the corporate example in the README models the correct pattern: validate only your own keys, identify your own at-risk accounts, and remediate. For authorized professionals auditing exposure, git-hound remains one of the more thoughtfully engineered answers to a genuinely hard discovery problem, and its false-positive-disciplined scoring pipeline is the part worth studying even if you never run it.
tillson/git-hound.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.