
CredsHunter is a read-only, network-silent credential hunting toolkit that helps authorized pentesters locate reusable local credential material for privesc and lateral movement analysis.
| Tool | NeCr00/Credential-Hunting — read-only credential discovery toolkit for Windows and Linux, version 2.4.0 |
| Category | Post-exploitation credential enumeration (Bash + PowerShell) |
| Primary Use | Hunting for reusable local credential material — plaintext passwords, private keys, connection strings, GPP cpassword, credential containers — during privesc and lateral movement phases of an engagement |
| Safe Use | Strictly for authorized internal penetration testing, red-team engagements, labs, and CTF environments on systems you own or have explicit permission to assess; the tool is read-only and transmits nothing |
| Telemetry Note | Network-silent by design — no outbound traffic and no system modification — so its use is observable mainly through process creation of credshunter.sh/credshunter.ps1, elevated shell activity, high-volume local file reads, and its plain-text output file (loot.txt-style), which defenders can audit on monitored hosts |
CredsHunter, hosted at NeCr00/Credential-Hunting on GitHub, is a credential hunting toolkit built as a matched pair of scripts: credshunter.sh for Linux (Bash 4+) and credshunter.ps1 for Windows (PowerShell 5.1+). The project's stated purpose is narrow and deliberate — finding credentials that can actually be reused for lateral movement or privilege escalation during an authorized internal assessment, rather than generating a wall of low-value token matches. At version 2.4.0 and written primarily in PowerShell with roughly 181 stars, it sits squarely in the post-exploitation enumeration niche alongside tools like Lazagne-style credential dumpers, but with a distinctly scoped philosophy.
What immediately differentiates CredsHunter from generic secret-scanners is its explicit exclusion of cloud and SaaS access tokens. The README states plainly that JWTs, AWS access keys, GitHub tokens, Slack tokens, and generic API keys are not treated as primary findings, because they generate noise and are usually less useful for host-to-host lateral movement in an internal engagement. This is a smart editorial decision on the author's part: the tool optimizes for in-network reuse value — local hashes, plaintext passwords, private keys, connection strings — over the everything-is-a-secret approach of tools like trufflehog. Cloud-CLI credential files may still be surfaced as locations worth review, but their contents are not the target.
The architecture is a five-stage funnel, and understanding it is key to using the tool efficiently. Stage 1 inspects known OS and application credential stores — the Windows registry, Group Policy Preferences, shell histories, vaults, keys, and saved sessions. Stage 2 hunts for confirmed credential containers by extension: .kdbx (KeePass), .ppk (PuTTY), .pfx/.p12 certificates, .keytab Kerberos keytabs, and keystores. Stage 3 looks for high-value file types such as private keys, .env files, backups, databases, packet captures, archives, and configuration files. Stage 4 is a filename pass matching tokens like *password*, *secret*, *credential*, *login*, and *account*. Stage 5, the deepest and slowest stage, runs 70+ tuned credential regexes with false-positive filtering across readable text content.
The staging reflects real operational judgment: stages 2 through 4 are intentionally fast filename and extension passes, while stages 1 and 5 do the heavy lifting. Findings are surfaced live as the scan progresses rather than being hoarded until completion, which matters when you are working a time-boxed engagement and want immediate triage. Every result passes through false-positive filtering before it reaches the final output, and the README repeatedly emphasizes the low-noise design goal.
Results are grouped into finding tiers that map to usefulness and confidence. [CRITICAL] marks a confirmed credential container, [HIGH] flags reusable passwords, hashes, or GPP cpassword values, [KEY] covers private keys and key material including readable SAM/SYSTEM hive findings, [INTEREST] marks high-value files worth manual review, and [NAME] tags suspicious filenames as review hints. The exit-code semantics are automation-friendly: any finding in CRITICAL, HIGH, or KEY produces a non-zero sensitive-findings exit status, while INTEREST and NAME alone do not — making the tool trivial to drop into scripted engagement workflows or CI hygiene checks on gold images.
Installation is minimal since the scripts are self-contained. On Linux, git clone https://github.com/NeCr00/Credential-Hunting.git followed by chmod +x credshunter.sh gets you running; Windows needs nothing beyond git clone and PowerShell 5.1+. Elevated execution is optional but recommended on both platforms when you want visibility into protected stores like the SAM/SYSTEM hives and vault directories. Linux dependencies are intentionally mundane — find, grep, awk, sed, stat — with realpath and file as optional niceties, which means it runs on Debian, RHEL-family, Arch, and Alpine without fuss.
The scan-control surface is well thought out for operators who need to scope tightly. Both scripts accept multiple scan paths (-p/--path on Linux, -Path on Windows), exclusions (-x/--exclude, -ExcludePath), per-stage skips (--no-stage1 through --no-stage5, -NoStage1 through -NoStage5), a configurable file-size cap with a 5 MB default (-m/--max-size or -MaxFileSizeMB), and quiet/no-color modes for piping. Windows adds -IncludeData to pull SQL and CSV-style data files into scope and -NoDefaultExclude to disable built-in system and vendor exclusions. The --no-size-limit/-NoSizeLimit flag removes the cap entirely when credentials may hide in large logs or dumps.
Customization is a first-class concern rather than an afterthought. The pattern libraries, container-extension lists, high-value file types, suspicious filename tokens, and false-positive filters all live in clearly labeled configuration arrays inside each script. The README's guidance — edit the relevant list in one place without rewriting the scanning workflow — suggests the codebase is organized for exactly the kind of per-engagement tuning that experienced operators expect. Contributors are invited to submit new credential patterns, false-positive reductions, and platform-specific credential locations.
From a defensive perspective, CredsHunter's properties are worth noting. It is read-only by design, writes only to the operator-specified output file, and is network-silent — it never transmits discovered data. That same silence means blue teams cannot rely on network indicators to detect it; detection angles center on process creation events for credshunter.ps1/credshunter.sh, elevated shell activity, anomalous mass file reads across protected directories, and filesystem auditing of credential store locations. The tool also functions as a hygiene checker: running it against your own gold images and server baselines to confirm a zero sensitive-findings exit status is a legitimate hardening exercise.
The FAQ addresses the practical pain points candidly. Stage 5 slowness is acknowledged with concrete remedies — narrow the path scope, exclude noisy trees, keep the size cap, or skip stage 5 entirely. Missed credentials are diagnosed via a four-point checklist covering scan-path inclusion, exclusion paths, size limits, and extension coverage, with -a/--all as the broad fallback that scans every readable text file. The project wiki is referenced for deeper documentation, and the responsible-use section is unambiguous: authorized security testing, internal pentesting, red-team engagements, labs, and CTFs only, on systems you own or have explicit permission to assess. For operators in that scope, CredsHunter is a disciplined, signal-over-noise addition to the post-exploitation toolchain.
NeCr00/Credential-Hunting.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.