Classical HIPS and policy based HIPS discussion

The answer to your question is given in this dated by still applicable article that is addressed to 32 bit OSes: http://www.codeproject.com/Articles/2082/API-hooking-revealed

The major implementation difference between them is that interceptor engine for kernel-level hooking is wrapped up as a kernel-mode driver, whereas user-level hooking usually employs user-mode DLL
​

Kernel mode rootkits are in reality just hidden process level 0 drivers.

Eset and SpyShelter to name a few security products use kernel mode drivers to monitor API activity. Eset also can dynamically inject a user level .dll hook as additional protection for Internet using processes when the kernel level driver detects abnormal API activity. SpyShelter chose to closely monitor API activity associated with keylogging, screen capture, and the like activities as its primarily monitoring emphasis.

Other security products use a combination of both fixed user level hooking set by dll injection and kernel mode hooking by driver. Many of these use the kernel driver hook to monitor the user level injected .dll against tampering activity by malware in addition to performing user level .dll process injection. These products will inject their user level .dll upon select pre-determined target process startup.

Finally, products like Online Armor, Outpost, and Zemana Anti-Logger Free use AppInit_DLLs based injection to set a user level .dll hook into every application process at system and/or process startup time. I believe the paid ver. of Zemama Anti-Logger uses a kernel mode driver.

Most recent security products with a HIPS component will use kernel mode drivers as their primary API monitoring mechanism.

Finally, it is the software entity deployed to monitor API calls that determines it access privileges. A .dll injected into an application process will have user level privileges. A driver based process can have either user or kernel privileges. The drivers deployed by Eset and SpyShetler for example, have kernel level access. You can't monitor kernel level activity unless you have kernel level access.

​

 

Thanks for the info, it's interesting, I think I read it a couple of years ago. However that doesn't completely answer my question, because this article talks about the usage of user mode hooks to monitor API hooking. Like I said, SS doesn't seem to be doing that, so the only conclusion is that they are somehow doing it directly via the driver, without the help of any user mode hooks.

 

This might help. From the Excubits folks: http://www.bitnuts.de/KernelBasedMonitoring.pdf

For those that don't want to read all the technical stuff, here's a list of products from the article that support global event filtering in some fashion:

Microsoft AppLocker

http://technet.microsoft.com/en-en/library/dd723678(v=ws.10).aspx​

TripWire

http://www.tripwire.com/it-security...uration-management/file-integrity-monitoring/​

Bit9 Parity Suite

https://www.bit9.com/products/bit9-parity-suite.php​

CoreTrace Bouncer

http://www.coretrace.com/products-2/bouncer-overview​

Lumension Application Control

http://www.lumension.com/application-control-software.aspx​

McAfee Application Control

http://www.mcafee.com/de/products/application-control.aspx​

Application Access Control

http://www.tricerat.com
​

Anyone reading the Excubits article should also pay close attention to the 'Drawbacks' section. I commend the author's honesty there. Of note is that even with kernel level filtering employed, you're not 100% bullet-proof as far as malware infection goes.

 

The Excubits article has this excerpt I will explore a bit further:

The drivers are not digitally signed, hence you cannot run them on 64-bit version of Windows without a tweak (or work around). There you must boot into Testsigning Mode and digitally sign the drivers by yourself or you start up Windows without checking code signatures. To do the latter just press F8 while rebooting your system.

On Windows 8 the classic F8-Bootmenu must be enabled by executing the following commands in an console:

bcdedit /set bootmenupolicy legacy
bcdedit /timeout 12
​

So in theory, x64 rootkits should never exist. Sorry, that unfortunately is not the case. Let's look at an APT x64 rootkit named Turla and how it operates from this excellent dynamic analysis article: http://labs.lastline.com/dissecting-turla-rootkit-malware-using-dynamic-analysis

Bypassing Signature Verification for Drivers

