NtWarden: a Windows internals viewer with a kernel mode tab

Four components, and the driver is the one that changes the risk

NtWarden is a C++ project whose README describes it as a Windows system inspection tool built on ImGui and DirectX 11, covering processes, services, network and kernel internals, locally or over the network.

The architecture is four parts. NtWarden is the GUI application, WinSys is a static library for process, service and network enumeration, KWinSys is the kernel driver, and WinSysServer is a headless TCP server for remote inspection. The split matters because most of the tool works without the driver. User mode stuff, meaning processes, services and network, works without it, and only the kernel tabs need KWinSys loaded on the target.

The author is unusually direct about the caveats. The README states that parts of the project were vibe coded with AI assistance so it might have some bugs, and that the kernel driver should only be installed in a Test VM for research purposes. That warning is in the top of the readme rather than buried, and it is the right frame for the whole tool: this is a research instrument for a lab, not a utility to run on a production workstation.

The project is MIT licensed, and the repository carries a vcpkg.json for dependency management alongside the solution file, the four source directories and a screenshots folder.

The user mode tabs cover the usual enumeration surface

The user mode half of the interface is broad, and each tab is a distinct Windows subsystem rather than a variant of the same view.

Processes shows a process list with a tree view, handles, threads, memory regions and modules. Performance draws real time CPU, RAM, GPU and network usage graphs, and the graphs can be overlaid on top of other tasks, which is the kind of detail that only appears in a tool someone actually used while investigating a machine. Services enumerates services with status, start type and binary path. Under Network there are Connections with the owning process and remote endpoints for TCP and UDP, Root Certificates listing the trusted root CA store with subject, issuer and thumbprint, and NDIS for adapter information including driver, MAC, speed and media type.

Then there are the tabs that make it a research tool rather than a task manager. ETW lists active trace sessions and registered providers. IPC lists RPC endpoints and named pipes. Object Manager browses the kernel object namespace, its directories, symlinks and devices. Registry is a key and value browser, and Symbols shows user mode symbol loading status. The Logger tab pulls kernel driver debug logs and user mode GUI logs into one place.

That Object Manager and IPC pairing is the combination that makes the tool useful during malware triage, because an injected process often leaves a named pipe or a section object behind, and neither is obvious from a process list.

The kernel tab reads things most tools leave to other tools

Switching to kernel mode requires the driver, and the tab list is where the project's real coverage shows.

Process Objects gives EPROCESS enumeration with hidden process detection through cross referencing. Modules lists loaded kernel drivers with base, size and path, along with a LolDrivers check. Callbacks covers kernel callbacks for process, thread, image, registry, object and power, with integrity checks, and SSDT lists entries with owner and hook detection. Symbols handles kernel symbol resolution and PDB loading, and Kernel Pool shows big pool allocations and pool tag statistics.

Then the parts that let you change things: Memory R/W reads and writes kernel memory by address, and Timers shows per CPU interrupt and DPC counters. Filter lists minifilter drivers with altitude and instance info, which is the quickest way to see what is filtering your filesystem. Descriptor Tables lists GDT and IDT entries, IRP Dispatch shows the IRP dispatch table for any driver with handler addresses and owner module, and WFP lists callout drivers and filters.

The security posture tabs are the ones that answer the questions a defender actually asks. DSE Status shows Driver Signature Enforcement state, CI Policy shows the Code Integrity policy and enforcement level, Kernel Integrity verifies the kernel .text section against the on disk image, and Hypervisor Hooks detects EPT hooks through timing analysis.

Read together, these are the tabs you would otherwise assemble from several separate utilities, which is the tool's value: not that any single check is unique, but that they share a window and a connection.

Analyze Process turns the toolkit into a per process verdict

The right-click Analyze Process action is the part of NtWarden with a different shape from the rest. Instead of listing system state, it runs a set of checks against one process and reports what looks wrong.

The checks are named for the technique they detect. Unbacked Memory looks for private executable regions not backed by any file, which the project labels as a shellcode indicator. Hollowing compares the PEB ImageBase against the PE header ImageBase, so a mismatch stands out. Module Stomping compares in memory .text sections against the disk originals, which is how a process that remapped a legitimate DLL gets caught. Direct Syscalls looks for the syscall instruction, written in the project as the two byte sequence 0F 05, outside ntdll, and Syscall Stubs checks ntdll stub integrity by comparing memory bytes against a clean copy from disk.

User Hooks covers inline hooks, described as JMP and CALL patches, in ntdll and kernel32 among others, and it needs capstone to disassemble the analysed bytes. Tokens checks elevation, integrity level, impersonation and suspicious privileges. Debug Objects reports debug objects and debug ports on the process, Hypervisor runs a CPUID vendor check plus RDTSC and CPUID timing anomalies, Job Objects lists job membership, limits and UI restrictions, and CFG Status reports Control Flow Guard and XFG enforcement state with mitigation flags.

