Windows Kernel Exploitation: Lab

Getting in the deeps of the OS

Blog Windows Kernel Exploitation: Lab

| 4 min read

Contact us

This post will be the first of a new series in which we will get deep into Windows Kernel Exploitation. I’ll be using HEVD (HackSys Extreme Vulnerable Driver) as the target and, just as we did with the Vulnserver series, there’s going to be a different articles on the ways to exploit it.

Before dealing with vulnerabilities, we must setup the lab environment first. Kernel exploiting is different than application exploiting. When you are attacking an application, if something goes wrong, you can simply restart it. In kernel mode, you will likely get an infamous blue screen of death BSOD.

This post will guide you to setup a testing lab for kernel debugging on a Windows 10 target machine and finally we will be able to install HEVD driver that will be our kernel space victim.


Unlike common user-land applications, the Windows Kernel is commonly debugged remotely. This is because, as I mentioned earlier, when you mess with kernel memory, you’re likely making the OS unusable. For that, we will setup a testing environment with a target Windows OS system (the debuggee) and some tools in the debugger machine.

The following are the tools needed to setup the environment:

  • WinDBG. We’ll use the version that’s included in the Windows 10 SDK

  • WinDBG dark theme (optional): Because I like fancy debugging

  • Pykd: To run Python scripts on WinDBG. Download here.

  • Windbglib + Mona: Download here

  • Windows 10 1703 (Creators Update): For now, we’d only need the 32 bits version

  • A virtual machine player. I’ll be using VMWare Workstation Player.

  • HackSys Extreme Vulnerable Driver: Our target. We’ll be using the latest stable release (HEVD v3.00 to the date of this post).

  • OSR Driver Loader: To load HEVD into the OS. Download here

With all the requirements in place, we can start setting up our lab, which will be composed of a debugger machine, that will be the host machine from which we will run WinDBG; and the debuggee machine, on which we will install HEVD that will be running as a virtual machine.

Setting up debugger

The first stage is to download and install the Windows 10 SDK. If you want to install only WinDBG, you can choose only the Debugging Tools for Windows option:


Once installed, if you search for windbg on Windows, you should get something like this:

WinDBG dark

The default WinDBG configuration provides a not so friendly UI. However we can use a dark theme for WinDBG (see the Pre-Requisites section). To do that, just download the dark.reg file and install it. You will get a much friendly UI:

WinDBG dark

Next, we need to adjust the Windows symbols resolution. It is done by creating a new environment variable _NT_SYMBOL_PATH with the value srv*, like this:


Now, we need to install our friend mona. To do that, we need to grab the file located here.

That ZIP has two files. The pykd.pyd file should be placed at C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\winext. Now run vcredist_x86.exe and follow the installing instructions.

Now, all that’s left is to download from here and from here and move them to C:\Program Files (x86)\Windows Kits\10\Debuggers\x86.

To check if that worked, load an executable on WinDBG, type .load pykd.pyd and then !py mona. You should see something like this:


With that, we have now debugger machine set.

Setting up the debuggee

Now it’s time to setup our target OS. The first thing is to launch a new virtual machine with a Windows 10 1703 (Creators Update) instance.

It’s recommended to disable Windows Update service to avoid messing with our lab results.

Get started with Fluid Attacks' Ethical Hacking solution right now

With the target machine up an running, it’s time to load HEVD in the system. This is done by copying the and files to this target OS and uncompressed them. Then, we must run OSR Driver Loader (run the one in the WNET → i386 → FRE folder)

OSR Driver Loader

Now browse for the HEVD.sys file, click on Register Service and then Start Service:

Driver Loaded

To check if that went well, open a terminal and type driverquery | findstr HEVD. You should see something like this:

Driver Loaded

Great! To ensure that the HEVD driver is load every time, open a terminal as administrator and run

> sc config HEVD start=system

Driver autostart

Now we must connect our target OS with the debugger. You need to launch a new terminal windows as administrator:


And then you need to enable remote debugging by issuing the following command:

> bcdedit /dbgsettings NET HOSTIP: PORT:50000

You need to change the HOSTIP param with the IP of the debugger machine.

This will return a key that will be used for WinDBG to expect for a connection with that identifier.


In the debugger machine, setup WinDBG to listen for a connection with that key:


Now, we need to make Windows to start in DEBUG mode and restart. To that, we should issue the following command:

> bcdedit /debug ON > shutdown -r -t 0

The target OS will restart and the debugger machine should now get a connection from the target OS:


Great. Now break the execution (Debug → Break) and type .reload to load the debugging symbols:


To check if everything’s working, type x /f nt!Create*Process. This will list all the functions in the NT module that contain Create and Process.

NT Create Process

Now, set a breakpoint in nt!MmCreateProcessAddressSpace and resume execution:


Great! But as we are going to debug HEVD, we must add the debugging symbols to our environment. If you look at the folder HEVD.3.00\driver\vulnerable\x86 you can see several files, including the HEVD.sys driver file and HEVD.pdb. The latter is the file containing the HEVD debugging symbols. To load it on our debugger, follow this steps:

  • Create a folder called C:\projects\hevd\build\driver\vulnerable\x86\HEVD

  • Copy the HEVD.pdb file in that directory.

HEVD symbols

  • On WinDBG, type .reload

  • Type lm m HEVD to check if the HEVD module is loaded.

  • And type x HEVD!* to check if the symbols were successfully added.

HEVD symbols

With that, we can start debugging our target machine’s kernel space!:


In the next post, you can see a short reference of WinDBG commands that we will be using during this process.


This post will help you to setup a working Windows Kernel debugging lab. In the next posts we will be dealing with some theory on Windows Kernel and will start exploiting HEVD.

Subscribe to our blog

Sign up for Fluid Attacks' weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by Robs on Unsplash

Consequential data breaches in the finance sector

Photo by Claudio Schwarz on Unsplash

Is your financial service as secure as you think?

Photo by Brian Kelly on Unsplash

We need you, but we can't give you any money

Photo by Sean Pollock on Unsplash

Data breaches that left their mark on time

Photo by Valery Fedotov on Unsplash

A digital infrastructure issue that many still ignore

Photo by James Orr on Unsplash

Our pick of the hardest challenges for ethical hackers

Photo by Ray Hennessy on Unsplash

Let's rather say a bunch of breaches in a single box

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.