Process Hacker Can Terminate CIS processes; A Concern?

[Guest]

[metalforlife]

I managed to terminate cfp.exe with Process Hacker. Is that something to worry about?

[panic]

CFP.EXE is the GUI that is used to "talk" to CIS. CMDAGENT.EXE is the service/process underpinning it all. If you like a challenge, try killing it.

Even if CPF.EXE gets killed, CIS's protection is still active, even though you may get reduced or no alerts. A default block will apply in all unswerable alerts.

Cheers,
Ewen :-)

[wj32]

Wow, I'm surprised my software (Process Hacker) got on these forums! I've designed Process Hacker to use its kernel-mode driver (named KProcessHacker) to terminate processes. Basically, when the driver is loaded, it scans for a specific signature in kernel memory to locate an internal Windows function called PsTerminateProcess (PspTerminateProcess on XP). That means KProcessHacker can bypass any hooks on ZwTerminateProcess (which CIS does in fact hook) and terminate any process (as I claim on the website ).

EDIT: Oh and I forgot to say: ALWAYS focus on the mechanism, not the end result. That is, you should care about HOW it's done and not IF it's done.

[Endymion]

Wow, I'm surprised my software (Process Hacker) got on these forums! I've designed Process Hacker to use its kernel-mode driver (named KProcessHacker) to terminate processes. Basically, when the driver is loaded, it scans for a specific signature in kernel memory to locate an internal Windows function called PsTerminateProcess (PspTerminateProcess on XP). That means KProcessHacker can bypass any hooks on ZwTerminateProcess (which CIS does in fact hook) and terminate any process (as I claim on the website ).

EDIT: Oh and I forgot to say: ALWAYS focus on the mechanism, not the end result. That is, you should care about HOW it's done and not IF it's done.

Thanks for pointing out that the termination involves a kernel driver which indeed can be prevented using D+ thus defeating any termination attempts


(Tested on XP and D+ safe mode)

EDIT:  Kernel divers obviously grant many privileges to the applications using them and, as such, users should not carelessly allow them.
          All those who want to use Process Hacker to terminate CIS will have to make an exception and allow the installation of KProcessHacker driver like hinted on the PH website.

[metalforlife]

CFP.EXE is the GUI that is used to "talk" to CIS. CMDAGENT.EXE is the service/process underpinning it all. If you like a challenge, try killing it.

Even if CPF.EXE gets killed, CIS's protection is still active, even though you may get reduced or no alerts. A default block will apply in all unswerable alerts.

Cheers,
Ewen :-)

"cmdagent.exe" is the CIS driver, right? I did not try to terminate it because I was scared that I might have had to reinstall CIS if doing that lead to irreparable damages to CIS or the OS.

Since I have the option "Block all the unknown requests if the application is closed" deselected, if "cfp.exe" gets terminated, CIS protection is completely switched-off until the next reboot. Although the automatic "block all" policy will prove to be an absolutely secure approach in circumstances when a system is under attack, I personally feel that is more of an hassle, in any other situation.

[metalforlife]

Wow, I'm surprised my software (Process Hacker) got on these forums! I've designed Process Hacker to use its kernel-mode driver (named KProcessHacker) to terminate processes. Basically, when the driver is loaded, it scans for a specific signature in kernel memory to locate an internal Windows function called PsTerminateProcess (PspTerminateProcess on XP). That means KProcessHacker can bypass any hooks on ZwTerminateProcess (which CIS does in fact hook) and terminate any process (as I claim on the website ).

EDIT: Oh and I forgot to say: ALWAYS focus on the mechanism, not the end result. That is, you should care about HOW it's done and not IF it's done.

That is too technical an explanation for me to grasp. But, thanks anyway.

[Endymion]

That is too technical an explanation for me to grasp. But, thanks anyway.

The layman explanation is that Defense+ should be used to block the installation of the KProcessHacker driver to prevent any concern.

[metalforlife]

Thanks for pointing out that the termination involves a kernel driver which indeed can be prevented using D+ thus defeating any termination attempts


(Tested on XP and D+ safe mode)

EDIT:  Kernel divers obviously grant many privileges to the applications using them and as such users usually should not carelessy allow them.
          All those who want to use Process Hacker to terminate CIS will have to make an exception and allow the installation of KProcessHacker driver like hinted on the PH website.

Yes, I did install the driver, because I do have a vague understanding of what "driver" and "kernel" mean.

By the way, in your test, did you attempt the termination with the driver installed or without? The alert you get for Process Hacker - accessing the registry key - did you manually add that particular entry to "My Protected Registry Keys", and the alert you got was it when Process Hacker was attempting to terminate cfp.exe? Also, did you try to terminate it with "terminator" from the context menu? Finally, you don't normally block the application from accessing it's own registry keys, it would cripple the application's functioning. That should make your test invalid, shouldn't it?

[wj32]

"cmdagent.exe" is the CIS driver, right? I did not try to terminate it because I was scared that I might have had to reinstall CIS if doing that lead to irreparable damages to CIS or the OS.

Since I have the option "Block all the unknown requests if the application is closed" deselected, if "cfp.exe" gets terminated, CIS protection is completely switched-off until the next reboot. Although the automatic "block all" policy will prove to be an absolutely secure approach in circumstances when a system is under attack, I personally feel that is more of an hassle, in any other situation.

No, cmdagent.exe can be thought of as the master controller for all cfp.exe instances - there can be multiple cfp.exe instances running if more than one user is logged in at one time. If you terminate cmdagent.exe you may have a hard time restarting it, but it will be started again when you reboot.

