It is not always true. While Hacker Process Kernel was fully loaded OSS 2009 did protect its core process. Howe could you explain that?
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.
AFAIK you claimed the core process “went back up right away”. Does protect mean restarting that process?
CIS provide a red warning alert too and can also be configured to control the application activity once the driver is loaded. Eventually changing the description would be trivial.
I will test KIS 2010 tonight or tomorrow along with NIS 2010 and see how they will handle Process Hacker. Stay tune
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.
Peace.
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.
Peace.
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?
In the end restarting a killed core component is by no mean a protection against what a Kernel driver could do.
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.
Peace
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.
Peace.
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 rootkit driver 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.
Peace?
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.
Peace.
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.
I already did.
Obviously we disagree. Whenever it the methodology and the comments added to the results.
OSS 2009 is vulnerable to termination carried by means of kernel drivers and if it is terminated it can be prevented to come back to life by means of the same technique as well.
Having a driver to continually repeat the termination wouldn’t be something more unreasonable than assuming it would be appropriate to carry some tests using kernel drivers, wouldn’t it?
If OSS 2009 was actually able to block the termination in the first place coming “back to life” wouldn’t be needed at all.
Is it as simple as this.
The FACT was and still is OSS 2009 core process was not prevented to come back to life. It is certain that it was the intention of Process Hacker to prevent OSS 2009 core process to come back to life, but OSS 2009 defended itself. Termination, to me, is synonymous to kill. If a process is killed or terminated, if I have to stay true to the meaning of the the words kill or terminate, that process cannot come back to life. My understanding of the situation is that Process Hacker attempted to kill or terminate OSS 2009 core process and was not able to do even after repeated attempts. Isn’t that success to you? It is to me.
It looks like your understanding of the situation rely on semantic but neglect to properly address the kernel driver approaches involved.
It was your call to use an application that rely on a kernel driver and please be aware that, like with View active process list “terminate and block”, some other application+driver could also prevent in one shot the “back to life” you wish to held in account.
Though if you wish to simulate what would happen with a similar driver that endlessly carry the termination then use Process Hacker to continually terminate acs.exe but be aware that applications/drivers can carry termination way more faster than it happens when using mouse clicks or keyboard shortcuts on PH (even faster than an application could possibly display a list of running processes).
It would be plenty possible to thwart OSS 2009 using a variant of the same driver based termination approach in order to endlessly kill any OSS core process and it would be obviously inappropriate for the OP to neglect that so easily whenever PH was not meant to fulfill that purpose.
In the end there is no way to pass a false sense of security for a success…
As it would be possible to bypass any security using kernel drivers, prevention/protection ought to be carried by denying those drivers to be installed/loaded in the first place.
Hopefully nobody will carelessly allow a driver because some process is claimed to come “back to life” because drivers can do way more than terminating something “once”.
Once more you’ve got it wrong. My understanding is not based upon semantic; it is based on a test that I performed. And based on the result of such a test I’ve got to conclude that OSS 2009 core process was not killed nor terminated. Semantic or kidding aside, do you at least agree with that statement?
Peace.
Jaki you might have overlooked that acs.exe PID changed. This obviously happened because it was terminated/killed whenever you could be willing to create a definition for you individual use this might cause unnecessary confusion.
The result of your test prove that it would be possible to thwart OSS 2009 and even prevent the “back to life” you mentioned by endlessly repeating the termination in an automated way through a similar kernel driver based approach.
It is also unlikely that between a termination and a “back to life” the system would be protected. Nor that it matters since a kernel drivers could not be limited to termination…