trogan hunter and PG

ano1,
SetWindowsHookEx only allows the DLL to load into the target process(es), that's all. In order for a program to hook API functions this way code modifications/patching in memory still needs to take place, and it's those modifications that can be easily detected, and bypassed, and cleared. The DLL itself doesn't actually matter - it's the changes that it makes to the process that it modifies that's the main thing.

Regards,
Wayne

 

Hi Wayne:

I mentioned SetWindowsHookEx in order to make sure that we are not talking about GetAsyncKeyState keyloggers.

I agree that we can forget about the DLL. Some keyloggers do not even use a DLL. For example, Fearless Keyspy 2 seems to be based on a separate process. ( It uses the following hook: "invoke SetWindowsHookEx, WH_JOURNALRECORD,addr JournalLogHook,hinstance, NULL".)

What I do not completely understand is your comment: "In order for a program to hook API functions this way code modifications/patching in memory still needs to take place, and it's those modifications that can be easily detected, and bypassed, and cleared." Why is it so easy to detect the hook? Where in memory do you search for it? And from which file on disk do you copy code back into memory in order to over-write the hook?

Thanks for helping me out.

 

SetWindowsHookEx and GetAsyncKeyState are different, yes. GetAsyncKeyState is a bit easier to program, but requires a timer set to 1ms to check literally every millisecond for a keypress. It's more CPU-intensive and less accurate than SetWindowsHookEx which is why most trojans use that rather than GetAsyncKeyState, even though SetWindowsHookEx is a little trickier to code. There are also quite a few OS-specific issues that you should be aware of if using GetAsyncKeyState as a keylogger (see MSDN for more).

