Classical HIPS and policy based HIPS discussion

@ Rasheed

I believe this article explains user mode kernel hooking via use of the SSDT: http://www.adlice.com/kernelmode-rootkits-part-1-ssdt-hooks/

Detection/Removal

To detect such a hook, we need to load a driver that will scan the SSDT and compare each pointer to the address range of ntoskrnl module. If one is outside this range, it’s probably hooked by some module. Pretty easy to detect.

However, some other tips exist to hook the SSDT, some rootkits do not change the address in the SSDT but change the assembly instructions of the first bytes in the target API (in ntoskrnl then) to point to the hooking module. This is called Inline hook (not covered here).

To remove a SSDT hook, you need to retrieve the true address of the API (somewhere…) and replace the bad address in the SSDT. That should remove the filter and let the rootkit unprotected. Pay attention, the restore action must be atomic (else we can have some BSoD).​

To clarify, user mode hooks set in the kernel, begin with "Nt". Kernel mode hooks being with "Zw". And again PatchGuard on x64 OSes will prevent kernel mode hooks. That is why the hook monitor must be driver based; so a kernel mode hook can be set. As noted in the above excerpt if restore actions are not exact, you're going to blue screen. Also whether the use of a monitoring hook running in real-time is practical is another issue. It will have an impact on performance. Finally, your AV solution can also be setting it's own monitoring hook. Using Emsisoft as an example, its kernel monitoring hook is only set upon demand when it detects some abnormal activity. This also leads me to believe that enabling Kapersky's "changing system modules" option on a permanent basis as noted previously will cause a noticeable performance hit.

Here is a python script that will detect SSDT hooks from user-mode: https://gist.github.com/ksose/1064568

​

 

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=9&cad=rja&uact=8&ved=0ahUKEwif5fXnlonLAhWKcD4KHR9ZAOkQFghbMAg&url=http://www.reconstructer.org/papers/Hunting%20rootkits%20with%20Windbg.pdf&usg=AFQjCNHNqC25pcVaPNmJTvSbjftCsIL74w&bvm=bv.114733917,d.cWw

windbg script.

 

That is another subject I guess, of course most AV's would catch it, but the article was more about the techniques that Gozi uses to bypass protection against code injection into Edge. Gozi simply uses another trusted system app (RuntimeBroker.exe) to do this.

Did you also notice which API's are being hooked? HIPS like SS will normally block hooking of the WININET API, but they won't block KERNEL32 hooks, since it would cause too many false positives.

 

I'm not sure if I understood it correctly, but most HIPS do monitor modification to the KnownDlls registry key.

Yes, I posted this link earlier, but I don't understand what you're trying to say? AFAIK the SSTD can not be hooked anymore in Win 64 bit. Or are you saying that it fact this can indeed be done by using inline hooking (kernel mode)?

 

BTW, Device Guard on Win 10 is looking quite good:

http://www.malwaretech.com/2015/09/device-guard-beginning-of-end-for.html

 

Thanks for this link Rasheed.

 

Yes. Malware inline hook example that bypassed PatchGuard: https://blogs.mcafee.com/mcafee-labs/analyzing-uroburos-patchguard-bypass/

 

Windows 7 and earlier.

 

This has nothing to do with registry modification. You are modifying a directory within Object Manager that resides in memory. You have to read the entire CodeProject article.

Then we open the directory of KnownDlls Object Manager using the NtOpenDirectoryObject, function, whose parameter is the name of the directory. For the x32 process section name is KnownDLLs32, for x64 processes - KnownDLLs. For x64 processes, ws2_32.dllis is located in C:\Windows\system32\.
​

-EDIT-

Elaborating, you have to understand a bit on what the Object Manager is and what functions it performs. Here's a ref.: https://en.wikipedia.org/wiki/Object_Manager_(Windows) . Here is a FireEye article that appears to be based on the CodeProject article that explains what is going on with less technical details: https://www.fireeye.com/blog/threat-research/2010/07/malware-persistence-windows-registry.html.

Simply put, the knowndlls for x64 .dlls and knowndlls32 for x32 Object Table entries are populated at boot time from corresponding registry entries. What the CodeProject article details is a method to "hijack" entries in those tables. You replace a dll table entry with an entry pointing to your malicious dll. Again the only way this activity can be prevented is:

To protect the process from intrusion via KnownDlls you can use kernel mode hook of API function named NtCreateSection checking the path to DLL. If it doesn't correspond to the system one, the section creation must be blocked.
​

When an Object Table change is attempted via NtCreateSection API, the corresponding monitoring hook is checking that the path entry for the dll is the same as where the system one is stored. This can be done by comparing the attempted path change to that stored in the registry as again noted in the CodeProject article:

Moreover, if you look closer to the KnownDLLs registry key, you’ll see that the search paths are not indicated there. It’s because all KnownDLLs are supposed to be located in the folder, indicated in the registry key:

KEY_LOCAL_MACHINE\System\CurrentControlSet\Control\KnownDLLs\DllDirectory. Note: This key is created at boot time and does not permanently exist in the registry.

This is one more security aspect of KnownDLLs: requirement of that all KnownDLLs are placed in the same specific folder.
​

From the above details, I think it is fairly obvious that this type of API monitoring activity is outside the scope of most conventional HIPS's and AV software.

​

 

I'm not sure if I understood correctly, but you can't hook the SSDT unless you bypass PatchGuard, like Uroburos did. It used inline hooking for the bypass, but HIPS can't block this. The same was done by Rovnix to hide network traffic, that's what sparked the discussion.

https://blogs.technet.microsoft.com/mmpc/2013/07/25/the-evolution-of-rovnix-private-tcpip-stacks/

OK I see, so this attack is related to DLL Hijacking? I believe most HIPS don't cover this, but Online Armor did alert about this, see the second pic: http://help.emsisoft.com/oa/UsingOA.shtml

Seems like they fixed most security loopholes related to PowerShell and .NET, but only on Win 10.

 

Yeah, OA was every bit as good as Defense+. I was all set to purchase it, when Emsisoft announced they were dropping it. Would have never went with Eset if OA was still around.

 

Just got done testing EAM BB using Comodo Leak Test. With all behavior monitoring rules enabled for CLT, my score was 220/340. With my custom Eset HIPS rules, my score is 300/340.

Interestingly, EAM also flunked the two CLT hook tests. So I don't know if those tests work on WIN 7+. I could find no reference to either in the Process Monitor log I generated. One possibility is many HIPS's are monitoring for SetWindowsHookEx and are overlooking SetWindowsHookExA - ASCII ver. and SetWindowsHookExW - Unicode ver.. CLT uses the SetWindowsHookExA function.

 

Actually, I didn't really like it, but I did get the impression that it was quite powerful.

I'm not willing to run the Comodo Leak Test because the last time I got a BSOD. Too bad that you can't run the tests one by one.

 

I think I finally have finally determined why most HIPS fail the CLT SetWindowsHookEx and SetWinEventHook tests.

First, CLT is a 32 bit program. So the assumption is the hooking is going to be performed against 32 bit .dlls. So using SetWindowsHookEXA or SetWindowsHookEXW are the correct functions to use. The CLT SetWindowsHookEXA global hook test is a test to hook all instances of kernel32.dll. Looking at the test .dll plug-in CLT uses in detail, it appears that no actual hook details are present; for example the keyboard function if you wanted to capture keystrokes. From this I deduce that Defense+ monitors the actual API calls. So CLT test failure is given if the API call is not detected.

Most HIPS's on the other hand, like Eset's, are monitoring actual hook injection into a .dll for a protected process. Since that never occurred using the respective CLT hook tests, the HIPS's will ignore the activity from CLT. Again, a HIPS would not be directly monitoring an unknown process's hook activity. Rather it is monitoring rule defined protected processes for .dll hook modification or injection. Also reputation wise, CLT is considered a trusted process to Eset. As such, the advanced heuristics protection would not be paying any attention to its activities.

Now behavior blockers like Emsisoft would be monitoring the source process for such activity. Again, no hooks via CLT were actually attempted to be set. As such, EAM would not have detected any abnormal activity from it. Also I believe that EAM/EIS might only be monitoring for select hooks such as those associated with keylogging.