If cfp.exe is terminated, you can simply start it again by running "COMODO Internet Security". It will restore CIS perfectly.

[wj32]

That is too technical an explanation for me to grasp. But, thanks anyway.

Think of it like this:

To terminate a process, a program must ask Windows to terminate the process via a system call. The system call for terminating processes is called ZwTerminateProcess. Normally, if a program has the right privileges and security permissions it can terminate any process.

When you install CIS, it installs a driver which, when loaded, begins to intercept all requests to terminate processes. If it detects that a program is about to terminate CIS itself, it denies the request ("Access is denied").

KProcessHacker bypasses CIS and directly terminates cfp.exe without being intercepted. It does this using a (dangerous) method - it tries to find an internal Windows function, and calls it.

[wj32]

Yes, I did install the driver, because I do have a vague understanding of what "driver" and "kernel" mean.

By the way, in your test, did you attempt the termination with the driver installed or without? The alert you get for Process Hacker - accessing the registry key - did you manually add that particular entry to "My Protected Registry Keys", and the alert you got was it when Process Hacker was attempting to terminate cfp.exe? Also, did you try to terminate it with "terminator" from the context menu? Finally, you don't normally block the application from accessing it's own registry keys, it would cripple the application's functioning. That should make your test invalid, shouldn't it?

You don't need to use Terminator - "Terminate Process" uses KProcessHacker anyway.

The test is not invalid because installing a driver is a very privileged operation that potentially allows the program to do anything it wants without restriction. In Windows, code can run in two modes: user-mode and kernel-mode. All programs (like Windows Explorer, Firefox, etc.) run in user-mode. Drivers run in kernel-mode. The reason for this is that drivers often need direct access to hardware, and kernel-mode gives them that (user-mode is very restricted - programs cannot touch other programs' memory, for example).

Although malicious software in user-mode is often very dangerous, it can be controlled by security software like CIS. However, once malicious software gains access to kernel-mode (e.g. by installing a driver), it can, with enough programming skill from the author, bypass all restrictions imposed by security software.

The reason Process Hacker is accessing a registry key is because HKLM\System\CurrentControlSet\Services contains a list of drivers (in addition to normal user-mode services)! PH is attempting to install KProcessHacker.

[Endymion]

Layman explanation:

Yes, I did install the driver, because I do have a vague understanding of what "driver" and "kernel" mean.

Anyone willing to make use of Process hacker (PH) as a Security Test should be obviously concerned about the installation of a kernel driver.


Users willing to protect themselves against PH should thus block the following Red alert which is meant for highly suspicious behaviors (Understanding Alerts - Severity Level)

By the way, in your test, did you attempt the termination with the driver installed or without? The alert you get for Process Hacker - accessing the registry key - did you manually add that particular entry to "My Protected Registry Keys", and the alert you got was it when Process Hacker was attempting to terminate cfp.exe? Also, did you try to terminate it with "terminator" from the context menu?

To protect my PC from PH I only needed to deny the above alert which as I explained is meant to prevent the installation of the KProcessHacker driver upon starting the application.

No additional entries are needed for  "My Protected Registry Keys" nor further alert were needed prevent  the termination context menu option of PH.

Finally, you don't normally block the application from accessing it's own registry keys, it would cripple the application's functioning. That should make your test invalid, shouldn't it?

Indeed Proactive security is about crippling application considered malicious.  Besides the above mentioned registry entries are system-wide (thus critical registry entries pertaining Driver/Servces) and are not, in layman terms, PH's own ones.

Applications' own registry settings are those pertaining *\Software\appname\*

[metalforlife]

Thanks for the simple explanations. Now I understand what is happening. Well, somewhat. If I understand correctly, during installation if I allow Process Hacker to install it's driver, Process Hacker adds a registry entry to HKLM\System\CurrentControlSet\Services. So it is this access I am alerted about, right? What I was asking is if CIS will throw up the same alert during Process Hacker's termination, or since Process Hacker has already installed it's driver, it won't need the permission of CIS anymore?

[metalforlife]

Layman explanation:

Users willing to protect themselves against PH should thus block the following Red alert which is meant for highly suspicious behaviors (Understanding Alerts - Severity Level)

To protect my PC from PH I only needed to deny the above alert which as I explained is meant to prevent the installation of the KProcessHacker driver upon starting the application.

This is the answer I was looking for. Basically if I block the access to that registry entry Process Hacker will not be able to load the driver and thus not be able to terminate cfp.exe, am I correct? The thing is I don't get the above mentioned "registry alert" for Process Hacker every time I run it. Do you know what might be the reason?

Indeed Proactive security is about crippling application considered malicious.  Besides the above mentioned registry entries are system-wide (thus critical registry entries partaqining Servces) and are not, in layman terms, PH's own ones.

Applications' own registry settings are those pertaining *\Software\appname\*

That's what I meant, you can apply system wide settings, to which everything will be denied access, unless explicitly specified otherwise. 

[Endymion]

This is the answer I was looking for. Basically if I block the access to that registry entry Process Hacker will not be able to load the driver and thus not be able to terminate cfp.exe, am I correct? The thing is I don't get the above mentioned "registry alert" for Process Hacker every time I run it. Do you know what might be the reason?

The reason is that a kernel driver need to be installed only once.

That's what I meant, you can apply system wide settings, to which everything will be denied access, unless explicitly specified otherwise. 

Thus to prevent the concerns which titled this topic it would be rather appropriate to acknowledge D+ severity ratings and prevent such system-wide changes.

Anyway using custom made settings it is even possible to control what applications can use KProcessHacker driver even though it is already installed, thus preventing unwanted terminations.

[Tags:]