DefaultCreds-cheat-sheet consolidates thousands of vendor default username/password pairs into a searchable Python CLI and CSV dataset, serving pentesters and blue teams auditing their own infrastructure for a classic authentication weakness.
| Tool | ihebski/DefaultCreds-cheat-sheet — searchable dataset and creds CLI covering 3,711 default credential entries across 1,398 unique products/vendors |
| Category | Credential intelligence / authentication audit reference |
| Primary Use | Looking up vendor default credentials with creds search <product> during authorized pentest, red team, and blue team hardening engagements |
| Safe Use | For authorized penetration tests, lab exercises, and defensive audits of systems you own or have written permission to test, aligned with OWASP WSTG-ATHN-02 |
| Telemetry Note | The tool itself is a passive local database lookup — no network scanning; defenders observe its impact only indirectly, e.g., repeated failed logins against appliances if results are misused against systems they do not own |
Default credentials remain one of the most persistent and least glamorous weaknesses in enterprise infrastructure, and ihebski/DefaultCreds-cheat-sheet attacks the problem from the reference side. The project is a curated dataset of vendor-shipped username and password pairs — 3,711 rows covering 1,398 unique products and vendors — packaged both as a plain CSV file and as a Python command-line utility called creds. The stated motivation is explicitly dual-sided: it exists to assist pentesters and red teamers during engagements, and equally to help blue teamers discover and mitigate the flaw in their own environments, with the README pointing directly at OWASP WSTG-ATHN-02 (Testing for Default Credentials) as the canonical methodology.
The dataset is not built from scratch; the README is refreshingly honest about its provenance. The bulk of the entries were extracted from three well-known projects — ztgrace/changeme, threat9/routersploit, and danielmiessler/SecLists (specifically its Default-Credentials subtree) — supplemented by govolution/betterdefaultpasslist, arnaudsoullie/ics-default-passwords for industrial-control gear, and finally vendor documentation and blogs. This aggregation is the real value proposition: instead of juggling five scattered wordlists, an operator gets one normalized corpus that also includes an ICS angle most generic lists miss. The maintainer credits those upstream projects explicitly, which is good hygiene for a derivative dataset.
The README publishes short statistics on the corpus that are worth pausing over because they say something about the ecosystem. Of 3,711 rows, only 1,121 usernames and 1,680 passwords are unique — meaning enormous repetition, and indeed the top username value is a blank field appearing 814 times, with a blank password topping out at 479. Oracle is the most frequent vendor entry at 235 rows. That concentration matters operationally: a tiny handful of credential pairs (admin/admin, blank logins, vendor names) covers a disproportionate share of the dataset, which is exactly why default-credential checks are cheap, high-yield first moves in an authorized assessment and equally cheap to audit defensively.
On the tooling side, the package is distributed on pypi as defaultcreds-cheat-sheet, so installation is a one-liner: pip3 install defaultcreds-cheat-sheet. The primary interface is creds search <product> — for example creds search tomcat returns a formatted table of matching Product, username, and password triples for apache tomcat (web) and friends. A manual path is also documented for those who prefer git clone of ihebski/DefaultCreds-cheat-sheet followed by pip3 install -r requirements.txt and copying the creds wrapper into /usr/bin. The README claims testing on Linux (Kali, Ubuntu, Lubuntu), Windows 10/11, and macOS, which suggests the maintainers care about cross-platform usability rather than assuming a Kali-only audience.
A useful operational detail is the creds update command, which checks for and downloads a refreshed database. That matters for a dataset like this, because default credential lists rot — vendors ship new appliances, and community pull requests keep adding entries (the README actively solicits PRs for missing products). Rather than re-installing the package, the update flow keeps the local corpus current, and from version 0.5.2 onward both search and update accept a --proxy=http://localhost:8080 flag so the database check can be routed through an intercepting proxy or egress-controlled network. That flag is a small touch but reveals an operator-minded author.
The export subcommand deserves scrutiny for what it implies. Appending export to a search — e.g. creds search tomcat export — writes results to /tmp/tomcat-usernames.txt and /tmp/tomcat-passwords.txt, and the README candidly notes these files "could be used for brute force attacks." For readers of this blog, the framing should stay on the legitimate side: within an authorized engagement, exporting pairs feeds tools like ztgrape/changeme or routersploit for credentialed validation against in-scope appliances, and on the defensive side the same export tells a hardening team exactly which pairs to verify have been rotated across their fleet. We will not be walking through any attack chain here; the dataset's value as documentation stands on its own.
Beyond the bundled CLI, the project has spawned an ecosystem consumer worth knowing about. noraj of the sec-it collective built pass-station, a separate CLI and Ruby library that queries this project's DefaultCreds-Cheat-Sheet.csv directly, adding field-selective search, regexp matching, highlighting, and multi-format output including JSON, YAML, and CSV. For automation-friendly workflows — say, enriching an asset inventory with known-default pairs and feeding a configuration-management pipeline — pass-station is arguably the more programmable front end, while the creds script remains the quicker interactive path. Both demos are recorded as asciinema casts linked in the README.
For blue teams, the defensive application is the more interesting half of the README's motivation section. Default credentials are a configuration flaw, not a vulnerability with a CVE, so they slip past patch-driven programs entirely. The practical defensive play is to take the dataset as a blocklist source: enumerate the appliance and product families actually deployed in your environment, look them up here, and then either verify via managed configuration baselines or write detection logic that alerts on any authentication attempt using those known pairs — a blank login against an Oracle or Tomcat service should be treated as a high-signal event precisely because 814 dataset rows tell you blank credentials are common enough to be tried first.
Architecturally the project is simple by design: a CSV as the single source of truth, a thin Python CLI over it, and an update mechanism that re-pulls the database. That simplicity is a feature — nothing here phones home beyond the update check, results are computed locally, and the data is fully inspectable before use, which is more than can be said for many closed credential-intelligence feeds. The MIT license and the 6,700-plus star count on ihebski/DefaultCreds-cheat-sheet indicate this has become something of a community standard reference rather than a hobby list.
Caveats are the usual ones for any aggregated dataset: entries age, some vendor pairs vary by firmware version, and the README marks the project as "in progress," so treat lookups as leads to verify rather than gospel. The disclaimer at the foot of the README is blunt — educational purposes, use at your own responsibility — and that is the correct posture. In scope, on owned or contracted systems, DefaultCreds-cheat-sheet is a fast, well-sourced reference that closes the gap between knowing default credentials are a problem and having the specific pairs in hand to prove or disprove it.
ihebski/DefaultCreds-cheat-sheet.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.