Classical HIPS and policy based HIPS discussion

Continuing the hook discussion of above reply #346, there are what can be described as "indirect hooking" methods to get access to a process. Rasheed187, I believe, describes these as hooks although technically they are not.

The most common of these methods uses the CreateRemoteThread function described here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682437(v=vs.85).aspx . Simple put, this function creates a thread that runs in the virtual address space of another process. It is a favorite of malware to perform both disk and memory based .dll injection into a process. However, CreateRemoteThread is also used non-maliciously by a number of processes. So direct monitoring of its use alone needs to be conditioned on monitoring of associated API's that can alter virtual memory. These are most frequently:

VirtualAllocEx and VirtualFreeEx
WriteProcessMemory

The ability of detecting the above activity varies by HIPS. Eset's HIPS detects this activity under the "process modification" category. Also, the ability to detect by default such activity in targeted processes varies by HIPS. In many instances, specific user rules must be manually created for processes you want to protect against such activity. Finally as should always be done when creating HIPS rules, throrough testing is required to ensure legit process activity is not blocked by such rules.

I will also add that behavior blockers such as that used in Emsisoft are very good at detecting the above activity. If an "unknown" process is performing these actions, it is almost always with malicious intent. Where behavior blockers might fail to detect would be in the case of a hidden rootkit running with admin or above priviledges.

 

I'm not sure why you're so focused on Global Hooking, they are mostly used by keyloggers. Even when you allow them to be loaded, a feature like keyboard encryption as offered by SS and KeyScrambler, will still block hook and message based loggers. Of course legitimate apps like StrokeIt and Volumouse also use global hooks.

http://www.tcbmi.com/strokeit/
http://www.nirsoft.net/utils/volumouse.html

This is no surprise, you can't expect Average Joe to know how to respond to alerts, HIPS are clearly geared to geeks. The good news is that companies like Zemana and SS have survived, and the reason is because they give an option to turn the HIPS off while still offering automatic protection against keyloggers and banking trojans without user interaction.

 

Don't forget that in fact you're already using HIPS technology. AG's Memory Guard and HMPA are in fact also HIPS with the difference that they auto-block suspicious behavior. For the people who need more control there are HIPS like SS, but even KAV/KIS has an advanced HIPS. BTW, Webroot's ID Shield is another example of HIPS that auto-protects the browser without asking questions:

https://community.webroot.com/t5/Techie/Identity-Shield-Deep-Dive/td-p/46422

 

@ itman

Speaking of API hooking, here is another tool that uses the same method that banking trojans use to hijack the browser. I haven't tested it though, but perhaps you can check it out. Normally speaking, Zemana and SS should block hooking of the browser. I'm not sure how HMPA (safe browsing) would react.

http://blog.elevenpaths.com/2013/11/hookme-tool-for-intercepting.html
https://code.google.com/archive/p/hookme/

 

Interesting tool:

HookMe's goal is to intercept network sending and receiving API calls.

One of the available plugins is MySQL_Backdoor.txt which forces HookMe to attach itself to mysqld.exe process and listens to a specially crafted packet.
​

Again, this is not hooking per se. It is a process that is intercepting API calls as best as I can determine. It would have to be injected into another process as noted above. And neither Zemana nor SS blocked memory based injection as discussed previously.

Also this software is nothing more than a TCP proxy; note the like statement at the beginning of the host site's web page. This puts it in the same class as software like Fiddler.

I also suspect that HookMe is using Layered Service Provider. LSP has been deprecated since Win 8.1. Ref: https://en.wikipedia.org/wiki/Layered_Service_Provider

Here's a "universal hooker" that will allow you to capture any API's you want. Whether it still works, I have no idea since the code was written in 2007: http://zqpythonic.qiniucdn.com/data/20100803113020/index.html . Again, the "rub" is it have to be injected into a target process. Again, HIPS rules should prevent that injection.

​

 

I don't know what you mean, I think you're misunderstanding. This tool uses the exact same technique that banking trojans uses, namely API hooking, so yes it's called hooking. Both Zemana and SS can not only block code injection but also API hooking of the browser. I don't believe that a lot of banking trojans make use of reflective dll injection if that is what you mean.

