I managed to terminate cfp.exe with Process Hacker. Is that something to worry about?
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.
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 ;D).
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.
[attachment deleted by admin]
“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.
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.
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?
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.
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.
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.
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)
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.
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*
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?
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?
That’s what I meant, you can apply system wide settings, to which everything will be denied access, unless explicitly specified otherwise.
The reason is that a kernel driver need to be installed only once.
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 [i]control[/i] what applications can use KProcessHacker driver even though it is already installed, thus preventing [i]unwanted[/i] terminations.
[attachment deleted by admin]
The reason that CIS doesn’t give you a prompt when you use PH to teminate it is because of the special method I use - I designed it specifically so that it is not intercepted by security software or rootkits.
PS: There is a special exception in CIS. I told you that when a user-mode program wants to teminate a process, it uses ZwTerminateProcess which is intercepted by CIS. However, if a kernel-mode program (like a driver) uses ZwTerminateProcess, CIS just lets it through without checking if CIS itself is about to be terminated. This is because the kernel itself may need to terminate CIS! PH doesn’t use ZwTerminateProcess, however (again, it has its own method), so I’m just telling you this just for the sake of it :).
Or, are you asking why CIS can’t protect against my method? The answer is that in kernel-mode, you can do pretty much anything you want. You simply can’t cover all possible methods of terminating processes.
No, I understood your explanation. I cannot translate the explanation in my own words because my english is quite poor. So it might come across as if I am confused. My problem is I haven’t managed to make CIS alert me about the registry-access even once, that is what is troubling me a bit.
Please extend further as it looks that providing access lists at kernel lever would be more practical than focusing on prevention of kernel drivers. ???
BTW does KProcessHacker driver implement access control to prevent unknown applications to use its services?
of course, CIS or any other HIPS appz. is not meant for stopping that at all, prevention is keyword for you soft. if it isnt installed it cant harm…