PrivFu, a WinDbg extension for taking tokens apart in the kernel

What the extension is for: making token privileges visible in the debugger

PrivFu is described as a kernel mode WinDbg extension and a set of proof of concepts for testing how token privileges work. The stated purpose of the code is to help investigate how token privileges work, and the project is explicit that it builds on existing public work, naming the Priv2Admin repository and its author as a notable example of research into token privilege abuse.

The centre of the project is PrivEditor, and its pitch is that it makes it easy to configure the token privilege you want to investigate. That is the part that distinguishes it from a one off exploit script. A token in a running kernel has privileges that are present but disabled, present and enabled, or absent entirely, and telling those three states apart from a memory dump by hand is slow work. The extension gives you commands for each operation.

0: kd> .load C:\dev\PrivEditor\x64\Release\PrivEditor.dll

PrivEditor - Kernel Mode WinDbg extension for token privilege edit.

Commands :
    + !getps       : List processes in target system.
    + !getpriv     : List privileges of a process.
    + !addpriv     : Add privilege(s) to a process.
    + !rmpriv      : Remove privilege(s) from a process.
    + !enablepriv  : Enable privilege(s) of a process.
    + !disablepriv : Disable privilege(s) of a process.
    + !enableall   : Enable all privileges available to a process.
    + !disableall  : Disable all privileges available to a process.

[*] To see command help, execute "!<Command> help" or "!<Command> /?".

The commands are namespaced with the usual debugger extension syntax, and each one takes a help argument, so the extension is usable without reading source.

The audience is Windows kernel developers, security researchers and anyone trying to answer a question about token state in a specific process on a system they control.

getps shows the token pointer next to the process, not just the name

The list command is the one that shows the extension's value, because the output is not a process list you would get from task manager. It shows the kernel addresses.

0: kd> !getps

     PID        nt!_EPROCESS nt!_SEP_TOKEN_PRIVILEGES Process Name
======== =================== ======================== ============
       0 0xfffff805`81233630      0x00000000`00000000 Idle
       4 0xffffd60f`ec068380      0xffffaf00`cec07a40 System
      68 0xffffd60f`f1780480      0xffffaf00`d3b290a0 svchost.exe
     580 0xffffd60f`efdc0080      0xffffaf00`d2266630 winlogon.exe

Four columns: the process identifier, the address of the EPROCESS structure, the address of the token privileges structure, and the process name. Those two addresses are what a researcher needs, because a privilege investigation almost always starts from a specific token structure in memory, and a process name alone is not an address.

The output can be filtered by process name, and the filtering behaviour is specified: forward matching, case insensitive. So a filter of micro returns the MicrosoftEdge processes listed in the documentation, with their own EPROCESS and token addresses.

That last point is a small usability decision worth noting. Forward matching rather than substring matching means the filter behaves like a prefix, which is what you want when you are narrowing a list rather than searching inside a name, and it means the query stays cheap as the system has more processes.

The privilege listing command, !getpriv, works on a specific process and is the natural companion to this one.

Ten escalation variants over a deliberately vulnerable driver

The KernelWritePoCs directory is a catalogue of privilege escalation proof of concepts, and its stated purpose is to investigate how attackers abuse an arbitrary kernel write vulnerability. All of them are written for the HackSys Extreme Vulnerable Driver, which exists to be exploited, and most of them use a token privilege to reach the SYSTEM integrity level.

The catalogue is organised by the privilege involved, and each entry names the technique it uses at the final stage. CreateAssignTokenVariant uses SeCreateTokenPrivilege and SeAssignPrimaryTokenPrivilege, CreateImpersonateTokenVariant uses SeCreateTokenPrivilege and SeImpersonatePrivilege, and CreateTokenVariant uses SeCreateTokenPrivilege alone. SecondaryLogonVariant combines SeCreateTokenPrivilege and SeImpersonatePrivilege and uses the secondary logon service at the final stage.

Two entries are about debugging privileges. DebugInjectionVariant uses SeDebugPrivilege and injects code into winlogon.exe, while DebugUpdateProcVariant uses the same privilege and creates a SYSTEM process from winlogon.exe with the UpdateProcThreadAttribute API.

Two are about ownership and service configuration. RestoreServiceModificationVariant uses SeRestorePrivilege and works with the HijackShellLib library in the same directory, and TakeOwnershipServiceModificationVariant uses SeTakeOwnershipPrivilege with the same helper.

The last two are about the TCB privilege. TcbS4uAssignTokenVariant uses SeTcbPrivilege to get a System mandatory level shell from a medium mandatory level, and TcbS4uImpersonationVariant uses the same privilege for thread impersonation with an S4U logon, which the documentation notes does not reach high or system integrity level.

The test matrix is stated plainly: tested on Windows 10 version 1809 and 1903, and the note says they should theoretically work on most of Windows 10. That word theoretically is doing real work, and it is the honest reading of a set of exploits tied to a specific driver and specific kernel internals.

The repository is a workbench of small projects, not one tool

PrivFu is organised as a set of sibling projects, and the directory listing reads like a table of contents for Windows privilege research.