But we already discussed this, the whole point of blocking API hooking is that you don't have to bother users with questions about code injection. And I don't believe it uses LSP's, there is no need to when you can already hijack and manipulate browser traffic. But anyway, I couldn't run the tool sandboxed, so you probably need a VM for this.

 

Thought I would return to the "dll hijacking" issue presented Comodo's Leak knowndlls Test.

Reviewing past CLT test results, I notice that PrivateFirewall passes this test. That makes sense since PF is just a rebranded version of Dynamic Security Agent aka DSA. DSA was developed as a commercial HIPS product. As such, it has the ability to directly monitor Win API calls. Again, the easiest way to get this type of capability is to purchase a commercial HIPS product such as McAfee's Endpoint. PF was reworked so the user no longer has the ability to directly monitor Win API calls.

Windows allows hijacking of knowndlls and knowndlls23 Global Table entries due to the following. MS's stance as to access to the GlobalRoot area where the Global Table resides is that it is not accessible programmatically. Not even Powershell can directly access the GlobalRoot. Any direct program access of the GlobalRoot will result in an "access denied" error message. However, MS doesn't consider low level access methods such as API calls to be direct program access.

 

API interception and the means to do so are not separate entities. To do API interception, you need code. That code is usually a .dll. The .dll cannot run by inself. It has to be loaded into an executable. Malware does that by injection means. If the .dll cannot be injected, API interception cannot occur.

Per Malware Research Group 3rd quarter 2015 browser banking protection test:

Simulator Test – API hooking tests

Financial malware developers always find new ways to bypass current protection technologies. One of the oldest techniques is to inject the attacker supplied DLL into Internet Explorer, then hook (redirect) the API calls, where the password can be found in a buffer passed to the function as a parameter. In this test, we used reflective DLL injection technique for the DLL injection step, and hooked either the HTTPSendrequestW function or the EncryptMessage function, either via not exported functions, or page exceptions. This is a total of four tests. ​

 

I would like to put this hooking discussion "to sleep" so to speak.

They are two categories of hooking used for Windows OSes. Generally speaking, the difference is where .dll injection is used.

The non-.dll injection category entails the ability to "link" the source malware process to one or more target processes. The two methods to do this is using the Win API's SetWindowsHookEx and SetWinEventHook.

SetWindowsHookEx

You must place a global hook procedure in a DLL separate from the application installing the hook procedure. The installing application must have the handle to the DLL module before it can install the hook procedure. To retrieve a handle to the DLL module, call the LoadLibrary function with the name of the DLL. After you have obtained the handle, you can call the GetProcAddress function to retrieve a pointer to the hook procedure. Finally, use SetWindowsHookEx to install the hook procedure address in the appropriate hook chain. SetWindowsHookEx passes the module handle, a pointer to the hook-procedure entry point, and 0 for the thread identifier, indicating that the hook procedure should be associated with all threads in the same desktop as the calling thread. Note: For a non-global hook, you would use a different thread identifier.

Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644960(v=vs.85).aspx

SetWinEventHook - Options

INEVENT_INCONTEXT
The DLL that contains the callback function is mapped into the address space of the process that generates the event. With this flag, the system sends event notifications to the callback function as they occur. The hook function must be in a DLL when this flag is specified. This flag has no effect when both the calling process and the generating process are not 32-bit or 64-bit processes, or when the generating process is a console application. For more information, see In-Context Hook Functions.

WINEVENT_OUTOFCONTEXT
The callback function is not mapped into the address space of the process that generates the event. Because the hook function is called across process boundaries, the system must queue events. Although this method is asynchronous, events are guaranteed to be in sequential order. For more information, see Out-of-Context Hook Functions.

WINEVENT_SKIPOWNPROCESS
Prevents this instance of the hook from receiving the events that are generated by threads in this process. This flag does not prevent threads from generating events.

WINEVENT_SKIPOWNTHREAD
Prevents this instance of the hook from receiving the events that are generated by the thread that is registering this hook.

Ref.: https://msdn.microsoft.com/en-us/library/windows/desktop/dd373640(v=vs.85).aspx

The following hooking methods all require .dll injection into the targeted process.

API/Function Hooking/Interception Using JMP Instruction

The following source code is an example of an API/function hooking method which hooks by overwriting the first six bytes of a destination function with a JMP instruction to a new function. The code is compiled into a DLL file then loaded into the target process using any method of DLL injection. Using a backup of the original function one might then restore the first six bytes again so the call will not be interrupted. In this example the win32 API function MessageBoxW is hooked.[1]