Finally if the CLT hook test actually did hooking activities, most would fail on a x64 OS since its target hook .dll, user32.dll, is 32 bit. You can't hook a 64 bit .dll from a 32 bit source .dll.

 

Aren't those related to global hooks? Most HIPS should easily pass this, no matter if it's on Win 32 or 64 bit. But perhaps we should ask Comodo to update this test, you should be able to run these tests separately.

That's because you're not into HIPS that give full control. I believe that EIS tries to minimize alerts that rely on user decision. It's basically an "expert based" behavior blocker, see link.

http://www.symantec.com/connect/articles/behavior-blocking-next-step-anti-virus-protection

 

That's what I said, you're not into it. But I prefer to rely on my own knowledge, you never know if a behavior blocker might fail. I rather have a false positive than a false negative know what I mean?

 

I didn't realize how good SSM was as I never really used it to that extent.Ive just discovered its application firewall ,which i hadn't enabled in the past.Its actually intercepting before sygate firewall ,and seems to run comfortably with every other security app i use.

 

The two most important hooks to monitor are SetWindowsHookEx and SetWinEventHook. And correct, most HIPS's do monitor for these but the degree of monitoring varies. Some will only by default monitor SetWindowsHookEx type activity for browsers for example. I monitor all Windows processes and all apps installed in C:\Programs and C:\Program Files (x86) against such activity.

Excluding in-line, AppInit_DLLs, and the like methods, there are basically two types of Windows based hooking; thread specific and global. Both use SetWindowsHookEx to implement. A good discussion of Windows based hooking is here: http://flylib.com/books/en/4.460.1.22/1/ . Excerpt from the article:

Global and Thread-Specific Hooks

A hook may be thread-specific, in which case it hooks messages (of the specified hook type) sent only to a particular thread, or it may be global (or system-wide), in which case it hooks all messages (of the specified hook type) throughout the system. Hooks of some types can be set for either individual threads or globally, whereas other hook types (such as journal hooks) must be global.

Indeed, whenever a thread in one process sets a hook on a thread in another process, the issue of cross-process communication must be addressed. To illustrate, imagine that Thread A in Process A wants to set a mouse hook on Thread B in Process B. Thread A must call the SetWindowsHookEx function (discussed soon) to set the hook, passing this function the thread ID of Thread B. However, it is the hook procedure in Thread B that is called when a mouse message is sent to Thread B.​

 

Interjecting here just for a brief. This is an amazing discussion guys, carry on.

I just couldn't help express myself on the disappointment that just as HIPS were really showing some absolutely great strides in combatting malware on 32bit systems, many HIPS developments FAILED to make the adjustments for compatibility to x64 bit systems. Of course and as expected, commercial AV vendors were quick to fill that gap and adapt HIPS into their own products at that transition.

No one was more devastated then I was to learn that none of the previously depended on HIPS apps were NOT going to go 64 bit and as such faded into oblivion.

A good solid well configured HIPS is/was a super idea/concept and a reality that done a fairly nice job at preventing/suspending malware intrusions at system calls, entry etc. BEFORE they could finish their instruction code to disrupt machines.

 

I've said this previously and I will say it again. We can all thank the AV labs for the demise of HIPS capability in retail security software. Their stance has been that all end users are nobs when it comes to alerts. Accordingly, security software should be "silent" and run with zero user interaction. They went further and penalized the security vendors in their lab test results if they didn't comply with this philosophy.

In a perfect security world, I would 100% embrace this alert-less approach. In reality, that will never be adequate since the malware creators will always be one step ahead of the security vendors in the PC world. More so currently since malware development is now a revenue generator. The end result has been to "dumb down" existing HIPS default settings such as those in Eset. Ditto for Defense+ default settings.

Bottom line is people like those that frequent Wilders as a class are not profitable enough for vendors to continue mainstream retail HIPS development.

 

You summed it up nicely. A HIPS especially a powerfully one like OA is not a product a non-technical person should use. I would never recommend using a HIPS to the average Windows user.

On the other hand, I have seen people performing a number of "security gyrations" using the anti-execs that are popular with Wilders users. If one is going to that degree of configuration, you might as well "bite the bullet" and go for the bulls eye and start using a full feature HIPS.