First, let’s see how Turla manages to load untrusted code into the context of the kernel. To execute new code in the kernel, the authors use a nifty trick, using a vulnerable version of a signed VirtualBox driver as a stepping stone: Loading this first driver does not raise suspicion - after all, the code is signed by a trusted entity. However, by loading this driver, a new vulnerability is introduced into the kernel, allowing a user-mode application to write to arbitrary memory locations inside the kernel.

Defeating PatchGuard

Despite the ability to run unsigned code in the operating system kernel, the APT is not yet able to achieve its rootkit behavior, as PatchGuard prevents injecting malicious code into the control-flow of critical system functionality.

This is addressed in the second step of the attack: The attackers start off by hooking functions RtlCaptureContext, KiRetireDpcList, and RtlLookupFunctionEntry in addition to the rootkit-activity related functions, which, as described above, will trigger an alert from PatchGuard the next time the integrity of system memory pages is verified. As soon as this happens, PatchGuard calls KeBugCheckEx, which, in turn, forces a system shutdown by showing the infamous blue-screen-of-death (BSOD).

However, Turla is able to bypass the BSOD using one of two possible techniques: In an earlier version of the APT, the code hooks KeBugCheckEx and forces the function to return without executing the BSOD functionality. After Microsoft updated PatchGuard to use a copy of the KeBugCheckEx function (cloned during the initialization of the system) instead of the global function in the kernel, a newer version of Turla appeared; this new version started hooking RtlCaptureContext instead of KeBugCheckEx. The former function is called internally by KeBugCheckEx (and thus also as part of the copied version), allowing Turla to intercept the execution before raising a BSOD [3].

-EDIT- BTW - this incident might be one reason to upgrade to WIN 10. It will no longer allow third party signing of drivers; they must all be Microsoft code signed.
​

​

 

I read this document about a year ago, it also doesn't explain exactly how to protect against API hooking without the use of any user-mode hooks. It's a bit hard to find this info, but like I said, it has to be done via the protection driver. And the reason why I bumped this thread was because of this technique (see link), where malware simply hooks the network driver (kernel mode hook). Like I said, current HIPS can't catch this.

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

Yes correct, drivers have to be signed on Win 64 bit, but advanced malware will probably be able to bypass that. And besides, just because some app is signed doesn't mean it's clean. My motto is to "trust no app", let's stake EagleGet for a example (a download manager), it also installs a driver, so you already now it will probably mess around with browser memory and perhaps also tries to monitor network traffic in a low level. That's why too risky and fishy for me.

http://www.eagleget.com/

 

BTW, this is an interesting article about the hooking techniques that's being used by KAV. But it's about Win 32 bit, so probably not all of these techniques can be used on Win 64 bit. And the other link is about the Caphaw/Shylock banking trojan:

https://quequero.org/2014/10/kaspersky-hooking-engine-analysis/
https://quequero.org/2013/10/caphaw-shylock-in-depth-analysis-part-3/

 

I am not following you. You're creating a kernel based mini-port driver to monitor API calls. Any hooking activities it's doing are at the kernel level. Don't know where you're getting the user-mode hooks business from.

As far as Rovnix goes, it is using its own NDIS miniport driver. You stop it by preventing the driver from being created in the first place. In fact, Rovnix driver loading isn't that sophisticated since it loads at boot time. Forensically, you can detect it using a tool like WinDbg. Scroll down to the section in this article: http://www.malwaretech.com/2015/02/bootkit-disk-forensics-part-1.html named 'Detecting Major Fuction Hooks With WinDbg.'

 

OK so you're saying that SS can hook the same API's inside browser memory via the driver? That would make sense, but I'm just trying to figure out why all other tools (like Zemana and Trusteer) monitor the browser via driver + user-mode hook. Like I said, SS only uses the driver, without user-mode hook.

That's what I'm trying to explain. New generation HIPS should be able to block API hooking after the driver has already been loaded. But we already came to the conclusion that it would probably be bad for system stability because of the risk of false positives. And perhaps it's technically not even possible. Probably only a hypervisor based HIPS would be capable of this, see links.

