Coercer walks Windows RPC methods until a server authenticates to you

Coercion makes a Windows server authenticate to your listener

Coercer automates one specific abuse of Windows RPC: it makes a remote server send an NTLM authentication to an address you choose. You give it the listening address as an IP address or an interface, and something such as `ntlmrelay` or responder receives the authentication on the far side, which is where captured material ends up. Coercer itself is not a listener, not a hash cracker and not a scanner for your own estate. It is a trigger generator, walking a list of RPC functions known to hand a server an attacker-chosen UNC path so the trigger fires for you. That framing is what to check first when deciding whether the tool fits, because the value sits in how many named pipe methods it walks rather than in the authentication that follows. The credits name the research behind those methods, which matters when judging whether the coverage is current.

Three modes split assessment from coercion and fuzzing

The quick start maps three intentions onto three modes. Assessing what RPC endpoints listen and whether they can be coerced at all is scan mode, documented at `documentation/Scan-mode.md`. Driving an authentication to ntlmrelay or responder is coerce mode. Hitting endpoints with various paths while doing research is fuzz mode. The finer detail sits in the feature list, where every capability carries a mode qualifier. Listing open SMB pipes is scoped to authenticated scan and authenticated fuzz only, while the unauthenticated variants of those same two modes try to connect to a list of known pipes. An unauthenticated run therefore tells you which candidate methods answer, not which pipes the host exposes, and a real inventory needs credentials the README never explains how to supply. Each mode links to its own page under `documentation/`, and the command examples stay in those pages rather than on the front page.

Random UNC paths exist so failures are not cached

Random UNC paths generation to avoid caching failed attempts runs in all modes, and it explains why a long run against one host does not collapse into a single remembered failure. Windows keeps the negative result for a path a server already refused, so a fixed name would make every attempt after the first meaningless. A configurable delay between attempts, set with `--delay`, spreads the calls out. What the README does not state is the unit `--delay` takes, nor whether the pause happens between every method or only between targets, so that value is worth confirming on a test host instead of assuming it. Both controls belong to the core feature list rather than to one mode, which means scan and fuzz runs are randomised too and produce a different path on every pass.

Filters, target files and the protocol list behind them

Scope comes from three filters and two target options. `--filter-method-name`, `--filter-protocol-name` and `--filter-pipe-name` narrow a run by method, protocol or pipe, and all three are documented as working in every mode. `--target` takes a single machine, `--targets-file` takes a list, so the same flags cover one host during assessment and a range during an engagement. The method list behind those filters traces back to protocol flaws credited on the front page: PrinterBug on MS-RPRN, PetitPotam on MS-EFSR, ShadowCoerce on MS-FSRVP, DFSCoerce on MS-DFSNM and CheeseOunce on MS-EVEN. Filtering by pipe name is the practical lever when a host exposes only a subset. Against the single-protocol implementations credited to individual researchers, the difference is packaging: one executable with mode and filter flags, a listener that stays swappable between ntlmrelay and responder, and export to a database rather than terminal output.

Results export to SQLite, JSON and XSLX, not stdout

Output does not stay on the terminal. Results export to SQLite, JSON and XSLX in scan and fuzz modes, which is what makes one run comparable with the next. `xlsxwriter` is a declared dependency, so the spreadsheet path is produced by the tool rather than by a script you write afterwards. The documented spelling and the file extension differ, so a log filter written from the documentation has to accept both forms. `jinja2` and `sectools` also sit in the dependency list without a stated role on the front page. Treat the three formats as the stable part and the column set as undocumented, because no schema is given for any of them and none is promised anywhere in the repository.

Pip installs it, installer.ps1 builds the Windows binary

Installation from PyPI is one command, and it is the only one given on the front page:

sudo python3 -m pip install coercer

Windows takes a separate path: download `installer.ps1` from the repository and run it with no arguments, and it creates a binary in the working directory, with the -h and --help flags opening the options menu. Notice the gap between that documented command and the project's Makefile, where every pip call carries `--break-system-packages`:

python3 -m pip uninstall coercer --yes --break-system-packages
python3 -m pip install .[build] --break-system-packages
python3 -m build --wheel

The maintainer route and the documented route are not the same route. The package declares `requires-python` at `>=3.7`, and its entry point binds the console script to `coercer.__main__:main`, so an installed copy answers to the name `coercer` rather than to `Coercer.py` sitting at the repository root.

Packaging metadata disagrees with itself on method count

Three method counts sit inside one project, and they disagree. The description field on the repository says 12 methods, the `description` key in `pyproject.toml` says 15, and the long description embedded in `setup.py` says 9, while the front page settles on the words many methods. setup.py carries a creation date of 17 Jul 2022 in its header and pyproject.toml declares version 2.4.3, so those three strings were not refreshed together. Pick your number by listing what an installed copy actually calls rather than by quoting any of the three in a coverage claim. The same pair of files disagrees on licensing: `pyproject.toml` declares MIT as its text while the repository records GPL-2.0, and that mismatch has to be settled by whoever owns the repository before the package is vendored into anything closed source. Neither figure is restated anywhere else in the documentation, so a mismatch here will not be corrected by reading further into the project.

A Windows-only dependency sits outside the build metadata

The dependency list is where the real constraints show, and it is inconsistent with itself. `requirements.txt` ends with `pydivert; sys_platform == "win32"`, yet the `dependencies` array in `pyproject.toml` carries no pydivert entry, and the build backend is poetry-core reading that same file:

argcomplete
impacket
xlsxwriter
jinja2
sectools
netifaces
psutil
pydivert; sys_platform == "win32"

A wheel built from that pyproject.toml therefore installs without the Windows capture dependency that the requirements file expects. The rest of the stack is pinned at its floor: `impacket` at 0.10.0, `xlsxwriter` at 3.0.0, `jinja2` at 3.1.3, `sectools` at 1.4.3 and `netifaces` at 0.11.0. Linting runs flake8 at a max-line-length of 88, and `coercer/ext` is excluded from flake8, black and isort alike, so vendored code in that directory is never checked. Upgrading follows the Makefile rather than the documented pip command, since its build target uninstalls the installed copy before reinstalling from source.

Editorial conclusion

Coercer fits a team that already owns a Windows segment and runs a listener such as `ntlmrelay` or responder, because it removes the manual work of binding each RPC method by hand. It does not fit an unscoped sweep, a network where you cannot receive the inbound authentication, or anyone who needs a documented rollback path. Verify three things before adopting it: how credentials reach the authenticated scan and fuzz modes, which the README does not document, and which of the 12, 15 or 9 method counts matches what an installed copy calls. The repository is not archived and its last push was on 2026-04-24.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. p0dalirius/Coercer on GitHub
3. Project website
4. README
5. Releases