Question

I am using the ESet antivirus, and recently its GUI front-end egui.exe hung and was taking 50% CPU (i.e. 100% of one core). Amazingly, I found that I cannot kill it, even with debug privilege enabled.

Now I am curious: how do they implement such defense, and is there a way to kill it short of writing a kernel driver?

The egui.exe process runs under a regular user (non-admin), and I try to kill it in various ways using an administrative account. Here’s what I tried.

• you cannot kill it from task manager
• you cannot kill it using pskill
• you cannot kill it using process explorer, nor can you attach a debugger to it

Then I started some programming and found that:

• under non-privileged user you can open it with PROSESS_TERMINATE access, but actual call to TerminateProcess() fails with error 5.

• under admin account you can open it with any access rights you want (after enabling debug privilege of course), but then calls to TerminateProcess(), GetKernelObjectSecurity(), SetKernelObjectSecurity() all fail with error 5.

This definitely points to some kind of fiddling beyond just setting the process DACL, since if Terminate were not in the DACL, you would not be able to open the process with PROCESS_TERMINATE right in the first place. Are they actually intercepting Win32 API calls? If yes, then how? It’s been a while since I did low level system programming, so pardon my ignorance.

Answer 1

If you can get a hold of the “System Virginity Verifier” from Joanna Rutkowska, this should give you a pretty good idea where they implement their hooks. Similar tools (including GMER) can be used to investigate what’s going on in the bowels of the system. It may sound odd, but sometimes AVs use techniques also commonly found in malicious software, i.e. rootkit techniques, in an attempt to protect their software from being fooled.

It sounds like SSDT-Hooking and similar techniques have been used to “protect” the process. My first shot at this would be to suspend all threads of the process. Most such protection mechanisms (of malware and anti-malware alike) trigger only on termination attempts. But once you suspend all the threads (Process Explorer can do that) none of them will be scheduled anymore by the scheduler (leading to no CPU usage).

SSDT (sometimes SDT) stands for System Service Descriptor Table. It’s the table with function addresses of the system services (the number of the system service being the index). When you call something like CreateFile from your Win32 application it will end up in NTDLL calling NtCreateFile (== ZwCreateFile in UM). From there the mechanism (which has changed since Windows 2000/XP) will differ in how it transitions into kernel mode (KM), aka “ring 0”. Anyway, the implementation of NtCreateFile in NTDLL roughly does the following: it moves the index of the system service into a register and then invokes the method that is used to transition to KM (sysenter opcode in newer implementations). Arriving in KM, the handler will check the index, figure out the function address from the SSDT and then call that function. There is some more checking of the UM stack going on here (when you come from UM), but this is the process in simple terms. So when you hook functionality at this level, you can prevent any subsystem, including the Win32 subsystem from doing things. However, this has several problems attached (yours being the least of them). Most implementers do a bad job, which can be often seen in malware, such as the rootkit Sony chose to put on some audio CDs back in 2005. So unhooking is virtually impossible without risking a bug check and several independent pieces of code hooking the same SSDT index will also usually lead to problems due to recklessness on part of the implementers.

So suspending the threads seems a possibility, although this question of course is kind of open-ended (without knowing the details of the ESET driver(s)). If, however, they prevent that as well you should indeed consider switching products. I wager that disadvantages to system stability of such products outweigh the additional “protection” although they (ESET) are going to tell you otherwise.

Another possible method could be to inject code (e.g. via a DLL) and have the process itself call ExitProcess. This also depends on whether or not their hooks allow for this loophole.