http://northsecuritylabs.blogspot.nl/2011_12_01_archive.html
http://www.esecurityplanet.com/windows-security/review-mcafee-deep-defender.html

 

BTW, these are some interesting articles about the various hooking techniques (both user and kernel mode) that can be used by both malware and security tools. The second link describes a technique to hide processes from the task manager. I wonder if HIPS can catch this. I do know that EIS should alert about activity from hidden processes.

http://nagareshwar.securityxploded.com/2014/03/20/code-injection-and-api-hooking-techniques/
https://www.apriorit.com/dev-blog/160-apihooks

 

Hum ..... All depends where the HIPS miniport driver is loaded on the stack. Remember the HIPS can already monitor stuff like direct disk access so it is monitoring APIs associated with that. So I have to assume the HIPS driver loading is early but if a rootkit driver is prior loaded, it is game over. However, there is a limit to what it can monitor and distinguish between legit and malicious activity. Referring to Trula, note the sequence of events:

http://labs.lastline.com/hubfs/3-turla-apt-behavioral-analysis-lastline.png?t=1454007719970

After it disables PatchGuard and injects its code into the OS kernel, the game is over since no HIPS or any other piece of software is capable of monitor OS kernel functions nor should it.

Yes - something like Deep Defender is effective but only on select hardware that supports it because of this:

When DeepSafe is installed on a computer with a vPro processor and the system is rebooted, DeepSafe loads as the very first boot driver, before any rootkits have a chance to load. The operating system then loads on top of it.
​

In other words, it can monitor all driver and system activity.

 

Note the following excerpt from the above link:

1.2 Local and global API hooks
There are two types of API hooks: local and global ones. Local hooks are applied only to the specific application. Global hooks are applied to all processes in the system. The Windows hook technique, which is shown in this article, is global and impacts on all processes in all sessions (in contrast to the SetWindowsHooks way that is bounded to the specific desktop).

2. AppInit_DLLs infrastructure
​

All the classical HIPS like Outpost's HIPS and Comodo's Defense+ have default rules that monitor modification of the AppInit_DLLs associated registry keys. I added a like rule to my Eset HIPS rules. Again, the strategy is to block the creation of the malware; in this case adding the names of the malware .dlls to the AppInit_DLLs registry versus trying to monitor the specific activities of what those .dlls are performing.

The same strategy applies to rootkits. You concentrate on blocking the creation of its driver rather than trying to monitor what it is doing.

Remember the old truism, "An ounce of prevention is worth more than a pound of cure." Or simply stating proactive protection is far more effective than reactive protection.

 

Here's an entire book dedicated to rootkit analysis; a bit dated but still plenty of info: https://books.google.com/books?id=E...o prevent rootkit driver installation&f=false

On page 298 is a section on rootkit prevention. Note that the author states that the following API is use exclusively by rootkit drivers - ZwSetInformation with SystemLoadAndCalIImage so that is what you would want to monitor. Note that's an "I" after "Call."

SystemLoadAndCallImage is used for persistence: http://flylib.com/books/en/3.414.1.155/1/

 

We already discussed this. Of course this can be stopped by simply blocking certain activities, but the next step is to block or detect suspicious behavior after malware has already modified the system in a malicious way. The problem is that hooking API's can be used in both a legit and malicious way.

For example, when it comes to process hiding that can even fool Process Explorer, it seems like the NtQuerySystemInformation API is hooked. So the question is, how common is that? I have no idea, but if HIPS could block apps from hooking this API (after code injection), you could block hidden processes.

 

Yes. HIPS is a reactive or defense strategy. It is designed to monitor known activities used by malware. For example, a HIPS rule to alert against process modification monitors known Win APIs that do that. Most HIPS's will also allow for monitoring a process against global hooking by monitoring SetWindowsHookEx activity. A HIPS can also monitor API's used for debug purposes and the like. However, monitoring of kernel hooking activities performed by drivers is far beyond a standard HIPS capability due to the difficulty of determining what is malicious versus benign behavior.

