Blocking particular process from getting terminated

Hi all,

I’m new to windows driver. So i dont know that much in drivers

I want to ask that is there any way that somehow we can block process from getting killed through kernel mode.
I went through internet found out PsSetCreateProcessNotifyRoutine routine which will add a driver supplied callback routine which will get called every time a process is created or deleted with the boolean value is set to TRUE when process is created and FALSE when process is deleted.

With this routine i will come to know when process is deleted i can even get its loaded image . But can i stop the process from getting killed???

It will be great if someone enlightened me on this…

sorry for english
regards,
Ajit

Why do you need that? What problem are you trying to solve by that?

Currently i’m working on a project. Company i’m working for has this product xyz.which when installs in computer proactively cleans temporary file and do some other work. Then this requirement comes that when the product is running user cant kill process manually. which will not hinder the work.

so can i achieve this from kernel mode???

Stupid feature, in any case. But it’s possible with

http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692(v=vs.85).aspx

Just register for Pre-handle creation and strip the rights (e.g. Terminate) from the handle

On Oct 16, 2014, at 9:00 PM, xxxxx@hotmail.com wrote:

Currently i’m working on a project. Company i’m working for has this product xyz.which when installs in computer proactively cleans temporary file and do some other work. Then this requirement comes that when the product is running user cant kill process manually. which will not hinder the work.

It?s not up to you. It?s my computer, not yours. If I want to kill your process, I have the right to do so.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Frank…

@Tim: yes tim its ur computer .do whatever u want…
this feature is not for end user. Its for enterprise…

> this feature is not for end user. Its for enterprise…

Yes, and it’s their computer and not yours.

If their admin wants to kill the process, then he/she should be allowed to do this.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Yes they will kill process if they want.
denying a computer administrator to terminate a process is wrong, so process self-protection should be avoided.
This is true 99% of the cases, the remaining 1% are those cases when a process is vital for the system infrastructure security such as anti malwares, IPS and IDS. Those kind of softwares have to protect themself from malicious software trying to terminate their services and processes or inject arbitrary code into their executable address space, so that’s when an appropriate protection is vital.

This problem is already solved:

  1. The users in enterprise infrastructure MUST NOT have administrative privilege.
  2. The applications in enterprise infrastructure MUST be installed by an administrator or by remote installation which runs in a privileged context. Users CANNOT kill the installer in such a case.

And the problem with these cases is that about half the stupid firms don’t
provide an appropriate kill switch for the program. I have turned down
requests for being an “expert witness” because a firm thinks their program
is “so important” they don’t provide a way to terminate it. I am not sure
any of the cases really ended in court, but I know some of the situations
the “we will protect our program against anything” were asking where are we
getting the money to pay our programmers after the enterprise customer was
done with them.

Mr Grig has it right, Use administrative privledge, worst case provide a
confirmation dialog to ensure that termination is what is really wanted.
Trying to stop termination is another one of these idiot chases like trying
to complete clean an infected system while it is running, you are not going
to be able anticipate all the potential ways.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, October 17, 2014 8:59 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

Yes they will kill process if they want.
denying a computer administrator to terminate a process is wrong, so process
self-protection should be avoided.
This is true 99% of the cases, the remaining 1% are those cases when a
process is vital for the system infrastructure security such as anti
malwares, IPS and IDS. Those kind of softwares have to protect themself from
malicious software trying to terminate their services and processes or
inject arbitrary code into their executable address space, so that’s when an
appropriate protection is vital.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Use ObRegisterCallback(), its pretty easy & theres tons of sample code and info about it around, just look on a search engine.

After looking I saw its not easy to find via search engine so heres one (of several) links - http://stackoverflow.com/questions/20552300/hook-zwterminateprocess-in-x64-driver-without-ssdt

I guess that your statement may hold true under the condition that user is warned about these features
BEFORE purchasing your product and is allowed to cleanly uninstall it (or explicitly warned of inability to do so).

