- Sep 7, 2016
- 76
Please provide comments and solutions that are helpful to the author of this topic.
Wave, you must finally accept to work for them, I think Wave@kaspersky.com would be a nice new e-mail !The video you uploaded is not sufficient enough to actually know what is really the cause, however I am going to assume that Process Hacker used it's kernel-mode driver (kprocesshacker.sys) to obtain a handle to the Kaspersky process (via ObOpenObjectByPointer - bypasses the access checks, sadly) and then utilised this for the process suspension. This appears to be the most logical explanation, and in this case it would not be a bug.
Process Hacker would have either enumerated all the threads within the target process and called SuspendThread for each handle of the enumerated threads, or it would have just utilised ZwSuspendProcess (I am not sure but either one), using the acquired handle to the process.
In the case of Process Hacker using it's kernel-mode driver, it would not be a bug, since there is nothing Kaspersky themselves can do to protect their processes from kernel-mode attacks like they can with user-mode attacks - especially on x64 systems due to the additional limitations being brought in by Microsoft - and once an attacker gains kernel-mode code execution, it's game over for the most cases.
However, as I said previously, the video is not sufficient enough to know what is really the cause... Therefore, it could just be a bug of the process protection not working correctly (e.g. not registering due to a problem).
Please follow the steps I've laid out below:
1. Check if the Process Hacker service has been created (and is running) when you perform the suspend attack - let me know if it is.
2. Open up Task Manager and attempt to terminate the same process you demonstrated the suspend attack for within this video - does it cause Access Denied (0xC0000022) or does it successfully terminate?
3. If step 1 is a no and step 2 is a success then please reboot the system and see if the results are the same.
Let me know, and thank you for your time.
I do not know what you are referring too when you mention about "in the process" protection, please elaborate. I went back and re-read my first response, however I really do not know what you mean.Seems like a bug if they provide protection from other processes.
I doubt that such a protection would be "in the process" as @Wave described it. That would be very silly. This is usually done by a process responsible with intrusion detection feature (which usually makes use of kernel mode) .. although I'm not really that familiar with Kaspersky.
Please follow the steps I've laid out below:
1. Check if the Process Hacker service has been created (and is running) when you perform the suspend attack - let me know if it is.
2. Open up Task Manager and attempt to terminate the same process you demonstrated the suspend attack for within this video - does it cause Access Denied (0xC0000022) or does it successfully terminate?
3. If step 1 is a no and step 2 is a success then please reboot the system and see if the results are the same.
there is nothing Kaspersky themselves can do to protect their processes from kernel-mode attacks like they can with user-mode attacks
The video you uploaded is not sufficient enough to actually know what is really the cause, however I am going to assume that Process Hacker used it's kernel-mode driver (kprocesshacker.sys) to obtain a handle to the Kaspersky process (via ObOpenObjectByPointer - bypasses the access checks, sadly) and then utilised this for the process suspension. This appears to be the most logical explanation, and in this case it would not be a bug.
Process Hacker would have either enumerated all the threads within the target process and called SuspendThread for each handle of the enumerated threads, or it would have just utilised ZwSuspendProcess (I am not sure but either one), using the acquired handle to the process.
In the case of Process Hacker using it's kernel-mode driver, it would not be a bug, since there is nothing Kaspersky themselves can do to protect their processes from kernel-mode attacks like they can with user-mode attacks - especially on x64 systems due to the additional limitations being brought in by Microsoft - and once an attacker gains kernel-mode code execution, it's game over for the most cases.
However, as I said previously, the video is not sufficient enough to know what is really the cause... Therefore, it could just be a bug of the process protection not working correctly (e.g. not registering due to a problem).
Please follow the steps I've laid out below:
1. Check if the Process Hacker service has been created (and is running) when you perform the suspend attack - let me know if it is.
2. Open up Task Manager and attempt to terminate the same process you demonstrated the suspend attack for within this video - does it cause Access Denied (0xC0000022) or does it successfully terminate?
3. If step 1 is a no and step 2 is a success then please reboot the system and see if the results are the same.
Let me know, and thank you for your time.
Your almost 8 minutes long video which you uploaded is useless.hi
thanks
video:
7.45 min
and I had to create an exclusion...not-a-virus:HEUR:RiskTool.Win32.ProcHack.gen
I am going to assume that you already knew that Process Hacker (when running as administrator) was capable of suspending the Kaspersky processes. Try it with the others and it should work too... In fact, it should work for other AV products as well. If Process Hacker is capable of loading that device driver and connecting to it then it can do whatever it wants since it can have the actions performed from kernel-mode, bypassing the security protection being put in place - if all you want is a Like then do not hesitate to ask, I'll give you a Like for all your posts in this thread, better?
Use a portable version??I tried this on Kaspersky 18 Beta it says i have no permission to suspend
The question is, did Process Hacker really try to use it's driver or not? Also, the driver being loaded with the service and the driver actually being utilised are two very different things. As for the Comodo HIPS, did it block the PH driver from being loaded (or block PH user-mode process from talking to the driver)?CIS seems to protect against it quite well with HIPS enabled even after PH driver was loaded. Default settings.