Since you brought up Process Monitor, do you know that it dynamically creates and loads a kernel level driver? I monitored its behavior with Eset's HIPS. On x64 systems, when PE starts up it runs a 32 bit process that spawns a 64 bit process. The 64 bit process creates a .sys driver file in C:\Windows\System32\System\Drivers. It then loads the driver and deletes the .sys file it previously created. The only trace that a driver ever existed is it will show as a ghosted device. Using the "set devmgr_show_nonpresent_devices=1" option from a admin command prompt, then entering "start devmgmt.msc," and finally setting the "show hidden devices" option in Device Manger, you will see the ghosted PE driver.

They is nothing to prevent a rootkit from performing the same behavior. So at the very least, one has to monitor write activity to C:\Windows\System32\System\Drivers folder with a HIPS rule.

 

@Rasheed187

I want to discuss Ronvix more in detail and its hooking from the link you posted previously. From the reference:

1.At boot time, Rovnix hooks the following exported APIs in ndis.sys by patching the export table in memory:

•NdisMRegisterMiniportDriver() (for NDIS 6.0)
•NdisMRegisterMiniport() (for NDIS 5.1)

•When the network adapter driver calls NdisMRegisterMiniportDriver()/ NdisMRegisterMiniport() to register to NDIS, the hooked function registers Rovnix’s own miniport handler functions.
•With Rovnix’s own miniport handler functions, the malware is able to send/receive the packets through this private TCP/IP stack
​

Note that that the Rovnix's NDIS miniport filter driver is a boot driver. I just checked Eset's NDIS miniport filter driver and it loads at OS startup time. You can check SpyShelter's miniport filter driver to determine when it loads. All boot drivers load prior to OS startup drivers; this is extremely important to note. Boot drivers are lower in the stack which means they can intercept activity prior or after OS startup drivers depending on the type of activity. More on this later. I am sure rootkits make sure they load as early as possible by making sure they use a early loading service group from those loaded in the ServiceGroupOrder registry key.

As far as the hook functions that Rovnix miniport filter performs, I am fairly sure the same functions are being done by Eset's and Spyshelter's miniport drivers. Eset's miniport driver catches incoming network traffic for malware scanning using its HTTP filter and for unencrypting HTTPS traffic and malware scanning that. Once that is done, the Eset miniport filter passes on the traffic to the browser.

Now "for the rub" so to speak. Since the Rovnix miniport filter sits lower in the stack, it can capture the incoming network traffic and do with it what it wants prior to the Eset's miniport examining it. Even if the Eset's miniport driver was a boot driver, the Rovnix driver could still intercept if it was prior loaded. As far as outbound network traffic, Rovnix pretty much free to do what it wants. However, there is a firewall element here. Eset's firewall is a boot driver. Packet scanning at the firewall level could trip up Rovnix. However, Eset's firewall has that option turned off by default and it does slow down browser speed.

The bottom line is that monitoring hooking functions is an effort in futility in most instances since malware uses the same hooks legit software use. What has to be monitored is rootkit driver installation and associated registry modifications. Also monitoring of driver loading can be used as a secondary defensive strategy.

​

 

I think in theory it should be possible to block kernel mode hooking, but how to decide if it's malicious or not, that's the problem. Zemana and SpyShelter have both implemented a white-list, and based upon that it decides if apps are allowed to hook user-mode API's.

Keep in mind, they don't block code-injection unless the user blocks it. They will however block API hooking automatically so without user input. So in theory you should be able to implement the same model for kernel mode hooking, but it would be quite complex.

I wonder if this is really the case. Why would security tools need to hook these API's inside the NDIS driver? I don't think it's needed in order to monitor inbound and outbound traffic, but it sure comes in handy if you want to hide network traffic. In other words, I don't believe this is quite common behavior.

 

