Tutorial Why Antivirus software may use Kernel Mode drivers

  • Thread starter Deleted member 21043
  • Start date
Hello everyone,

Earlier today @Tony Cole asked me a question relating to Antivirus software and Kernel Mode drivers. Instead of responding directly as a post on one of my threads, I decided to keep this as a separate thread altogether considering if someone see's this separate thread they may also be interested in what a kernel mode driver is and why Antivirus software like them.

First up, the term "kernel mode" represents ring0. There are 4 rings in the OS.
The first ring is ring0. This is where the code to the kernel mode drivers gets loaded (since we are talking about drivers).
The second ring is ring1. After ring1 is ring2. An example of a program which makes use of Ring1 is VirtualBox, it loads the guest kernel code there.
The last ring is ring3. Ring3 is where user-mode applications are executed. For example, if you opened up Google Chrome or Skype, they would be running in Ring3.

When a crash occurs in user-mode (ring3), only that application which has/is crashing will have an affect. Whereas, when there is a crash in e.g. a kernel mode driver (ring0), it will result in the whole system crashing (BSOD - Blue Screen of Death). This is the disadvantage of kernel mode, but what do you expect? It's running at the root access of the OS.

The drivers run in the Windows Service.

Now I got that little bit of theory out the way, I can start going into why Antivirus software like to use kernel-mode drivers.

Antivirus developers love kernel-mode. But why? Well there are many priveleges to kernel-mode. My first example will be about Self Defence.

Self Defence is a very important thing in the Antivirus industry. It would not be good if the Antivirus was attacked, leaving all the protection disabled. In some cases, the malicious software may not just disable the protection of the Antivirus product, but actually attempt to uninstall the security software off the system. There are other ways an Antivirus product may be attacked, such as with the Registry. Malicious software may not just try to do things like terminate the Antivirus processes, get rid of the Antivirus services and the actual required files for the Antivirus to work, but may also try to attack the Registry keys.

So how may an Antivirus product protect against malicious software?
Well, on 32-bit systems they may resort to patching up the kernel. On some Antivirus software you may notice it's easier to attack them on 64-bit systems than 32-bit systems (I'll move onto why this is in a minute). There is something called the SSDT, and this stands for the System Service Dispatch Table. On a 32-bit system, Antivirus software may use SSDT hooking (System Service Dispatch Table hooking).

Using SSDT hooking, the Antivirus software can prevent attacks based on the APIs being called by the malicious software. I will explain:

An Antivirus product may hook the WinAPI function "NtTerminateProcess" which is used quite commonly to terminate a process. There is also "ZwTerminateProcess". NtTerminateProcess is used in user-mode, and ZwTerminateProcess is used in kernel-mode. Although, you can still call ZwTerminateProcess API from user-mode.

In the SSDT hook to this WinAPI function, in the hook it can be made so you can obtain which is the target process from the API call. If it is one of the processes belonging to the Antivirus software, then it may do the following:

Regardless if the user is a standard user account or Administrator, they will receive the "Access Denied" error message as response. You may have once experienced this when trying to terminate a process in Task Manager. If so, now you know why. ;)

On a 64-bit system, Microsoft decided to try to prevent "rogue" driver installations by putting a stop to SSDT hooking. On a 64-bit system, a KM driver can only be loaded if it has a digital signature. There is however a way to do SSDT hooking on 64-bit, but of course for security software this would be unethical in it's own way; and it's something only a malicious software would even attempt.

Without that being said, Administrative permissions would be required for a kernel mode driver to be loaded. This is why Antivirus installers generally require Admin priveleges at some point of the installation procedure (or at the execution of the installer from the start).

Instead, they resolved to things like API/IAT hooking through DLL injection. For self defence, they may inject a DLL into every running process and hook certain functions. With IAT hooking, instead of the original function, it's redirected to the function made. So you may call function A (which is hooked) and then the code in function B is executed instead. That's IAT hooking for you. And if done properly it can be very effective.

So it can be good for self defence.

As well as this, they can be good for things like HIPS/BB. If they are hooking APIs, they may hook APIs which may be used commonly by malicious software. Or watch for certain list of APIs to be used and then detect it.

But that's not all. Kernel-Mode can also be used to monitor process creation and termination. This can be achived by using the callback PsSetCreateProcessNotifyRoutine: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559951(v=vs.85).aspx
That's still not all! They can be used for... Rootkit protection.

For example, a rootkit may use SSDT hooking but may not clean it up when the driver is being unloaded. This means Antivirus software may use a driver in kernel-mode to scan the SSDT and fix any detected hooks.

Since there is a kernel-mode driver, it can attempt to prevent a rootkit infection in the first place by hooking NtLoadDriver and have the user provide consent to the process loading a kernel mode driver (user-mode rootkits do exist, however of course kernel-mode permissions for a rootkit to have are good for them due to what more they can do).

Which brings me to the next example, Process Termination! Yes, that's right. Antivirus software may use attempt to terminate a process from kernel-mode (or suspsend it at least whilst it alerts the user). When I say "suspend it", I am referring to the suspension of the threads of the process; it's impossible to suspend a "process", but you suspend the threads of the process running. Suspending basically makes the whole application temporarily "stop" until the threads are resumed for a quick educative note. So it may suspend the threads of the process whilst it does something like alert the user.

NtSuspendProcess(), NtResumeProcess(), SuspendThread(), ResumeThread(), PsSuspendThread()...

Although termination can be good from user-mode, too.

There is so much that can be done in kernel-mode. Should anyone want any more examples to help them understand, I will be more than happy to provide them! All you have to do is ask me in the comments.

Cheers. ;)
Last edited by a moderator:


New Member
Mar 18, 2015
Kernel drivers are generally required for rootkit detection and removal, especially in the case of stubborn ones. Otherwise it's not really needed (Emsisoft Emergency Kit used to load drivers into a machine, but it no longer does that now).

Deleted member 21043

Kernel drivers are generally required for rootkit detection and removal, especially in the case of stubborn ones. Otherwise it's not really needed (Emsisoft Emergency Kit used to load drivers into a machine, but it no longer does that now).
Emsisoft Emergency Kit is to be used on-demand, not as a real-time product. If it uses drivers, it may not be for the same things that EAM/Another AV product may do.

However, I have just checked. EEK once extracted does have drivers in the directory under the EEK path/bin. The files in that bin folder with the extension "*.sys" are the drivers. (don't worry, fresh download of EEK, all up-to-date).

One driver is for 32-bit systems, another for 64-bit systems.

The drivers in EEK are loaded upon starting Emsisoft Emergency Kit, and are used for the Direct Disk Access Support.

Cheers. ;)


New Member
Mar 18, 2015
It's not visible in my logs due to existing EIS drivers (this is what you get when using EEK on a machine with existing Emsisoft product...)

But thanks. I used to know that EEK drops two drivers (DDA and cleaning driver), but when I review logs on my machine they are not present.


New Member
Apr 21, 2021
Very intretsing .
why iam trying to avoid the av KasperSky on my system by making direct syscalls
the syscall success and the registery edit is Done.
but after it done the process terminated by KasperSky i dont know why ? can some help . for educational purpose