Nidhogg: a Windows kernel rootkit for Intel x64, and what it actually ships

What Nidhogg solves, and who it is built for

Nidhogg is a Windows kernel driver with a companion C++ client. The README states the goal plainly: to provide an all-in-one, easy-to-use rootkit with multiple helpful functionalities for operations, and to be easy to integrate with a C2 framework. That sentence defines the audience. This is not an endpoint security product or a general Windows utility. It is a toolkit for people who already work in kernel space and want a single driver that covers the operations they would otherwise write themselves.

The feature list is broad by design. Process hiding and unhiding, process elevation, process protection against kill and dumping, thread hiding and protection, file protection against deletion and overwriting, registry key and value protection and hiding, function patching, a built-in AMSI bypass, an ETW patch, PP/PPL signature modification, shellcode and DLL injection over APC or NtCreateThreadEx, kernel callback listing and removal, module and driver hiding, port hiding, credential dumping, and the Nidhogg Object File format for kernel-mode COFF execution.

That breadth is the point. A red teamer writing a custom driver would implement one or two of these and stop. Nidhogg ships them together behind one client binary. The cost of that breadth is the next few sections: several of these features conflict with Windows integrity mechanisms, and the README says so rather than hiding it.

How the driver and client fit together

The repository is a Visual Studio solution with two main projects. Nidhogg/ is the kernel driver, NidhoggClient/ is the user-mode C++ program that talks to it. The README describes the repository as containing a kernel driver with a C++ program to communicate with it. All the real work happens in the driver; the client is a command surface.

That split matters for how you use it. The client is invoked as NidhoggClient.exe, and the README gives one concrete example: NidhoggClient.exe process hide 3110. The pattern is a category, an action, and an identifier. Running the client with no arguments lists the available commands and their parameters, and the wiki is the reference for the rest. If you are evaluating Nidhogg, that is the fastest way to see the real surface area: build the client, run it bare, and read the output rather than the feature list.

The driver has two loading paths, and they behave differently. The normal path registers a service with sc create and sc start, which lets the driver set up kernel callbacks. The reflective path uses kdmapper, and the README warns that PatchGuard will be triggered if the driver registers callbacks, so under reflective loading the driver registers none. That disables process protection, thread protection and registry operations by default. The same warning says automatic graceful unload of hidden modules and unhooking of callbacks will not work, and that manually unloading hidden modules and unhooking callbacks is the user's responsibility. Failing to do so may lead to system instability or crashes. This is the single most important architectural fact in the project, and it is a design constraint, not a bug.

Building the client and driver, and a first hide command

The README gives two build paths. The client needs Visual Studio 2022 and is built like any other Visual Studio project. The driver needs Visual Studio 2022 plus the Windows Driver Kit, and the repository is cloned with submodules because the solution depends on them.

Start by cloning with submodules, since a plain clone leaves the termcolor and other submodule directories empty and the build will fail.

git clone https://github.com/Idov31/Nidhogg.git --recurse-submodules

Build the solution in Visual Studio 2022 with the WDK installed. The README does not document a command-line build, so treat the IDE build as the supported path.

For a lab machine, the README's driver testing steps are three commands. First enable test signing, then reboot.

bcdedit /set testsigning on

After the reboot, create the kernel service pointing at your built driver and start it. The path in the README is a placeholder; substitute the real location of your Nidhogg.sys.

sc create nidhogg type= kernel binPath= C:\Path\To\Driver\Nidhogg.sys
sc start nidhogg

With the driver running, the client is the interface. The README's example hides a process by PID.

NidhoggClient.exe process hide 3110

What you should see is the process disappearing from the tooling you use to enumerate processes, which is the whole point of the feature. If you want kernel debug output while testing, the README's debugging step is bcdedit /debug on followed by a reboot, after which messages appear in DebugView. Note that the README marks process hiding as a PatchGuard-triggering feature, so expect that risk in the same session.

PatchGuard, VBS and the features that fight Windows

The README separates its features into ones that work and ones that carry known risk, and it does not soften the second group. A caution block names process hiding, file protecting and driver hiding as known to trigger PatchGuard, with the note that you can still use them at your own risk. Kernel Patch Protection is not a bug you can work around quietly; it is designed to catch exactly this kind of modification, and a triggered check typically means a bugcheck.

The Nidhogg Object File feature has its own hard boundary. NOF lets you compile your own kernel-mode code to a COFF file with access to ntoskrnl APIs and syscalls, and the README says Nidhogg's own API is coming in v2.1, so that access does not exist yet. More importantly, the README states NOF is not compatible with Virtualization Based Security because it violates both HVCI and kCFG. On a machine with VBS enabled, that feature is not a degraded option; it is unavailable.

