You probably forgot that Process Hacker is not a rogue application. It is an application that allows someone to test his or her security apparatus. How can you really test a security apparatus if you do not allow the testing application to be fully loaded. If, for the sake of argument, Process Hacker was a piece of malware I would not even have allowed it to run, of course. Your screenshots of D+ blocking Process Hacker is beside the point.
I would consider success for CIS if it had blocked Process Hacker even after being fully loaded like Outpost Security Suite 2009 did. Please read reply #10. OSS 2009 did successfully prevented its core process from being terminated even when Process Hacker was fully loaded.
You stated also that: “There can’t be protection anymore once a kernel mode driver is loaded.” Well that is not true at least with respect to OSS 2009. Process Hacker kernel mode driver was indeed fully loaded and yet it could not terminate OSS 2009 core process. That is exactly the same thing I want CIS to do.
I was unaware of this thread until last night, consequently, it is not old to me ;D. However, I still have the same question what is being done about it? Are the engineers of Comodo still working on a solution?
Allowing a driver to be loaded mean that the driver will be able to obtain the same privileges/rights of the security software drivers.
As Process hacker developer noted, it would be possible to bypass any security using kernel drivers thus prevention ought to be carried by denying those drivers to be installed/loaded.
Whenever some other app may attempt to restart itself it is likely that a driver might be used to prevent this backup mechanism from occurring.
Though adding \Device\KprocessHacker to My protected files will provide a way to prevent termination, in order to use D+ properly it is important to be aware that driver install/loading should not be overlooked.
Indeed like for a termination driver it would unreasonable to allow a kernel rootkit and expect the system to be protected and this is the reason HIPSes focus on preventing these attempts…
It’s not important. I guess with little modifying of Process Hackers driver it could also kill OSS.
The weakness of CIS lies rather in its warning pop ups than in theoretically passing almost all leaktest like dangers. A pop up like services.exe or processhacker.exe wants to create registry keys bla bla is totally wrong for novice users. Kaspersky IS does it how it should be with red warning pop ups that explain what exactly happens and that KIS can’t control the application’s activity anymore once the driver is loaded.
Yes indeed and it is not only that, when I Tried Process Hacker Terminator OSS core process did prevail. Also in order for me to make sure, I used regtest from Ghost Security. The first test was trying to modify some registry keys and I couldn’t just like CIS in default deny mode, OSS did successfully defended the system. The only exception was that OSS core process was still alive.
Thus far here are the applications that I have tested with Hacker Process:
CIS 3.10
OA Free 3.5
OSS 2009
Results:
CIS 3.10
All CIS processes were killed; However, CIS went to a default deny mode and successfully defended the system. I went to PCflank in order to test my ports and all of them were still stealth and I also perfromed regtest from Ghost security and I was not even able to run it. CIS successfully defended the system.
OA Free 3.5
OA free did put up a fight. Nonetheless, all its proccesses succombed to Process Hacker. My ports were not stealth anymore once OA processes were killed. I ran as well regtest and I was able to successfully modify some registry entries. But at the booting process OA caught the regtest and asked to delete it, and I did.
OSS 2009
OSS 2009 successfuly defended at least its core process, not the gui. In the end OSS 2009 core process prevailed and all my ports were still stealth and I was not able to run regtest.
OSS 2009 was the only security software that I have tested thus far to successfully defended its core process without my system being compromised.
Though restarting acs.exe to keep it alive would be pointless since that OSS 2009 core process was killed (and thereafter restarted unlike the OSS gui), wasn’t it?
No you’ve got it wrong. I did not restart it nor was the computer rebooted, the process itself restarted immediately and brought itself back to life on its own with no intervention whatsoever from me. As a matter of fact the point the test was to terminate all of OSS 2009 processes. The gui went dead while the core process was alive and well.
My very first post on this thread was to eventually ask for help. So in order to see what I’m talking about, please download virtualbox and perform the test yourself with OSS 2009 in order to verify my findings. That’s what I wanted to do in the first place, to compare my results with someone else, whether they could be similar or different.
I guess you totally missed the point: Using a driver Proces hacker was able to kill OSS2009 core process and its gui.
Whenever acs.exe core process came “back to life” is irrelevant as this provides no protection against what a Kernel driver could do.
Using a driver to test termination would be not much different to use a driver to terminate and prevent the restart of those processes using another driver function.
FYI since I found your replies confusing, I tested this myself hours ago. I was able to confirm that acs.exe core process was terminated and thereafter restarted with a different PID.
OSS2009 failed miserably to prevent the termination and it would a also fail miserably to restart if the driver included a corresponding restart/loading prevention function (like for terminate & block feature available in View active process list) or, for what it matters fail the resurrection, if the driver would continually kill acs.exe to let it RIP (rest in peace) without any intervention whatsoever.
Allowing a driver to be loaded mean that the driver will be able to obtain the same privileges/rights of the security software drivers.
So the ability to terminate OSS2009 core processes comes at no surprise nor it would be surprising to eventually confirm that the the degree of control a driver has would also allow to thwart the automated restarting.
As Process hacker developer noted, it would be possible to bypass any security using kernel drivers thus prevention/protection ought to be carried by denying those drivers to be installed/loaded.
Whereas a kernel driver was actually involved,“back to life” restarting would be a red herring.
Moreover it is pointless to allow a kernel driver to test “self protection” because the “protection” in itself mean to prevent such drivers in the first place.
A malicious driver could not only be able to terminate any security but also prevent the restart and carry additional malicious actions with high privileges (unlike the Ghost regtest ring3 usermode PoC previously mentioned)
That’s why in order to use D+ properly, members should be advised to be aware that driver install should not be overlooked.
It should be obvious that, like for a termination driver, it would unreasonable to allow the installation of a kernel rootkitdriver and expect the system to be protected and this is the reason HIPSes focus on preventing these installation attempts…
…and there is no joke or mayday that could possibly provide a different notion and drift away from the big picture.
The realtime protection carried by security softwares is meant to watch over usermode unprivileged applications actions and not drivers. this is why there could be alerts when an usermode application attempt to install a driver but not when a driver carry some action.
Self Protection tests ought to be carried using unprivileged (without kernel drivers) applications in order to verify that security software do make use of high privileged code (using drivers) to protect the system or else usermode PoCs could be able to thwart the protection without using any driver.
Thanks for all the information that you have provided; however, once again you’ve got it wrong. The only way I knew that OSS 2009 core process was not killed was because I tested it just like I did for CIS and OA free. I went to PCFlank and also performed the regtest from ghost security. The results were that all my ports were still stealth and regtest could not perform any registry modifications, to me that’s success.
OSS 2009 core process protected my system just like CIS did when CIS loaded in kernel. OA free did not protect me though once its processes were killed. In the end my intention and my goals were and still are to improve CIS by reporting what could be a major flaw. To me it is critical to fix this; CIS must be able to protect its processes better. That is all.
PS: Nothing is impossible in life, you just have not thought of a way to accomplish something. I guessed the prehistoric man was saying to himself that it is impossible to go to the moon. And now men are thinking to go to Mars and beyond. Impossible? Of course not.
Once again you missed the point. It doesn’t matter how many “lives” OSS core process got as using a driver based approach it would be possible to disable it for good and have it fail whatsoever test.
I’m not sure how anybody could argue about better protection either considering that Killing OSS 2009 core process could be continually repeated to prevent it from running using a similar driver based approach.
In the end the only flaw would seemingly be the way you approached Process hacker driver based termination and regarded it as any usermode termination test.
More over nothing is apparently impossible by words alone…
Feel free to let anybody know whenever OSS2009 will be able to prevent the termination carried using a kernel driver without actually needing to come “back to life”.
Let us agree to disagree on this one. The only thing that I can tell you are my findings. I tested a few security software and I published the results, that’s all.