The capstone dependency is worth noting. The hook detection needs a disassembler, so a build without it will have that section reduced to pattern matching rather than real instruction analysis, and the README does not document how to toggle it.

Building means Visual Studio, the WDK and a signed driver

The build is a Visual Studio solution, and the requirements are Visual Studio 2022, Windows SDK 10.0.26100.0 or newer, and the WDK for the kernel driver. The solution contains the four project directories:

NtWarden.sln
├── NtWarden/          # GUI app
├── WinSys/            # Core library (static lib)
├── KWinSys/           # Kernel driver
└── WinSysServer/      # Remote server

Open the solution in Visual Studio, build Release x64, and the output goes to x64/Release/.

The driver is where the friction is. KWinSys needs test signing or a valid signature, and on a test machine that means enabling test signing and rebooting:

# Enable test signing (reboot required)
bcdedit /set testsigning on

# On VMs you may also need
bcdedit /set nointegritychecks on

You run NtWarden as Administrator, and switching to the Kernel Mode tab will auto install and start the driver if it is not already loaded, with manual control available from the Driver menu. That convenience is also the risk: one click in the interface loads a kernel component into the running system, and the README's own instruction to keep the driver inside a test VM is the mitigation.

Release naming in this project is date based, with tags like release-2026.04.28-3-5de4bf7, and the last push was on 2026-04-28.

The remote server speaks a binary protocol with no authentication

WinSysServer is the headless half, and it exists so you can inspect a target machine that has no interactive session, usually a virtual machine, from the GUI running elsewhere.

Two files need to reach the target. WinSysServer.exe from x64/Release/WinSysServer.exe is always needed, and KWinSys.sys from x64/Release/KWinSys/KWinSys.sys is needed only for kernel features.

The server can install the driver and start itself, elevated, on the default port 50002 or a port you choose:

# Auto-install driver + start server (run elevated)
WinSysServer.exe --install              # default port 50002
WinSysServer.exe --install --port 9000  # custom port

# Or install the driver yourself first
sc create KWinSys type= kernel binPath= "C:\path\to\KWinSys.sys"
sc start KWinSys
WinSysServer.exe [--port <port>]        # default: 50002

From the GUI, Remote > Connect takes a target IP and port.

The protocol is a custom binary format over TCP with a 12 byte header carrying MessageType, DataSize and Status. The security posture is stated flatly: no auth, use in isolated lab or VM environments only. That is a real constraint rather than a footnote. A listening socket with no authentication on a shared network hands anyone who can reach the port a view of the target's processes, services, network connections and, with the driver loaded, its kernel state. Keep the port on an isolated segment, or tunnel it, and do not treat the default port as safe because it is unconventional.

A good lab tool with the caveats of a weekend project

The sensible alternative to this toolkit is a stack of single purpose utilities. A process and handle viewer, a service enumerator, a network connection mapper, a root certificate store dump, an ETW session lister, an object namespace browser, a driver list, an SSDT dumper and a syscall stub checker are all available separately, and any of them does its one job with a smaller attack surface than a driver that reads and writes kernel memory.

The difference in approach is consolidation against specialisation. NtWarden puts the whole surface in one window, adds a per process anomaly pass that no single tool above performs in one place, and adds the remote server so the same interface works against a headless target. For a researcher moving between a live machine and a VM, that consolidation is worth a lot.

The cost is the maturity profile. The AI assistance warning in the readme is a real signal that the code has not had the review a driver that can read and write kernel memory would need, and the no authentication protocol is a design choice that only makes sense in a lab. The tool also has no homepage and no support commitment, and the release tags are dated snapshots rather than a semver line, so pinning a version is pinning a date and a commit.

It is the right tool for a researcher on a disposable image, and the wrong tool to hand to a team that needs guarantees.

Editorial conclusion

Adopt NtWarden if you work on Windows internals in a lab and want one interface spanning user mode enumeration, kernel mode visibility and a per process anomaly check, and if you can run it elevated inside a disposable VM with test signing enabled. Do not adopt it if you need a tool with a professional support commitment, a reviewed codebase or a safe default posture, because the project itself warns that parts were AI assisted and may contain bugs, and the kernel driver is meant only for a test VM. Before you run it, build Release x64 in Visual Studio 2022 with the WDK, enable test signing on a throwaway image, and confirm the protocol's lack of authentication keeps the listening port on an isolated network.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mrT4ntr4/NtWarden on GitHub
4. README
5. Releases