GetAsyncKeyState, like SetWindowsHookEx, is a Windows system service (both eventually go to kernel-mode code with a jump from INT 2E/SYSENTER, so the only way to secure them is with a kernel-mode driver. We've secured the latter, and we can secure GetAsyncKeyState as well if we choose, but it's not really a priority at this stage as it doesn't allow the using process to use GetAsyncKeyState to terminate other processes (whereas SetWindowsHookEx does offer that capability), and Process Guard is more about preventing terminations than preventing keylogging, but preventing most keyloggers is just an incidental side-effect of securing SetWindowsHookEx . We're not ruling out adding it later though, but at this stage it doesn't seem necessary.

This is still a global hook, as defined by the NULL as the last parameter. This would easily be blocked by the next update to Process Guard (probably next week).

Because you know what code should exist in your program, so comparing that with what is actually there, or simply checksumming to detect differences, is all it would typically take to detect any changes (such as a user-mode hook, or code modification).

I think I've given you enough information for now in regards to this. Any programmer who needs to clear usermode hooks will figure it out pretty quickly and won't have any problems doing so, but as this info can help trojan authors I'm reluctant to go into specifics, even though such attacks aren't relevant to our own software (as we don't use user-mode hooks).

Best regards,
Wayne

 

1.
"Once a hook DLL is loaded into the address space of the targeted process, there is no way to unload it unless the Hook Server calls UnhookWindowsHookEx() or the hooked application shuts down. When the Hook Server calls UnhookWindowsHookEx() the operating system loops through an internal list with all processes which have been forced to load the hook DLL. The operating system decrements the DLL's lock count and when it becomes 0, the DLL is automatically unmapped from the process's address space."

(see http://www.codeproject.com/system/hooksys.asp )

2.
How do I get the handle required for UnhookWindowsHookEx if I do not have installed the hook?

3.
Can I copy code from the file USER32.DLL to the memory in order to over-write all hooks? Would this crash the system or some applications?

4.
I wonder whether a tool which can clear all user-mode API hooks in a generic manner will actually increase security. A clean OS w/o any user-mode API hooks does not seem dangerous to me.

 

You're getting confused between API hooking and the actual SetWindowsHookEx hook itself. SetWindowsHookEx will load the library into the target process, and for example if it's hooking keystrokes then it will receive those, but that's about all - the hook alone doesn't change the behaviour of any API functions. However, at this point the DLL can then modify the code in the process as if it were its own, for example to change the behaviour of an API function used by that process (typically the API function would be 'redirected' to a function in the loaded DLL which then determines how it should be handled). So, clearing the code modifications is easy, but unloading the actual DLL is somewhat harder (but not necessary anyway).

Regards,
Wayne

 

"You're getting confused between API hooking and the actual SetWindowsHookEx hook itself."

Not really ;-) Just trying to explore different methods.

Don't you think, Wayne, that a tool clearing ALL user-mode hooks would be useful? I believe it would increase security since the user would have the choice to "clean" his system. Any malware depending on user-mode API hooks would be disabled, wouldn't it?

If it's so easy to clean API hooks in a generic manner (not targeting a specific application) why not developing such a tool?

 

Hmmm, a number of applications wouldn't run as designed anymore, I suppose??
Dolf

 

an11,
User-mode hooks have valid uses such as API Monitoring, so making such a tool to clear them probably isn't ideal. Also, our development schedule is already full with PG, TDS4 and WG4 so if somebody else wants to make such a tool they're more than welcome, but we simply don't have the time. However, user-mode hooks are inherently insecure and they were never designed for security which is probably why TH is the only security program we've ever seen that tries to gain security this way.

To elaborate on some of the main reasons why it's insecure (and thus not appropriate for use in security software):
- SetWindowsHookEx only works on processes that have user32.dll loaded, and for a trojan that library isn't really necessary (and even if the trojan does need just one or two functions from user32.dll it can easily carry those functions in its own program rather than using the user32.dll one. For example, it can easily just import psapi.dll to enumerate processes and kernel32.dll for the TerminateProcess API, so that process wouldn't get hooked anyway.

- it requires modifying code in existing processes (as many as possible), and as it does this rather generically it's then easy for a trojan to specifically target the changes that were made, and reverse them.

- anything in a user-mode process can be modified/corrupted/destroyed by other user-mode processes. Kernel-mode code (such as that used by Process Guard) cannot by modified by user-mode code, and because Process Guard then puts in place protections against kernel-mode attacks also, even other kernel-mode drivers can't tamper with the Process Guard driver.

- it requires having a new DLL (not user32.dll, but the actual DLL that provides the new code used by the hooks) load as a seperate instance into every process, which is a significant resource hit.

- Such hooks can typically only be applied once. If you had a second security program that also tried to protect itself this way then there would almost certainly be conflicts, unless both programs knew exactly what hooks/code modifications were in place. So having said that, you can imagine that if the two programs were written by two different companies then they probably wouldn't have the required intimate knowledge of exactly what changes the other is making.

You could argue that "something is better than nothing", but when that something can cause so many problems as outlined above, and knowing how easy they are to remove, it actually does equate to virtually nothing.

Yes it's a lot EASIER and FASTER to implement a user-mode hook than a kernel-mode solution, but SECURITY is the issue here, and as user-mode hooks just equate to a 'bandaid' that can be pulled off even easier than it was applied, giving our users such a false sense of security is just something that isn't an option.

Regards,
Wayne

 

I might just add, that for every area of memory that usermode hooks patch, it requires even more physical memory. Usually kernel32.dll/ntdll.dll/etc are not modified and the one file mapping is used for every process, limiting the amount of memory usage. For example, it is no point loading a DLL 50 times into memory for each process when it never actually changes, this is a good Windows optimization.

When you go modifying these DLL's in each processes address space Windows allocates memory for each page you modify since that DLL no longer exists as it did on the disk. Since a lot of usermode protection schemes patch every process you dramatically increase resource usage SYSTEM WIDE, you won't really notice that much difference in EACH process, but if you add them all up you could see it quite easily.

-Jason-

 

This is not correct. Lithium v2 will not be LSP based, this was abandoned months ago.

 

Thanks for the information Olympus but you are replying to a post made nearly five months ago?

 

Ok Lithium WAS going to be installing a LSP.. it was supposed to be released on 31st December 2003 and has been used "beta" since before then, I doubt much would detect the beta versions unless someone found it on their machine. This is the problem for security conscious users, for everyone.

If its DLL injection, I doubt it can't be blocked quite simply with PG. Sure a lot of trojans will move on to far more powerful, stealthy advanced stuff. So will we when its needed

 

Olympus:

Why did you give up coding a LSP RAT? Would you mind to tell us about the problems you faced? Do you know whether akcom has also abandoned this route?