Killing a process from a Minifilter Driver

NTDEV
1

Hello all,
I am a complete beginner in terms of Windows driver development, so requesting a verbose response!
I am trying to write a minifilter driver which can kill the calling process in the pre-write callback routine and hence prevents the write operation.
I tried a few things out but nothing is working.
Here is one of the examples of the same.

HANDLE procs;
ZwOpenProcess(procs,DELETE,0,NULL);
NTSTATUS terminateStatus = ZwTerminateProcess(procs, STATUS_SUCCESS);
ZwClose(procs);

I would appreciate any and every help I can get to achieve this task.
Thank you!

2

Prevent the write operation based on what? Are you trying to do some kind of bizarre file protection? Surely there are better ways that don’t require kernel mucking.

3

**Terminating the calling process in kernel mode is A Real Bad IDEA . **

You can prevent a write operation without killing the process. For example you can fail the write operation. Or you could pretend the write operation was successful but not actually write anything.

Anyway, ZwOpenProcess’s first parameter is a pointer to a handle, not a handle. DELETE is not the correct access mask. ‘0’ is not a valid OBJECT_ATTRIBUTE pointer, and you need to identify the process to open using the ClientId parameter.

You don’t have to call ZwOpenProcess at all, ZwCurrentProcess() is the handle for the current process.

Also **terminating the calling process in kernel mode is A Real Bad IDEA **.

4

@Mark_Roddy said:
**Terminating the calling process in kernel mode is A Real Bad IDEA . **

You can prevent a write operation without killing the process. For example you can fail the write operation. Or you could pretend the write operation was successful but not actually write anything.

Anyway, ZwOpenProcess’s first parameter is a pointer to a handle, not a handle. DELETE is not the correct access mask. ‘0’ is not a valid OBJECT_ATTRIBUTE pointer, and you need to identify the process to open using the ClientId parameter.

You don’t have to call ZwOpenProcess at all, ZwCurrentProcess() is the handle for the current process.

Also **terminating the calling process in kernel mode is A Real Bad IDEA **.

Yes, I am preventing the write operation, but I also need to kill the process that started the write operation.
ZwCurrentProcess() worked!! Thank you so much!!

For reference of others, this is what worked for me,

HANDLE procs;
procs = ZwCurrentProcess();
NTSTATUS terminateStatus = ZwTerminateProcess(procs, STATUS_SUCCESS);
ZwClose(procs);

Thank you for the help!

5

Note that writes often occur at APC and ZwTP is supposedly Passive level
only (and likely is).

Dejan.

6

This ‘solution’ is a blue screen or a deadlock waiting to happen. Don’t do this.

If you think you need to terminate the process, queue a work item and do it from a clean stack and make sure that you are not executing in the context of the process that you are trying to terminate - which also means don’t use ZwCurrentProcess. You need a real HANDLE so that you don’t choke when the process dies before you have the chance to kill it. Also make sure to handle the situation where many further IRPs happen before the process dies (you have that problem with your current code too) and don’t try to kill it more than once

7

Better than all of these, take Mark’s suggestion to heart and fail the operations. What is driving the need to kill the process?

If you want to prevent a write, why not just use an ACL that denies write permission?

And if that’s insufficient (explain why), failing the create if the caller requests write permission is much easier and safer than terminating the process.

And if failing the create is insufficient (again, explain why) failing the write operation itself is still easier and safer than killing the process.

8

Failing the create can cause issues for processes that never actually perform a write. Lazily waiting for an actual write to occur is a less invasive approach.

9

@Mark_Roddy said:
Failing the create can cause issues for processes that never actually perform a write. Lazily waiting for an actual write to occur is a less invasive approach.

The OP wants to behead the process. I don’t believe the OP cares about causing issues …

1 Like
10

with all due respect, I don’t think the OP knows what he wants to do.

1 Like
11

@Phil_Barila said:
Better than all of these, take Mark’s suggestion to heart and fail the operations. What is driving the need to kill the process?

If you want to prevent a write, why not just use an ACL that denies write permission?

And if that’s insufficient (explain why), failing the create if the caller requests write permission is much easier and safer than terminating the process.

And if failing the create is insufficient (again, explain why) failing the write operation itself is still easier and safer than killing the process.

I cannot reveal much about the project, but…
The project I am working on considers that a malicious process is running in administrator mode, hence the ACLs can be modified and perform write operations on protected data.
I am failing the write operations already, but I also need to terminate the running malicious process to prevent further damage to the data.

12

@Mark_Roddy said:
Failing the create can cause issues for processes that never actually perform a write. Lazily waiting for an actual write to occur is a less invasive approach.

Yes, I am waiting lazily for a write operation, only then do I fail the write operation and further kill the process.

13

@MBond2 said:
This ‘solution’ is a blue screen or a deadlock waiting to happen. Don’t do this.

If you think you need to terminate the process, queue a work item and do it from a clean stack and make sure that you are not executing in the context of the process that you are trying to terminate - which also means don’t use ZwCurrentProcess. You need a real HANDLE so that you don’t choke when the process dies before you have the chance to kill it. Also make sure to handle the situation where many further IRPs happen before the process dies (you have that problem with your current code too) and don’t try to kill it more than once

How do I achieve this? Could you please point me to some documentation where I can deeply understand such concepts.
I would love to ensure such measures are in place that stop blue screen or deadlock.

14

Can someone also explain WHY exactly is it a bad idea to kill the process from kernel?

15

It is not a bad idea to kill a process from the kernel, it is a bad idea to kill the current process from the kernel. If you want to do this correctly, get the process handle and hand that to a worker thread that kills the process.

1 Like
16

The usually objections about trying to protect the system from administrators apply - its a fools errand - but if you have to decided to ignore them, well, who doesn’t need another ‘security’ product that makes the system more unstable and less secure :wink:

As to why it is a bad idea to kill the current process from KM, think about the stack of the thread calling into your code. What locks is it holding? What locks could it be holding? Where does it need to return to?

You can search the archives of this forum for extensive discussions on both topics

17

@Mark_Roddy said:
It is not a bad idea to kill a process from the kernel, it is a bad idea to kill the current process from the kernel. If you want to do this correctly, get the process handle and hand that to a worker thread that kills the process.

Thank you Mark,
Could you please explain it? :smile:
As per my understanding, I need to create another application that will be responsible for killing the current process.
Or I can create a worker thread in kernel mode itself and kill the process?

18

You can fire up a kernel thread that runs in the system process. Any other process will do.