Terminating a protected process

[reparto]

I searched around for a malware sample that is a persistent process and I am trying to find a way of forcing it to terminate. I have seen this behavior in several AV software and I am trying to figure out how that works.

I have tried two ideas I had but it seems the malware has these covered. I tried to inject code that would call ExitProcess() but it didn't work on the malware (WriteProcessMemory returns 0 even though calling OpenProcess with PROCESS_ALL_ACCESS succeeds).

I also tried to cheat a bit and suspend the threads but the process doesn't seem to respond to SuspendThread() even though no there is no error.

My guesses are that the malware has hooked several WinAPI functions, what can I use to find which functions have been hooked and how would I bypass these hooks?

[bad_brain]

that sounds like a case for gogeta or cats....sooner or later one of them will show up...^^

[reparto]

that sounds like a case for gogeta or cats....sooner or later one of them will show up...^^

Oh ok, as I'm still working on this so I will just add whatever I have found as I find it.

I stumbled across GMER and figured that was what I needed. From GMER I can see that there is a kernel mode driver hooking ZwCreateProcessEx and ObMakeTemporaryObject, I also noticed that every process has a DLL loaded that shouldn't be there.

The DLL exports two functions: InstallHook and UninstallHook. It also imports pretty much all the functions in kernel32.dll which are probably used to hook the functions.

The DLL is also protected by file permissions from the usergroup "Administrators", and if I add myself to the group I still can't make any modifications.

I'm guessing that by hooking ZwCreateProcessEx the malware is able to inject a DLL pre-runtime, the DLL then hooks several functions and is able to intercept any attempts to kill the process.

Chances are that FreeLibrary has been hooked by the injected DLL, this means that I can't load a library that will unload the injected library.

I'm guessing the best way to kill the process it is to hook ZwOpenFile and block access to the DLL, then any processes that are started will not have the DLL injected in them and will be able to kill the malware process.

I think I answered my question myself but I'm not sure if my idea will work, either way I'm going to read about kernel mode drivers.

[reparto]

I just realized that there is a scan button on GMER and it looks like pretty much everything is hooked. I can't check individual functions because the scan causes Virtualbox to crash so until that is fixed I am going to assume that everything has been hooked.

Also, how does GMER get away with terminating protected processes, does it reconstruct the SDT to call the original functions or does it use some other mechanism to bypass kernel hooks?

[Gogeta70]

Well, it's hard to grasp everything the malware is doing, but there may be a way to get a pointer to an unhooked function inside of a dll. Try this:

Code: Select all

HMODULE k32 = GetModuleHandle("kernel32.dll");
MyLoadLibrary = GetProcAddress(k32, "LoadLibrary");

I assume the malware's method of hooking is through modifying the IAT in the dll, so this should bypass that. If they're detouring the functions in the dll, then this won't work. But detouring every function in a dll is a LOT of work, so it's unlikely.

[reparto]

Just before I read your post I attempted mapping kernel32.dll into memory by using CreateFile->CreateFileMapping->ViewMapOfFile and calling functions by calculating offsets of the original functions.

I figured if the IAT was tampered the calculated offsets would be incorrect and so would cause a crash, however the function call succeeded and was blocked.

I did then try your suggestion of using GetProcAddress to get the pointer to TerminateProcess but it doesn't work either.

[Gogeta70]

I would suggest running the malware in a debugger and see how it's redirecting/blocking the function calls. It doesn't appear to be modifying the IAT, or at least, that's not the only thing it's doing. Knowing more about how it's redirecting/blocking the kernel32 dll routines will allow you to come up with a way around it.

If it is actually detouring the function by writing a small stub at the beginning of each function (basically, a jmp call to it's own routine), then you could try reading in kernel32.dll as a file and patching the kernel32.dll functions in your process at runtime...

[reparto]

I think the process is being protected by a kernel mode driver, here is the evidence to suggest this:
[*]GMER has an option to restore the SSDT in the VM but not on uninfected PCs
[*]There is a driver installed and it is set to start with the system
[*]If I use GMER to uninstall the driver then I can kill the process via normal means but another service restarts the malware. This service is also protected by another driver.

It seems that all the necessary functions for removing the malware have been hooked at a kernel level. The injected DLL is a keylogger.

Not sure where to go now...

[Gogeta70]

Well, you could modify the registry entries for loading any malicious drivers to not load those drivers, along with any entries that load up the executable. But your goal is to terminate the process, right? You'll probably have to do it at the driver level as well.

[reparto]

I'm putting this on a backburner for now. I could just go away and write a driver that gives me unrestricted access to the kernel functions but that feels like cheating to me. I'm going to gather some ideas and keep going at this, who knows I might find something interesting