Internal IAT Hooking

The following code demonstrates how to hook functions that are imported from another module. This can be used to hook functions in a different process from the calling process. For this, the code must be compiled into a DLL file then loaded into the target process using any method of DLL injection. The advantage of this method is that it is less detectable by antivirus software and/or anti-cheat software, one might make this into an external hook that doesn't make use of any malicious calls. The Portable Executable header contains the Import Address Table (IAT), which can be manipulated as shown in the source below. The source below runs under Microsoft Windows.

Ref.: https://en.wikipedia.org/wiki/Hooking

Bottom line - as long as your HIPS protects all the above methods and you code your rules properly, you're covered against malware hooking activity.

 

No offense, but where do you see me claiming otherwise? I already explained, some tools like Trusteer and HMPA don't block code injection, they only block or detect the API hooking part. This means no user decision is necessary.

I will give an example. Years ago I used a download manager named Orbit Downloader. It had to inject code into the browser, otherwise it couldn't sniff and download files. So I had to allow it, but if it was a malicious data stealer, HIPS that can not block API hooking wouldn't be able to stop it. It would simply be able to steal data or even money via the browser, completely bypassing HIPS and firewall. You now see why it's so cool?

http://www.pcworld.com/article/2449...to-networking-apis-to-steal-banking-data.html

 

The only problem with monitoring API's absolutely that can do hooking type activity is a lot of false positives.

All HIPS's monitor API's; the difference between them is what API's they monitor and how they do the monitoring. Note that all hooking type activities require that a link be established between the source/malware and the targeted processes. This "link" can be a hard hook; e.g. using SetWinHookEX or SetWinEventHook or via establishing a thread between the two processes. This linking activity is done almost always via source to target .dll connection between the two processes. Again a good HIPS should have the capability of detecting this "linking" activity in the same way it would detect disk or memory based .dll injection into the target process.

Relating to the PC World article, the malware is injecting a .dll I assume using SetWindowsHookEX. Note that this API can also used for global .dll injection; not just hook injection:

The main Emotet component downloads a DLL file and injects it into all processes running on the system, including Web browsers. The file has the capability to monitor outgoing network traffic from those processes and look for strings specified in the configuration file.
​

I would be suspicious of any application based software performing hooking or .dll injection type activities. The type of software doing same should be security or disk backup related only.

-EDIT-

There is another type of "hooking" that we haven't discussed. Any global function such as GetActualKeyboardState can be mapped into a target process. However to do so, a handle has to be set in the WinInit area of the targeted process. Again, that is process modification and would be detected as such as long as a HIPS rule existed to prevent it.

​

 

@itman

What does this discussion mean in terms of using a product such as SpSFW vs ESET or COMODO ?

 

The best comparison is that SS and Defense+ HIPS's are user friendly. Both have an array of options that make creation of user rules relatively painless for the user. Both also have relatively strong default settings. I know there are a number of people will disagree but in comparison to creating rules in Eset, both are "child's play."

Eset's HIPS is akin to a HIPS from the stone age. It has next to zip functionality. For example, there are no trusted system processes categories or the like. There is no Installer or Win Updater modes you can switch to, etc. etc.. Its default setting of auto basically protects a few system and registry areas. The smart mode is not that much better. Its default rules are hidden, so you have no idea what the HIPS is protecting in its auto or smart mode. Some examples are you can't write protect the root directory itself of any directory tree; no wildcard support exists for file names such as *.exe; etc.. The HIPS also has a few bugs such as the habit of creating duplicate rules when running in learning mode. And the list goes on.

Its strong point is it has blocked any type of malware technique I have tested including memory based such as reflective .dll injection regardless of if the process is suspended or not. And it has done the blocking with zip impact on the process's existing operation. The HIPS also has good alerts and event logging. Note that I have extensive user rules that accomplish this total lock down state. Unless you have a lot of technical knowledge and time to test your configurations thoroughly, I would not recommend using it.

-EDIT-

