KasperskyHook: system call hooking through a third party hypervisor

Redirecting the syscall entry point instead of patching the kernel

KasperskyHook hooks system calls on Windows by using Kaspersky's hypervisor, and the mechanism is the part worth understanding.

Kaspersky uses its hypervisor when hardware virtualization is supported, as additional protection. It hooks system calls by changing IA32_LSTAR, the IA32 long syscall target MSR, so that it points at its own syscall handler, which the project describes as basically a copy of KiSystemCall64. From that point, system calls are dispatched to Kaspersky's own handlers, and during initialization it builds its own dispatch table.

That is the whole design. Instead of patching the kernel image or writing a detour into ntoskrnl, the hypervisor redirects the entry point for the system call instruction. The handler that receives the calls belongs to the security product, and this project inserts itself into that path.

The project loads two things: klhk.sys, which is Kaspersky's hypervisor module, and a custom driver which interfaces with it to subvert the system and hook system calls. The repository listing shows the same split, with a KasperskyHookDrv/ directory, a KasperskyHookLoader/ directory, and a klhk/ directory holding the module itself.

The author's stated motivation is worth quoting in spirit because it sets expectations. While researching Kaspersky components, he thought it would be an interesting idea to write a custom project that hooks system calls by using Kaspersky's hypervisor, to take a closer look at what it is doing. This is a research tool for reading someone else's product, not a general purpose interception framework.

Building the driver and loading it on bare metal

The build steps are short and assume a Windows kernel development environment.

You download Visual Studio 2019 and the WDK, clone the repository and build the solution. The solution file is KasperskyHook.sln at the root of the repository. The build produces two artefacts, a driver named KasperskyHook.sys and a user mode loader named KasperskyHookLoader.exe.

The deployment step is where the specifics live. The two output files have to be in the same folder, since the loader looks for the driver next to itself, and klhk.sys has to be copied into the Windows drivers directory at \Windows\System32\drivers. Then you execute KasperskyHookLoader.exe.

The loader is not incidental. The troubleshooting section says that the driver reads a registry value called UseHvm, and if it is not present the hypervisor component stays disabled. That value is normally set by the KasperskyHookLoader, and if you write your own loader you have to replicate it.

The project also carries a prominent warning about test mode. To test it you must enable Windows test mode, and if you want to use the project outside test mode you need either your own custom driver loader or to sign the driver. Since this is a kernel driver loaded by the operating system, that is the standard Windows requirement and not an unusual demand, but it does mean the out-of-the-box experience is an unsigned driver on a machine that has been put into a less safe signing state.

Why hvm_init fails and what the driver checks

The troubleshooting section is the most useful part of the README, and it is specific enough to save hours.

If you see the status codes C00000A3 or C000090B coming from kaspersky::hvm_init(), it usually means the hypervisor component of the driver could not start. The causes given are four, and the first two are the usual suspects.

The driver refuses to load inside a virtual machine, so you have to be on a physical machine. Hardware virtualization has to be enabled in the BIOS or UEFI, either VT-x on Intel or AMD-V on AMD. And you have to avoid conflicts with other hypervisors, because Windows Hyper-V, Virtualization-Based Security, or other antivirus software that uses hardware-assisted virtualization can block klhk.sys.

The fourth cause is the one that is unusual. klhk.sys contains a hardcoded offset for ExGetPreviousMode that has to match your specific Windows version. If the pattern check fails, the hypervisor mode will not start, specifically to avoid a crash, and the advice in that case is to upgrade or downgrade the klhk.sys driver to match the build. The troubleshooting points at a GitHub issue for more versions and updates.

The internals the driver checks are also listed, which is unusual to find in a README. It verifies the Windows build number and version, and some older or specific builds are intentionally blocked, with flags such as 0x100, 0x400 or 0x2 getting set. It looks for signatures of other hypervisors by checking CPUID leaves, for example the string VMXh for VMware, Microsoft Hv for Hyper-V, or vendor strings for KVM and VirtualBox. And it reads the UseHvm registry value, which as noted is normally set by the loader.

What the project deliberately does not do