Actually, there's nothing special about it, Process Explorer and Process Monitor are both using "direct driver loading" and HIPS back in 2004 could already block this.

 

BTW, these are a couple of interesting articles, describing a couple of methods that HIPS/HIDS could use to detect hidden processes and services/drivers:

http://securityxploded.com/hidden-process-detection.php
http://securityxploded.com/hidden-services-detection.php

 

And using a combination of default and user rules to protection vulnerable processes, a HIPS will do the same. With a lot less effort, a behavior blocker such as Emsisoft's will also do so.

Note the multiple refs. to NtQuerySystemInformation in the article. However since these are user hooks, a properly configured HIPS or a behavior blocker should detect these.

Also as discussed previously if the rootkit has been able to invade the OS kernel, it is game over. Just do a DoD standards wipe of the hard drive and restore from an image backup or reinstall the OS.

 

Those hooks are used to register the miniport filter driver so I am sure security software use them to do the same. The difference is when it is being done. Legit software will do so only when the software is being installed.

The nasty driver is below but again is used by security products:

NDIS Hook Driver
There are two approved techniques to write an NDIS Hook driver. The first one is based on interception of some NDIS wrapper functions at runtime by writing a kernel mode driver that patches NDIS.sys in memory to replace the addresses of NdisRegisterProtocol, NdisDeregisterProtocol, NdisOpenAdapter and NdisCloseAdapter functions with internal ones.

The second one is based on registering a fake NDIS Protocol driver just to get a pointer to an internal NDIS structure NDIS_PROTOCOL_BLOCK.

At this level, both methods have enough information to substitute all protocols and adapters handlers to getting full control over all network traffic.

Although these approaches use sophisticated hacking techniques and require good understanding of different NDIS versions internals, an NDIS Hook driver is easy to install and able to filter, inject or modify packets. Several security software products including personal firewalls and VPN clients use these techniques.

This approach is discouraged for Windows Vista and higher.​

Ref.:https://briolidz.wordpress.com/tag/ndis/

 

Cylance has a great reference to registry keys that should monitored using a HIPS:

http://blog.cylance.com/windows-reg...troduction-attack-phases-and-windows-services
http://blog.cylance.com/windows-registry-persistence-part-2-the-run-keys-and-search-order

 

Now that I think of it, Zemana and SS are only focused on blocking rather than detection, so when it comes to this, Malware Defender and System Safety Monitor were more advanced. This is something that current day HIPS are lacking. A HIDS component would be nice.

http://www.snapfiles.com/get/malwaredefender.html

Actually, I don't believe that EIS protects against API hooking, not in the same way that Zemana and SS do.

 

Actually, after reading that article I get to impression that it's not common and not recommended to hook the NDIS driver. In other words, this is something that could be easily monitored. Now that I think of it, white-listing is always needed when it comes to blocking of user and kernel-mode hooking since it's not something that can be suspended. Now I understand why SS can not alert about it, this is something I did request so I was being a bit silly.

My take on registry monitoring is that you should only protect the ones that you can make decisions about and the ones that should normally never be touched. I sometimes get alerts about modification of certain reg-keys, but I don't have a clue if it's normal or risky to change those keys, very annoying.

 

This is an interesting article about the Corkow banking trojan, as mentioned in another thread.

http://www.welivesecurity.com/2014/02/27/corkow-analysis-of-a-business-oriented-banking-trojan/

 

I agree, Malware Defender was one of the best. Pity it's not supported anymore. Although it allowed for hook monitoring, I don't know what hooks it did so for. Do you? I also believe Defense+ gives you equivalent protection but you have no control over what hooks it is monitoring.

BTW - Eset does have IDS protection. It's part of its Network protection.

I monitor most of the keys referenced in that article. The only time you should get alerts on those is when you're installing new software or as a result of Win Updates. Eset does not have a Trusted Installer or Win Update mode like Defense+ has which is a pain in the butt.

They cover it this BB protection "use of hidden (Rootkit) processes" but don't elaborate on the details.