# windows-coerced-authentication-methods: a catalogue of RPC calls that leak machine credentials > This repository is a research index of fifteen methods across thirteen Windows RPC protocols that will make a domain machine authenticate to an attacker controlled host, with a README page per method and the protocol opnum it relies on. It suits a defender mapping exposure or a researcher studying NTLM relay, and it is a written catalogue rather than a tool that performs the coercion. **p0dalirius/windows-coerced-authentication-methods** — A list of methods to coerce a windows machine to authenticate to an attacker-controlled machine through a Remote Procedure Call (RPC) with various protocols. - Repository: https://github.com/p0dalirius/windows-coerced-authentication-methods - Website: https://podalirius.net/ - Stars: 613 · Forks: 70 - Language: Python - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/p0dalirius-windows-coerced-authentication-methods ## A written index of coercion methods, not an exploitation toolkit This repository contains a list of many methods to coerce a windows machine to authenticate to an attacker-controlled machine, and the README states the count plainly: there are currently 30 working functions in 13 protocols, with a badge on the project page reflecting the 15 methods indexed at the time of writing. That distinction matters for how the repository should be read. The top level contains a .github directory, the README, a methods directory and a possible-working-calls directory. There is no package manifest, no test suite, no build file and no release history, and the repository has no GitHub releases. The primary language is recorded as Python, which reflects the scripts used to research and confirm the calls rather than a library that ships with the project. The audience is therefore two overlapping groups. The first is a defender doing exposure mapping: given a list of entry points, you can check which of them your own domain controllers expose, which is a far more actionable artefact than a single working technique. The second is a researcher who wants the protocol surface laid out systematically, with each method documented against the Microsoft protocol specification that describes it. The README credits the ecosystem around it with social and video channel links for the author, and the topics list names the domain: authentication, call, coerce, microsoft, privilege-escalation, rpc and windows. The homepage is the author's own site, and the licence field is recorded as unknown, with the terms in the LICENSE file, so the licensing position is something to check before redistributing the documentation inside a commercial engagement. ## The root cause is UNC path authentication, and that is why the list is long The explanation the README gives for why these methods work is the most important paragraph in the repository, and it is the same for every entry. All of these methods are callable by a standard user in the domain, and they force the machine account of the target Windows machine, usually a domain controller, to authenticate to an arbitrary target. The root cause of this vulnerability or feature, in the README's own framing, is that Windows machines automatically authenticate to other machines when trying to access UNC paths, with the example given of a path into a SYSVOL share on a machine at a particular address. That single behaviour is why the catalogue is as long as it is. Any Windows service whose RPC interface will open a file handle on a path the caller controls, on a server the caller names, inherits the coercion. The protocols are not a related family chosen for variety; they are a set of unrelated Windows subsystems that all happen to accept a path over RPC. The distinction the README draws between a vulnerability and a feature is also worth keeping in mind, and it changes what an assessment is looking for. If the behaviour is a documented characteristic of how Windows authentication works, then the fix is not a patch to a single component but a set of mitigations, and the useful output of this repository is the enumeration of entry points rather than any one of them. What the repository does not attempt is a single unified exploitation chain. Each method is a separate README with its own opnum, its own protocol and its own discussion, and the possible-working-calls directory is where calls that are known to work but are not yet fully documented are kept apart from the ones that are. ## Where the collection lives, and how to work through it There is no installation step, because there is nothing to install, and the README does not describe a build, a package or a release. What the README does instead is point you at the repository itself, with the method pages linked directly from the protocol list in the page you are reading, so the collection is navigated in a browser rather than fetched. The practical way to work through it is by protocol. Each protocol heading in the README expands into its list of calls, and each call links to a README of its own in the methods directory. Reading the protocol list top to bottom gives you the full surface, and the opnum in each link tells you which operation you are looking at before you open the page. Two directories matter for understanding the state of the work. The methods directory holds the documented calls, one directory each, and the possible-working-calls directory holds the ones that are believed to work but are not yet written up in the same form. A reader building a checklist should treat the first as surveyed and the second as reported but unverified. The repository also carries a .github directory, and the README is linked from the author's homepage, which is where the surrounding research notes sit. There is no documentation site separate from the repository, so the README is the whole entry point, and that is a deliberate choice for a project whose value is the index rather than a tool. ## Thirteen protocols, and what each one contributes The protocol list is where the structure of the collection becomes clear, because the entries are grouped by the Microsoft protocol specification that documents them. MS-COMA is the Component Object Model Plus Remote Administration Protocol, and it contributes the ImportFromFile remote call at opnum 3. MS-DFSNM, the Distributed File System Namespace Management Protocol, contributes five calls: NetrDfsAdd, NetrDfsAddStdRoot, NetrDfsRemoveStdRoot, NetrDfsAddRootTarget and NetrDfsRemoveRootTarget, at opnums 1, 12, 13, 23 and 24 respectively. The DFS namespace management interface is the largest single contributor in the visible part of the list, which is consistent with its role as the component that resolves a namespace path to a target server. MS-DHCPM, the Microsoft Dynamic Host Configuration Protocol Server Management Protocol, contributes the DHCP backup and restore database calls, R_DhcpBackupDatabase at opnum 44 and R_DhcpRestoreDatabase at opnum 45. MS-DNSP, the Domain Name Service Server Management Protocol, contributes R_DnssrvOperation with a LogFilePath operation at opnum 0. MS-EFSR, the Encrypting File System Remote protocol, is the largest block in the visible list, with ten calls: EfsRpcOpenFileRaw, EfsRpcEncryptFileSrv, EfsRpcDecryptFileSrv, EfsRpcQueryUsersOnFile, EfsRpcQueryRecoveryAgents, EfsRpcFileKeyInfo, EfsRpcDuplicateEncryptionInfoFile, EfsRpcAddUsersToFileEx, EfsRpcFileKeyInfoEx and EfsRpcEncryptFileExSrv, at opnums 0, 4, 5, 6, 7, 12, 13, 15, 16 and 21. That volume is explained by what EFS does, since the protocol is built around opening a file on a remote server and asking the server to operate on its encryption metadata, so almost every operation takes a server-controlled path. MS-FSRVP, the File Server Remote VSS Protocol, contributes IsPathSupported at opnum 8 and IsPathShadowCopied at opnum 9. MS-PAR, the Print System Asynchronous Remote Protocol, contributes RpcAsyncOpenPrinter at opnum 0. MS-PLA, the Performance Logs and Alerts Protocol, contributes Extract at opnum 31. MS-RAIW, the Remote Administrative Interface WINS, contributes R_WinsDoStaticInit at opnum 3, with further entries in the list following it. ## The naming convention, and why the opnum is the useful part Each method gets its own directory and its own README, and the path encodes everything a reader needs to find the method again. The layout follows a consistent pattern, with a directory per protocol named after the specification and its title, then a subdirectory per call named with the call name, the opnum in parentheses, and a README.md inside. The encrypting file system example is typical, and the entries are prefixed with the opnum in two digit form, so the directory listing reads as an index of operation numbers. That is a deliberate design choice and it is the one that makes the collection useful beyond a single demonstration. An opnum is the offset of a function in the vtable of an RPC interface, and it is stable for the life of the interface version. So a directory named for opnum 21 of EfsRpcEncryptFileExSrv is a stable handle: a defender can look at the service interface of the RPC endpoint, find that operation number, and ask whether the environment is patched against it. The README also uses a consistent naming for the call itself, with the protocol specification reference in brackets, for example MS-EFSR for Encrypting File System Remote, MS-DFSNM for Distributed File System Namespace Management, and MS-DHCPM for the DHCP Server Management Protocol. The full titles are given in the link text. The possible-working-calls directory is the other half of the structure, and it is the honest bookkeeping of an ongoing research project. The methods that are documented and confirmed sit in the methods directory, and the ones that are believed to work but are not yet written up sit in the other directory. For a reader assessing coverage, that distinction tells you which parts of the map are surveyed and which are still being charted. ## What this repository cannot tell you, and what it can Two limits are visible in the documentation and are worth naming before anyone builds an assessment on top of it. The first is that the catalogue is a snapshot of a moving target. Windows changes, interfaces gain and lose operations, and a list of 30 working functions across 13 protocols is accurate for the versions its author tested. The README does not state which Windows builds were tested against, and the repository has no release history and no tags to track the state of the list. The last push was on 2026-09-15, which tells you when the list was last touched and not what it was tested on. The second is that this is a document about authentication behaviour, not a detection tool. It does not scan a network, it does not enumerate open RPC endpoints, and it does not tell you whether your domain is exposed. To get from the list to an answer about your own environment you need the protocol specification for each interface, a way to enumerate the RPC endpoints your domain controllers expose, and the patch level of those controllers, and none of those three are in the repository. What it does give you is the thing that is genuinely hard to assemble by hand. Finding these calls means reading a dozen Microsoft protocol specifications and working out which ones take a server path the caller controls. The repository has done that reading and recorded the opnums, and the per-method READMEs are where the reasoning for each one lives. The right use of it is as a checklist for a hardening review, paired with knowledge of what mitigation actually addresses the underlying UNC authentication behaviour rather than any single call. Judged that way, the length of the list is an advantage. A shorter list of techniques would tell you less about how much surface the behaviour exposes. ## Conclusion This repository fits a defender who wants to know which RPC paths on their own domain can be coerced into outbound authentication, and a researcher who wants a structured map of the protocol surface rather than a working exploit chain. It does not fit someone looking for a tool to run, because the repository contains documentation, and the README does not describe an installation or a set of scripts. Before using it in an assessment, check the method list against the patch level of the domain controllers in scope, because the underlying behaviour is a Windows design characteristic rather than a single defect, and the useful output is the enumeration of exposed entry points rather than any single call. ## FAQ ### What is the windows-coerced-authentication-methods repository? It is a research index of methods to coerce a Windows machine to authenticate to an attacker-controlled machine through RPC, with a README page per method and the protocol opnum it relies on. The README states there are currently 30 working functions in 13 protocols. ### Why do these Windows RPC coercion methods work? The README states the root cause is that Windows machines automatically authenticate to other machines when trying to access UNC paths, with SYSVOL given as the example. Every method is callable by a standard user in the domain and forces the machine account of the target, usually a domain controller, to authenticate out. ### Which protocols are covered in the coerced authentication list? The visible list includes MS-COMA, MS-DFSNM, MS-DHCPM, MS-DNSP, MS-EFSR, MS-FSRVP, MS-PAR, MS-PLA and MS-RAIW, with the encrypting file system remote protocol contributing the largest number of calls, ten of them. ### Does the repository contain code that performs the coercion? The top level holds the README, a .github directory, a methods directory and a possible-working-calls directory, with no package manifest or build file and no GitHub releases. The primary language is recorded as Python, reflecting the research scripts rather than a shipped tool. ## Sources - [Issues](https://github.com/p0dalirius/windows-coerced-authentication-methods/issues) - [p0dalirius/windows-coerced-authentication-methods on GitHub](https://github.com/p0dalirius/windows-coerced-authentication-methods) - [Project website](https://podalirius.net/) - [README](https://github.com/p0dalirius/windows-coerced-authentication-methods/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/p0dalirius-windows-coerced-authentication-methods