There is a paragraph in the README that changes how this tool should be judged, and it is worth reading twice.

The note says this is not meant to be an easy-to-paste detection-proof project, that the author wrote it for educational purposes, and that no hypervisor-hardening or anti-detection code will be added.

That is a constraint stated up front, and it matters in two directions. It means there is no stealth work here, so a defender scanning a machine will see an unusual driver and an unusual loader and will not have to fight a sophisticated evasion layer. And it means the project is not trying to be a general purpose system call interception toolkit that you could point at anything you like.

The nature of the mechanism also explains the limitation. Because the interception happens through Kaspersky's own hypervisor, the project depends on Kaspersky's component being present and loadable on the machine. It is not a self-contained implementation of hypervisor-level interception. You need a driver that a security vendor wrote for its own purposes, and a Windows build that the shipped offset matches, and a machine where no other hypervisor is claiming the hardware.

So the realistic use is a controlled research environment, on a physical machine, on a matching Windows build, with the other virtualisation features turned off. The demo.gif at the root of the repository shows the thing running.

Where this sits in the research landscape

It helps to be clear about what kind of tool this is, because the name is not much of a guide.

System call hooking on Windows is normally done by patching the system service table or by detouring functions in ntoskrnl, both of which are things endpoint protection products look for. Doing it through a hypervisor changes the layer. The system call entry point in the MSR is redirected before the kernel ever sees it, and the hypervisor is below the operating system entirely, which means the interception happens in a component that the operating system cannot easily reason about.

What that buys a researcher is visibility into what a security product does with every system call, which is genuinely hard to obtain otherwise. You can watch the dispatch table the product builds, and the product's own handler is the thing doing the dispatch, so the behaviour under study is the real behaviour rather than a reconstruction.

What it costs is the constraints listed above. This approach is heavyweight in every sense. It needs a hypervisor, it needs a specific Windows build, it needs a bare metal machine, and it needs the cooperation of a third party's driver. A more conventional hook would be easier to set up and much easier to maintain, but it would not tell you what the security product is doing at that level.

For a project whose stated purpose is to look closely at one specific vendor's hypervisor component, the heavyweight approach is the point rather than an accident.

Licence, repository layout, and the state of the record

The licence is MIT, with a LICENSE file at the repository root, which is a permissive choice for a kernel research project and lets anyone read, modify and study the driver source.

The repository is small. The top level contains .gitattributes, .gitignore, the KasperskyHook.sln solution, the KasperskyHookDrv/ directory for the driver, the KasperskyHookLoader/ directory for the user mode loader, the klhk/ directory holding the Kaspersky hypervisor module, the README, the demo.gif, and the LICENSE. There is no CI configuration, no test suite, no issue templates, and no separate documentation beyond the README.

The build tooling is pinned to a specific generation, Visual Studio 2019 and the WDK, which is worth noting for anyone trying this on a current machine. The WDK link in the readme points at the Microsoft documentation for driver downloads rather than at a specific version, so the exact combination you end up with is up to you.

On the state of the record, the repository is not archived, but the last push was on 2026-04-02, which is more than six months before this review, and there are no GitHub releases. The project should therefore be treated as a snapshot of the author's research rather than a maintained tool. The troubleshooting advice to try a newer klhk.sys and the pointer to issue 4 for more driver versions both assume someone is still collecting them, and that is worth confirming before you spend a weekend on it.

The demo.gif is the fastest way to see what a successful run looks like, and it costs one request.

Editorial conclusion

KasperskyHook is a good pick for a kernel researcher who wants to observe what a commercial security product does at the system call boundary, because the mechanism is genuine hypervisor level interception rather than an inline hook, and the troubleshooting notes are specific enough to get it running; it is the wrong pick if you need something that works on a machine with Hyper-V or VBS enabled, since the driver refuses to load alongside another hypervisor, and before you try it you should read the signing warning, because the project only loads unsigned in test mode and the alternative is to sign the driver.

Frequently asked questions

Official sources

1. iPower/KasperskyHook on GitHub
2. Issues
3. License: MIT
4. README