Another "gem" of the Eset HIPS is how it creates rules in interactive or learning mode. It creates a rule for each specific action encountered. So for a given process, you could very well end up with a number of rules. Nor is there any ability in the HIPS to sort or manually position those rules by process name. This is one reason why I have created all my rules manually. This way, I can integrate into one rule all the actions I want to allow or block.

 

I decided to run Comodo Leak Test as a regular user. In this mode, I did pass the "knowndlls" path hijacking test. This confirms what was noted in the previous codeproject.com link I posted. Namely:

It should be mentioned that starting with Windows Vista it’s impossible to add directly a string parameter with the DLL path to the KnownDLLs registry hive, as the system protects this hive from record. But if the application is started with the admin permissions, the user can get the permission to write to this hive.
​

Important to note is if you run as a full/limited admin, any downloaded malware can get access to other globalroot areas; most importantly, your shadow volume backups. This is how ransomware can get access to those and delete them.

 

@Rasheed187

Here is the "ultimate solution" HIPS as far as monitoring APIs that can perform hooking activities - Malware Defender. If you have a 32 bit OS - Win 8 or prior, this is the puppy you want. Unfortunately, it is now abandonware since x64 PatchGuard was something the author didn't want to tackle.

With MD you can monitor process:

Hooks detector

Detects and removes system service table hooks (SSDT hooks).
Detects and removes Win32k service table hooks (shadow SSDT hooks).
Detects and removes interrupt descriptor table hooks (IDT hooks).
Detects and removes SYSENTER handler hook.
Detects and removes kernel object hooks.
Detects and removes kernel notify routines.
Detects and removes kernel mode code hooks.
Detects and removes user mode code hooks.
Detects and removes global message hooks.
Detects attached devices.
Detects hooked driver dispatch routines (IRP hooks).​

Ref.: http://www.softpedia.com/get/Security/Secure-cleaning/Malware-Defender.shtml

 

I believed that MD was discontinued since some years.

 

Shame too. This was/is a very good HIPS but again another one that didn't transition toward x64 and any move to 64 bit rigs made these type HIPS obsolete for those systems. On my XP though malware defender and EQSyssecure were mainstays and tightly controlled many vectors.

 

Yeah, well... it's too bad about Malware Defender and DefenseWall on 64 bit.

Emsi just got rid of Online Armor because it just didn't generate enough sales to justify additional development. Besides, they do a good job with their Behavior Blocker.

Anyhow, MD and DW are two great HIPS.

64 bit home users are essentially left with COMODO, ESET, Kaspersky and SpyShelter. Of course, there are a few Enterprise HIPS, but they aren't practical nor economical for the typical home user.

Just face it, HIPS is holding on by the finger nails.

 

Last change log was 2014.

 

McAfee has a standalone desktop firewall/HIPS for $33: http://www.mcafee.com/us/products/host-ips-for-desktop.aspx. Datasheet specs. are a bit confusing. The ones on the web page for the link I posted state Win 10 and below are supported. However, another link I accessed about the product says only Vista and below supported. So I would verify this with McAfee if interested. There is a free trial and there is no minimum license count required as is the case for many Endpoint products.

If this product employs the same HIPS used in other McAfee endpoint products, it would support rule definition at the API level.

 

Looked into it a few months back. Could find no 64 bit installer in the package. Plus, the installation directions are cryptic.

 

Yes, it was basically a HIPS combined with a HIDS. But like you said, it's harder to take full control of Win 64 bit because of PatchGuard. But with code injection and driver loading it's still possible to remain stealth especially when API hooking is involved. So you need to be absolutely sure that you trust a tool before allowing it to perform these activities, because PatchGuard can't protect against everything. That's why I hope we will get to see a hypervisor based HIPS.

 

That's why I asked what the ESET HIPS is monitoring, because based on the screenshots I already got the impression that it wasn't really user friendly.

Actually, most of the discussion was about what HIPS should be monitoring. The end conclusion is that it's not possible to block all attack techniques. But when it comes to blocking API hooking, only Webroot, Zemana and SS offer this feature.

 

I don't believe banking trojans make use of the SetWindowsHookEX method, because this is mostly related to global hooking used by keyloggers. Banking trojans and other advanced malware often use the standard WriteProcessMemory and CreateRemoteThread method.

I don't believe this is considered to be true hooking. This technique is used by message based keyloggers. Like said before, keystroke encryption will also block this.

https://www.qfxsoftware.com/