Alongside ArtsOfGetSystem, which covers how to get system privileges from a high integrity level shell, and KernelWritePoCs, there is PrivEditor, PrivilegedOperations, S4uDelegator, SwitchPriv, TokenDump, TokenAssignor, TrustExec, UserRightsUtil, PrivMan and PowerOfTcb.

The names describe the surface area of Windows access control research. A token dumper, a token assignor, a switch for privilege state, a trust executor, a utility for user rights, a delegator for S4U logons, an editor for privileges, and a manager for privileges. Each is a separate directory with its own project, which means each is a small self-contained experiment rather than one growing application.

That structure has an obvious advantage for a research repository. You can pick up the one tool that answers your question and ignore the rest, and you can read a single directory without first understanding a shared framework, because there does not appear to be one. The cost is duplication across the directories, and the absence of a common build or test story, which is a common property of repositories that grow by accretion.

The primary language is C#, and the PrivEditor project is a native kernel mode extension rather than a managed tool, which is why its build output is a DLL loaded with the debugger's .load command and why the documentation warns about build configuration.

Build Release, then load it into a kernel session

The project description of the extension is short, and it contains one warning worth repeating: in some environments the Debug build does not work, and the Release build is preferred.

That warning is specific enough to be useful. A kernel mode extension is loaded into the debugger that is attached to the target machine, and the usual reasons a Debug build behaves differently from a Release build, optimisation and debug information, are exactly the reasons a kernel component can misbehave.

The load command in the documentation shows a path of the form C:\dev\PrivEditor\x64\Release\PrivEditor.dll, loaded with the.load command at the kd prompt, which is the WinDbg kernel debugger prompt. The x64 and Release components of that path are the visible reminders of the architecture and configuration the project expects.

Once loaded, the extension prints its banner and its command list, and every command takes help as an argument, so the workflow is self documenting.

The obvious practical point is where this has to run. A kernel debugger attaches to a live system, so the environment is a lab machine, a virtual machine you can afford to break, or a crash dump. The escalation proof of concepts add a second requirement on top of that, because they are written against the HackSys Extreme Vulnerable Driver, which has to be installed and loaded for them to do anything.

Why a debugger extension rather than a userspace tool

There is a real alternative here, and the project points at it: Priv2Admin, the repository by Grzegorz Tworek that it names as a notable example of token privilege abuse research. There are also plenty of general approaches to token manipulation that do not involve a kernel debugger at all.

The difference in approach is the point worth understanding. A userspace path works with the token through the operating system's own interfaces, which means it runs as a normal process on a running system, and it is subject to whatever the operating system allows that process to do. A kernel debugger extension operates inside the kernel, with the debugger attached, and it reaches the token structures directly, which means it can show and change state that a userspace tool cannot see, and it can act on a system you are already debugging rather than one you are attacking.

That is why the extension form suits investigation. If the question is which privileges a token holds and which of them are enabled, the address columns in the getps output and the direct token access in getpriv answer it with no ambiguity about what the operating system would have allowed.

The other half of the repository sits on the other side of that line. The proof of concepts are userspace programs, and their whole point is to take a kernel write vulnerability and use it to reach SYSTEM, which is offensive work that belongs in a lab and is useful to defenders because it shows what the abuse path looks like.

BSD-3-Clause, no releases, and a repository still in motion

The licence is BSD-3-Clause, which is a permissive grant with a mild attribution requirement and no copyleft obligation. For a research codebase that other people will read, copy and adapt, that is a sensible choice, and it is the kind of licence that makes a proof of concept acceptable to include in a course or a detection write-up.

There are no GitHub releases, which fits a repository of this kind. There is nothing to version as a binary artefact, and the individual projects inside it are developed independently. The last push was on 2026-09-28, and the repository is not archived, so the work is current rather than abandoned.

The project also keeps an acknowledgements section and a reference section, and it is careful about attribution for the work it builds on, naming the author of Priv2Admin as related work rather than as a dependency. The KernelWritePoCs documentation links the HijackShellLib library used by two of the variants, which is the sort of cross reference that tells you a proof of concept is not self contained.

One limitation is worth stating because it is not obvious from the directory names. The proof of concepts are written for a specific vulnerable driver and for the Windows 10 builds named in the documentation, so their portability to current Windows releases is a research question rather than a stated guarantee, and the privilege names they depend on, SeTcbPrivilege and SeDebugPrivilege among them, are exactly the ones that a modern hardened configuration restricts.

Editorial conclusion

Adopt PrivFu if you are researching Windows internals on a lab machine, debugging why a token privilege is or is not present, or building detection and hardening tests around privilege abuse, and you are comfortable in a kernel debugger. Do not adopt it as a product component or a deployment tool, since the extension needs a kernel debugging session and the proof of concepts are written against a deliberately vulnerable driver, and do not run the escalation variants on a machine with real credentials. Before you start, build PrivEditor in Release configuration as the project warns that the Debug build does not work in some environments, load the DLL with `.load` inside WinDbg, and confirm the target is an isolated test system with the HackSys Extreme Vulnerable Driver installed.

Frequently asked questions

Official sources

1. daem0nc0re/PrivFu on GitHub
2. Issues
3. License: BSD-3-Clause
4. README