PCredz has no authorization boundary, only an exclusion list

Live capture runs as root on a whole interface, with no allow list

Scope is the part of this tool that needs deciding before anything else. The `-i INTERFACE` option starts live capture and the documentation states that it requires root, showing `sudo ./Pcredz -i eth0`. There is no confirmation step, no dry run, no target prompt and no notion of which systems are permitted. The single scope control is `--exclude-host IP`, repeatable, and it is subtractive: it names hosts to leave out rather than hosts to collect. The usage examples make the intended posture explicit. One of them is labelled pentesting, capture target credentials not your own, and it excludes the machine's own address:

sudo ./Pcredz -i eth0 --exclude-host $(hostname -I | awk '{print $1}') -v

That is a tool whose documented use is collecting other people's credentials from a network segment. On a shared segment, a span port, or an interface you do not own, the exclusion list is the only thing standing between the script and credentials that were never yours to take. Decide the interface and the host list before starting, not after reading the output.

Credit card scanning runs by default and -c is the only switch

The repository description lists card number extraction among the things this tool pulls out of traffic, and the feature list repeats it as an optional item. Optional here means off only if you ask for it. There is a dedicated flag, `-c`, described as disabling credit card scanning, and it is the only protocol that got its own switch. Every other protocol is handled by the generic `--disable PROTO` option, whose accepted values are NTLM, HTTP, FTP, IRC, LDAP, SMTP, Kerberos, SNMP and MSSQL. So the default run of PCredz over a capture is looking for payment card numbers in addition to credentials, which is a different kind of finding and a different kind of data handling from a password. It also means the file list of outputs has no obvious home for what it finds, since no card output file appears in the documented layout of the `logs/` directory.

The --disable list omits POP3 and IMAP, and SNMPv2c lands in an SNMPv1 file

Count the two lists against each other. The feature list names twelve extraction targets: NTLM, Kerberos, HTTP basic and form fields, FTP, IRC, SMTP, IMAP, POP3, LDAP simple bind, SNMP, MSSQL and credit cards. The `--disable PROTO` option accepts nine names, and neither IMAP nor POP3 is among them. Those two protocols are extracted and cannot be turned off by flag, so if you are analysing a capture where POP or IMAP logins should not be surfaced, the only lever is not running the tool over that capture. The output layout has the same gap: eleven files are named, covering NTLMv1, NTLMv2, MSKerb, HTTP-Basic, HTTP-PasswordFields, FTP-Plaintext, IRC-Plaintext, SMTP-Plaintext, LDAP-Simple, MSSQL-Plaintext and SNMPv1, with nothing for IMAP or POP3. SNMP has a naming mismatch of its own, since community strings from both v1 and v2c are extracted into a file called SNMPv1.txt.

Kerberos pre-authentication is captured before any password check happens

One entry on the list deserves its own note because of how it works rather than what it finds. The Kerberos support is described as AS-REQ Pre-Authentication hashes, etype 23, written to `MSKerb.txt` and labelled for hashcat mode 7500. A pre-authentication hash sits in the ticket request itself, before the server has verified anything, so it is present in traffic that never carried a password and never completed a login. No prior authentication is needed for it to be captured. The NTLM entries behave the same way in kind, with NTLMv1 and NTLMv2 complete hashes written to separate files and labelled for modes 5500 and 5600, which is what makes the output format useful to an offline guessing tool and useless as a log of what actually succeeded. LDAP simple bind is the opposite case and is stored as a plaintext password in `LDAP-Simple.txt`. This article stops at extraction and does not walk through what is done with the resulting files.

The benchmarks are numbers without a method behind them

A performance section states four optimisation claims and four timings, and none of them can be checked from what is published. File I/O caching is credited with a 10 to 100 times speedup, regex pre-compilation with 2 to 5 times, deduplication with in-memory tracking and link layer detection with minimal overhead. The timings then say small files under 10MB take less than a second, a 100MB file takes 5 to 10 seconds, a 1GB file takes 1 to 2 minutes, and live capture runs at 5,000 to 10,000 packets per second on modern hardware. No hardware is named, no packet mix is described, no capture size or protocol mix backs the figures, and there is no script in the repository that reproduces them. The 100 times figure in particular is the kind of number that belongs in a changelog entry with a before and after commit, and it is not clear from the text whether it is a measurement or an expectation. Treat all of it as a claim about the author's setup.

No releases, one script, and a version that exists only in the README

The repository has no releases at all, and the root holds a short list: `.github/`, `Dockerfile`, `LICENSE`, `Pcredz`, `Readme.md` and a `logs/` directory. There is no package metadata, no setup script and no version declaration anywhere in that list, so the version 2.1.0 exists only as the README's top heading. On Linux the documented install is a system package plus one Python library, and the script is then run from wherever you cloned it:

sudo apt-get install python3-pip libpcap-dev
pip3 install pcapy-ng

with the Fedora, RHEL and Arch equivalents given for `dnf` and `pacman`. The troubleshooting section adds a fallback that is worth noticing on a modern distribution, `pip3 install --break-system-packages pcapy-ng`, which tells pip to override the protection that stops it writing into the system interpreter. Given no tags to pin, the practical upgrade path is reading the diff yourself. The last push to the default branch is dated 2026-03-02.

The runtime image keeps the compiler it needed to build one extension

The container is built from `python:3.11-slim-bookworm` and installs libpcap-dev, gcc, g++, git and pcapy-ng in one layer before copying the single script to `/opt/Pcredz/Pcredz`, creating a logs directory, marking the file executable and setting `ENTRYPOINT ["/opt/Pcredz/Pcredz"]` with `CMD ["--help"]`. The compiler packages exist so that the pcapy-ng C extension can be built, and they stay in the shipped image because nothing removes them afterwards. The documented usage mounts the working directory and passes either a file or an interface:

docker run --rm -v $(pwd):/data pcredz -f /data/capture.pcap
docker run --rm --net=host -v $(pwd):/data pcredz -i eth0 -v

The host network flag on the second line is what turns a container into something that can see traffic, and it is the line to read twice before running it. Everything the tool writes lands under the mounted directory, in the `logs/` folder that the image also creates for itself.

Deduplication is on by default, so repeats vanish from the type files

The last mechanism worth understanding changes what your evidence looks like. By default the same credential is written once, and duplicates appear only when `-v` is passed. That applies to the per protocol files, so a password reused across two hundred hosts is a single line in `NTLMv2.txt` and the repetition count is not recoverable from that file. The complete timeline lives elsewhere, in `CredentialDump-Session.log`, and `-t` adds timestamps to what is printed. The troubleshooting advice for a capture that yields nothing is to try verbose mode to see all activity, which is the same flag doing double duty: it is the switch that turns a deduplicated summary into a full listing. Anyone building a timeline from the per protocol files alone will undercount, and anyone diffing two runs will see a difference in output that comes from the flag rather than from the traffic.

Editorial conclusion

PCredz fits an authorized engagement where you already hold written permission for the traffic you intend to analyse, and where the captures stay inside your own estate. Outside that, the tool has no way to know whose traffic it is taking, and its own documentation shows the intended workflow as excluding your own address so that everyone else's credentials are the ones collected. Before running it anywhere, agree in writing which interface and which hosts are in scope, set the exclusion list deliberately rather than by habit, and remember that credit card scanning is enabled unless you pass -c. Also weigh the practical state of the tool: there are no releases, the version exists only in the README heading, and the last push to the repository is dated 2026-03-02, so expect to read the script yourself rather than to upgrade between fixed versions.

Frequently asked questions

Official sources

1. Issues
2. lgandx/PCredz on GitHub
3. License: GPL-3.0
4. README