Reflective loading has a third boundary. Because the driver cannot register callbacks under kdmapper without tripping PatchGuard, process protection, thread protection and registry operations are off by default in that mode. If your plan depends on any of those three, reflective loading is the wrong loading path for you. There is no documented switch that turns them back on safely.

The pattern across all three constraints is the same: the features that make Nidhogg interesting are the features that Windows integrity mechanisms are built to detect. That is inherent to the category, not a maturity problem.

Nidhogg Object File, and what happened to NidhoggScripts

NOF is the newest capability and the direction the project is moving. Since v2.0, you can write kernel-mode code, compile it to a COFF file, and execute it in kernel mode through the driver, with access to ntoskrnl and syscalls. The stated plan for v2.1 is to expose Nidhogg's own API to that code, which would let a NOF call back into the rootkit's functions rather than reimplementing them. Until then, a NOF is kernel code with kernel APIs and nothing from Nidhogg itself.

The feature it replaces is worth understanding, because the reasoning is documented. NidhoggScript was a way to run a sequence of Nidhogg commands as a playbook, and initial operations could run a file named out.ndhg from the project root each time the driver started. Both are deprecated in v2.0 and slated for removal in the next major release. The README gives two reasons: hard maintainability and low popularity. That is a candid trade-off note, and it tells you something about the project's priorities. Scripted playbooks were a convenience layer with a maintenance burden; NOF is a lower-level execution primitive with a cleaner boundary. If you built anything on NidhoggScript, the removal is scheduled, and the replacement is not a drop-in: NOF executes compiled kernel code, not a command list.

How Nidhogg compares to a general kernel driver framework

The closest comparison in the same space is a general-purpose kernel driver loader such as kdmapper, which Nidhogg itself uses. The difference in approach is real. kdmapper is a loader: its job is to get an unsigned driver into kernel memory without a service, and it stops there. It has no opinion about what the driver does. Nidhogg is the driver plus the operations plus the client, and it explicitly supports being loaded by kdmapper as one of its two paths.

That makes them complements rather than competitors, and the choice is about what you are building. If you already have your own driver and only need a way to load it, kdmapper is the smaller tool and Nidhogg adds nothing. If you need process hiding, callback enumeration and removal, registry hiding, or injection primitives without writing them from scratch, Nidhogg is the layer above the loader, and you accept its constraints: no callbacks under reflective loading, PatchGuard risk on three features, and no NOF under VBS.

For a defender-side comparison, the README itself points at pe-sieve as the kind of memory scanner that the bypass feature is aimed at. That is a useful framing: Nidhogg exists in relation to detection tooling, and its feature list reads partly as a list of things that tooling looks for. If your interest is detection rather than operation, the README's feature list is a reasonable inventory of kernel-level behaviours worth monitoring, and the callback listing and removal features are the ones that most directly affect visibility.

Licence, maintenance and what an upgrade costs

Nidhogg is GPL-3.0. That is a copyleft licence, and it applies to a kernel driver that is linked into a running Windows system. If you modify the driver and distribute it, the GPL's source-availability terms apply to your version. Integrating Nidhogg into a closed product is not something the licence permits without careful consideration, and this is a question for a lawyer rather than an article. The repository also includes a Nidhogg.yar file, a YARA rule, which is worth knowing about if you are on the detection side.

On maintenance, the facts are concrete. The repository is not archived, and the last push was on 2026-09-26. The most recent release is v2.0.1 from 2026-06-26, following v2.0 in 2026-02-15 and v1.0.1 in 2025-10-03. The README states all features have been fully tested up to Windows 11 25H2, which is a specific claim about coverage rather than a general promise.

Upgrade cost has two components. The first is the scheduled removal of NidhoggScript and initial operations in the next major release, which will break anything depending on out.ndhg or on scripted playbooks. The second is the NOF API arriving in v2.1, which is additive rather than breaking. The README does not document a rollback procedure for a running driver, and it does not document an upgrade path between driver versions. If you run Nidhogg, plan your own unload and recovery steps, because the documentation does not supply them.

Editorial conclusion

Nidhogg belongs in a lab: a VM with testsigning enabled, a snapshot you can throw away, and Windows 10 or 11 on x64. It is the wrong tool for production endpoints, for anyone who cannot rebuild the driver from source, and for anyone who needs a stable long-running agent, because the README names process hiding, file protecting and driver hiding as PatchGuard-triggering and warns that reflective loading disables callbacks. Before you adopt it, verify three things yourself: that your build of the driver loads under your Windows build with testsigning on, that the client commands you plan to use appear in NidhoggClient.exe output, and that you have a documented way to unload hidden modules, since the README puts that responsibility on the user under reflective loading.

Frequently asked questions

Official sources

1. Idov31/Nidhogg on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases