KDU is a kernel driver utility for authorized Windows security research that leverages legitimately signed but vulnerable drivers to bypass DSE, map test drivers, and manipulate EPROCESS objects in controlled lab environments.
| Tool | hfiref0x/KDU — Windows kernel driver utility exploiting signed vulnerable drivers (BYOVD) for kernel exploration and research |
| Category | Windows kernel research / privilege escalation tooling (C, MIT license, 2756 stars) |
| Primary Use | Exploring the Windows kernel without a local debugger: bypassing DSE, mapping specially built drivers, downgrading PPL protections, and dumping process memory during authorized testing |
| Safe Use | Intended for kernel-security education and authorized assessments in virtualized lab machines only; the author explicitly states it is not designed to evade antimalware or anti-cheat and recommends VM-only use |
| Telemetry Note | Deliberately does not tamper with MmUnloadedDrivers or PiDDBCacheTable; loading a vulnerable provider driver creates standard service/registry artifacts that EDR and audit tooling can correlate, and lazy AV may flag the binary as hacktool |
hfiref0x/KDU, the Kernel Driver Utility, is one of the most referenced open-source implementations of the BYOVD — bring your own vulnerable driver — technique on Windows. Written in C under an MIT license and hosted at hfiref0x/KDU, it provides a consolidated framework for researchers who need to reach kernel mode on x64 Windows 7 through 11 without attaching a kernel debugger or booting into test-signing mode. The tool's stated purpose is explicitly educational: to offer a simple way to explore the Windows kernel and its components. It requires administrative privilege at runtime, which immediately frames it as a post-compromise research instrument rather than an initial access primitive.
The core mechanism is well documented in the README. KDU ships with a database of known vulnerable — or, as the author calls them, wormhole-by-design — drivers from legitimate hardware-vendor software. Each provider exposes some form of arbitrary kernel memory read/write primitive, which KDU then uses to perform its higher-level operations. The provider list lives in drv64.dll, the drivers database that must sit next to kdu.exe with read/write access, and the full metadata is maintained in Help/providers.md. Selecting a provider is done via -prv ProviderID, and you can enumerate what is available with -list or export the table with -listcsv, optionally writing it to a file for documentation purposes.
KDU consolidates several historically separate capabilities into one binary. It implements a Driver Signature Enforcement overrider comparable to DSEFix via the -dse value command, which writes a user-defined value into the system DSE state flags. It acts as a driver loader akin to TDL/Stryker through -map filename. And it performs protected process hijacking: -ps ProcessID modifies the kernel-mode EPROCESS object of a target process, downgrading whatever protection flags it carries, while -pho ProcessID opens an arbitrary process with full access and optional flags like -pht for threads and -phc/-phe to propagate access to a child process.
The protection-manipulation surface is the most interesting part for researchers studying Windows process protection internals. KDU can launch programs as ProtectedProcessLight-AntiMalware with -pse Commandline or as the higher-privileged ProtectedProcessLight-WinTcb with -psw Commandline. Both work through EPROCESS object modification rather than through documented APIs, making the tool a practical reference for how PPL is enforced structurally in kernel memory. The -dmp ProcessID command rounds out the set by dumping the virtual memory of a given process — a capability that normally requires a signed anti-malware provider to perform against protected targets.
The -map command deserves close reading because its architecture is unconventional and its limitations reveal a lot about how kernel loading actually works. Rather than using the standard kernel loader, KDU overwrites already-loaded modules with shellcode; for most providers it hijacks a third-party signed driver from SysInternals Process Explorer by placing a small loader stub inside its IRP_MJ_DEVICE_CONTROL routine. Shellcode versions V1, V2, and V3 are embedded in the binary, with V3 accepting -drvn and -drvr parameters to control the driver object and registry key names. The result is that the mapped driver executes its DriverEntry outside PsLoadedModulesList entirely.
Those constraints are spelled out honestly in the README, and they matter. Mapped drivers must be specially designed to run driverless: DriverEntry parameters are invalid, there is no SEH support so an exception can BSOD the box, unloading is impossible (DRIVER_OBJECT->DriverUnload must be NULL), and only ntoskrnl imports are resolved automatically. Several Windows primitives are banned by PatchGuard for dynamic code, because callbacks registered from memory outside PsLoadedModulesList can be detected and crash the system. The author even ships a BadRkDemo example tree under Source/Examples/ showing what not to do in kernel code — a genuinely useful pedagogical artifact.
Defenders should study KDU precisely because its artifacts are observable. Notably, the tool does not and will not modify MmUnloadedDrivers or PiDDBCacheTable, two structures commonly scrubbed by malware to hide driver load history. The README is explicit about why: KDU is not designed to circumvent third-party security software or anti-cheats, and those structures may become PatchGuard-protected. That means every provider driver load leaves the ordinary service-creation and registry traces that EDR pipelines ingest, making KDU activity on a monitored host highly visible. The author also warns that lazy AV engines flag the binary as hacktool/malware, which is itself a detection signal worth tuning.
The provider ecosystem KDU draws from is a who's-who of disclosed driver vulnerabilities, and the references section doubles as a curriculum in Windows driver exploit development. The list includes CVE-2019-16098, CVE-2015-2291, CVE-2018-19320, CVE-2019-18845, CVE-2019-8372, CVE-2021-21551 (the Dell dbutil issue), CVE-2022-3699, CVE-2023-41444, CVE-2023-20598 and CVE-2020-12928 on the AMD RyzenMaster side, and recent 2025 additions such as CVE-2025-45737, CVE-2025-7771, and CVE-2025-8061. The tool also links to the LOLDrivers project, cementing its role as a consumer of the living-off-the-land driver corpus that blue teams now track systematically.
The wormhole drivers deserve their own mention: WinIo, WinRing0, PhyMem, MapMem, InpOut, and the Intel NAL driver are described as shipped essentially unmodified inside multiple hardware-vendor products, breaking the OS security model by design. The author links BSOD/CVE generators for these in a separate Misc repository, framed as educational material on how not to write drivers. There is also GenAsio2Unlock, a bundled utility under Source/Utils/ that generates the unlocking resources required to work with the AsIO2 driver family — a reminder that some providers need vendor-specific preconditions before their primitives are reachable.
Building from source is straightforward for anyone with a driver-development toolchain: Microsoft Visual Studio 2019 or later plus the Windows Driver Kit 10, with the full source shipped in-repo. Two invocation examples illustrate the shape of normal research usage: kdu -list to enumerate available providers, and kdu -dmp ProcessID to dump a process's virtual memory in an authorized lab. KDU also borrows well-audited third-party crypto code — tiny-AES-c and a whirlpool implementation — presumably for handling embedded resources, and the changelog tracks years of active maintenance from 2020 through 2026.
Where KDU fits in an authorized workflow is as a kernel-research Swiss Army knife: red teams can use it in agreed-scope engagements to demonstrate the impact of unsigned-code execution once administrative privilege exists, while detection engineers can use it as a controlled generator of BYOVD telemetry for building and validating rules. It is not, and is explicitly not intended to be, an AV or anti-cheat bypass; the README says incompatibilities with such software are the operator's own responsibility. The disclaimer is blunt that KDU can BSOD your machine and that, because it depends on genuinely buggy drivers, virtual machines are the only sane place to run it.
From a defensive-program perspective, KDU's existence is a strong argument for the mitigations Microsoft has been shipping: vulnerable-driver blocklists, HVCI, and driver attestation all directly raise the cost of this exact technique. For security teams, the practical takeaways are to inventory which of the provider drivers exist in the estate, monitor for the service-installation events that accompany their loading, and treat any appearance of kdu.exe or its embedded shellcode patterns as a high-fidelity indicator of hands-on research or testing activity. As an educational artifact, few repositories document the gap between signed-but-vulnerable driver surfaces and kernel code execution as thoroughly as this one does.
hfiref0x/KDU.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.