After all, it does not conflict with Tim’s and Max’s statements in any possible way - indeed, it is user’s computer, and it is his/her/its right to install a product that effectively strips him/her/it of his/her/its right to control his/her/its own machine in the name of the “security”. Such a product is not necessarily bound to be as unattractive to the end users is it may seem to at the first glance. Instead, it may be VERY attractive to some ( just look at Mac users if you don’t believe it - they are ready to spend a night in a queue in order to be among the first ones who had purchased a new upgrade of a product that controls their every move).

However, users just have to be warned - otherwise, you product is nothing more than just a piece of a malware with a high potential of landing its authors in a courtroom…

Anton Bassov

xxxxx@hotmail.com wrote:

This is true 99% of the cases, the remaining 1% are those cases when a process is vital for the system infrastructure security such as anti malwares, IPS and IDS. Those kind of softwares have to protect themself from malicious software trying to terminate their services and processes or inject arbitrary code into their executable address space, so that’s when an appropriate protection is vital.

But the problem is unsolvable. Don’t you see that? Whatever your
process can do, a malicious process can do as well, and can also UNDO.
You can’t make your process bulletproof. It’s impossible. The malware
writers are smarter than you are. Once you have malicious software with
admin or kernel privileges, the game is over, and you have lost. There
is no solution short of reformatting.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> But the problem is unsolvable. Don’t you see that? Whatever your process can do, a malicious

process can do as well, and can also UNDO.

Well, this is just the question of who was the first one to get there…

If you install such a product on a clean machine there will be simply no malicious processes in sight, unless it was user’s choice to allow them to run by installing their binaries. However, if the target machine has been already infected by the time you install your process there is nothing that can be done.

To put it simply, there are 3 security problems - prevention, detection and cleaning. The first one is perfectly solvable at the target system itself as long as it is clean, the second one may be sometimes solvable at the target system as well, and the third one is simply infeasible unless you use some independent installation, rather than a target system itself - you just cannot do anything about the system that has been compromized at the level of its kernel…

Anton Bassov

Thanq @adam, @alex, @tim, @anton, @don for ur comments
I understand ur point of view. But as i said mine is a product company which design product according to clients requirement. If they want in their infrastructure no one should be able to kill any particular exe so then it be. They have their own requirement their own point of view.

Now its upon them if they want some kind of kill switch or not.

but according to me i find this idea intriguing one able to protect their exe from getting terminated by other user…

@anton i completely agree with you (there are people who will buy anything jst in the name of glamour-- Celebrity branding is nothing new – get a reasonably famous person to attach their name to a product, and suddenly $10 product will become $100)

well thanq everyone for ur valuable comments i got what i wanted.

Tim Roberts - Thats an interesting comment, and I generally agree with you. However in this case, the only way I am aware of to remove the process protection is to call ObUnregisterCallback(). Are you implying that a malicious program can call ObUnregisterCallbacks() and remove my protection from outside of my kernel module (.sys), or similar? Thanks.

Assuming the malware has infected the kernel, then even with that protection
there are so many things that can be done to mess up the your program. For
example, the malware can corrupt the executable so it crashes, or gently
modify it so it sleeps forever.

As Tim pointed out, once a system is infected you cannot use that system to
clean itself up. Any belief that you can is a fools errand.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, October 18, 2014 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

Tim Roberts - Thats an interesting comment, and I generally agree with you.
However in this case, the only way I am aware of to remove the process
protection is to call ObUnregisterCallback(). Are you implying that a
malicious program can call ObUnregisterCallbacks() and remove my protection
from outside of my kernel module (.sys), or similar? Thanks.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

First, I agree with you, the malware is going to win 99% of the time as offense is way easier than defense. But for the sake of educational argument (as I’m not very farmiliar with this), let’s assume that the infection has occured after my driver is loaded. The driver protects against file modification via a minifilter FltRegFilter(), and is also protecting against process termination via ObRegisterCallbacks(). There’s also another routine blocking remote threads. The attacker cannot modify any binaries, nor use Read/WriteProcMem(), no TermProc(), no CreateRemoteThread(), no SSDT hooks, etc. Apart from offline attacks - how do you destroy my process?

OK nevermind an attacker can still attach a debugger to my process and make changes in memory.