Classical HIPS and policy based HIPS discussion

Good reading material.

@Peter2150 Shades of the old nemesis KillDisk by chance?

 

Yes of course, all malware has to be able to run, but HIPS are the last line of defense. HIPS can block stuff even when malware is active on the system, and we all know that AV's will never be able to identify 100% of all malware. That's why I became fascinated by HIPS.

 

Yes I know, but I don't have the resources, I don't know where to download samples, and VMware is expensive as hell. There are so many malware experts and not one of them is testing HIPS like SS and Zemana against advanced malware. Perhaps this is something that MRG can do in the future, I do like their anti-banking trojan tests. And yes, the Comodo Leak Test is quite extensive, but the last time I tried I got a BSOD.

https://personalfirewall.comodo.com/cltinfo.html

 

No, PatchGuard blocks modification to the OS kernel, but rootkits can still hook drivers. Drivers run in kernel mode, so that's why I call it "kernel mode hooking". But from what I've understood, it would probably be too risky to monitor this stuff, because if HIPS would start to block hooking of drivers it could make the system unstable. So basically, rootkits and other advanced malware can still use methods like user-mode and kernel-mode hooking, even with PatchGuard enabled. You should read this stuff:

http://www.adlice.com/userland-rootkits-part-1-iat-hooks/
http://www.adlice.com/kernelmode-rootkits-part-2-irp-hooks/
http://www.adlice.com/kernelmode-rootkits-part-3-kernel-filters/

 

If I'm correct, you need to run a (malicious) driver in order to hook ndis.sys, would be really cool if HIPS could block this. Or perhaps M$ could make a system that watches for this. To clarify, I'm talking about blocking the malicious hooks, not driver loading itself.

On the other hand, I don't know if it's normal behavior to hook the ndis.sys driver, that's the big problem. That's why HIDS (not HIPS) is also important, I'm really missing a good "expert" anti-rootkit tool for Win 8.

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

 

SS is a classic HIPS, so is Zemana. The thing is, I like to depend on my own expertise, that's why I love HIPS. EIS has a behavior blocker that will probably stop most malicious behavior, but HIPS give full control which gives you the ability to block unwanted behavior even from non-malicious tools. AppGuard can't be compared to HIPS, it's more about containment.

The thing is, when you run or install some app, you have already made the decision that it's probably safe to run. So tools like AppGuard and AV's are out of play. But if apps exhibit suspicious behavior, only HIPS can alert you about it. But you do need the expertise, because it all depends on being able to recognize what's normal behavior and what's not.

 

@ itman

You should also read this, it shows why code injection is so dangerous. Carperb tried to kill the Trusteer protective browser hooks. But Trusteer fixed it, so apparently it's possible to protect your user mode hooks. If Trusteer is attacked, the browser will simply freeze.

That's why HMPA does not actually block API hooking of the browser, it only detects and alerts. According to the developers that's a better approach, instead of simply freezing the browser. I'm not sure how Zemana and SpyShelter would handle such an attack.

http://www.adlice.com/carberp-anti_rapport-beating-trusteer-protection/
https://securityintelligence.com/ib...-effectively-resists-carberp-bypass-attempts/

 

I believe most HIPS's protect anything in C:\Windows\System32\drivers\* by default? If in doubt, you could always create a rule to prevent process modification and global hooking against anything in C:\Windows\System32\drivers\*. Here's a C++ program you could modify and use to do API hooking against one of your drivers to test your HIPS rule: https://www.unknowncheats.me/wiki/C++:Make_Your_Own_DLL_Hack_-_2_-_WINAPI_Hooking . -EDIT- I believe this will only do user mode hooking. For kernel mode hooking you can use EasyHook: http://easyhook.github.io/

I believe Comodo Defense+ protects against both user and kernel hooks:

Windows/WinEvent Hooks - In the Microsoft Windows® operating system, a hook is a mechanism by which a function can intercept events (messages, mouse actions, keystrokes) before they reach an application. The function can act on events and, in some cases, modify or discard them. Originally developed to allow legitimate software developers to develop more powerful and useful applications, hooks have also been exploited by hackers to create more powerful malware. Examples include malware that can record every stroke on your keyboard; record your mouse movements; monitor and modify all messages on your computer; take over control of your mouse and keyboard to remotely administer your computer. Leaving this box checked means that you are warned every time a hook is executed by an untrusted application (Default = Enabled).​

You bring a topic that isn't discussed much on Wilders; just how secure are your security solution hooks. You can use a tool such as the one I discussed previously that not only will inject a .dll into a process but will also remove a .dll to see if the security solution hook can be deleted. Again a HIPS rule to prevent process modification will prevent either activity.

 

Yes but that's not what this topic is about. And SS and Zemana have been in business for about 8 years I believe. Probably because they have marketed their tools as anti-loggers and not HIPS. Plus they give an option to disable certain HIPS modules, a very smart move.

 

Yes but keep in mind, that Trusteer will protect their user mode hooks even after malicious code injection. I believe it's probably done via the protection driver. I wonder if tools like HMPA and SBIE are also protecting their user mode hooks.

 

You're misunderstanding. User-mode hooking (after code injection) can already be blocked. But hooking of drivers (kernel-mode hooking) can not be blocked, at least not without any risk to system stability. And hooking is done in memory, so protecting against modification of drivers on disk won't help.

To give an example, a tool like Hide Folders will use a driver to hide and lock folders. But none of the HIPS will alert about this. However, Zemana and SS do have the capability to block kernel mode keyloggers, probably by monitoring the keyboard stack, see the second link.

http://fspro.net/hide-folders/
http://www.adlice.com/kernelmode-rootkits-part-3-kernel-filters/

 

I updated my posting to include EasyHook that will do kernel mode hooking.

 

Yes, I saw that one, but I believe it's a bit too advanced. And BTW, can you perhaps post which behaviors the ESET HIPS is monitoring? Speaking of HIPS and leak testing, these are the behaviors that any HIPS should cover:

http://www.testmypcsecurity.com/lea...5sk1=d5bff129ae164ae0c62d8bac87a0c3fb5cfb852f
http://www.matousec.com/info/articles/introduction-firewall-leak-testing.php
http://www.matousec.com/info/articles/features-of-modern-security-suites-part-2.php

 

@ itman

This is a great article about process hollowing:

http://www.adlice.com/runpe-hide-code-behind-legit-process/

 

No you're misunderstanding, those hooks are related to global hooks often used by key-loggers. User and kernel mode hooking is entirely different. Of course, if you simply block code-injection and driver loading, then user/kernel mode hooks are blocked, but 'm talking about blocking malware from API hooking AFTER they have already performed those activities.

 

Here's a detail analysis of an "oldie but goodie" nasty, Win32/Gapz, that literally does it all; bootkit, rootkit, kernel mode injection, you name it: http://www.welivesecurity.com/wp-content/uploads/2013/05/CARO_2013.pdf

 

Best of the bunch for memory code injection is Comodo Firewall Parent Injection Leak Test. It will attempt to inject explorer.exe's memory. Emsisoft's behavior blocker detects it by behavior and quarantines it. And yes folks, EAM/EIS does protect you against memory code injection. In this case, it submitted the .exe to the cloud which didn't recognize it by reputation. So, the BB immediately clicked into gear.

That said, this Comodo test is a good one to test your HIPS process modification rule for explorer.exe.

A bit of warning. Not all these tests are benign. The Comodo tests for the most part are. The Matousec tests are not and could damage your OS installation. Ditto for any downloads for non-Comodo or Matousec tests.

 

Oh, no! Here we go again - process hollowing.

This write-up looks vaguely familiar to me. Again HIPS mitigation is:

1. Monitoring vulnerable processes for process start-up.
2. Monitoring vulnerable processes for process modification.

 

BTW - Wilders member, Cutting-Edgetech, posted in another forum I believe, that he achieved a score of 300/340 for ESET HIPS in Interactive mode using the standard Comodo LeakTest suite. In other words, this is the highest score achievable for the Eset HIPS. I am glad to post that I have achieved the same score using my Eset HIPS custom rule set running in non-interactive mode.

A bit about Comodo Leak Test suite here and reasons why results might be unpredictable when not specifically testing Defense+ for which it was developed for: https://forums.comodo.com/leak-test...ting-accurate-leak-test-results-t61715.0.html. Another important point I found on another forum is any security product with a sandboxing element, internal or external, will affect the Leak Test results. Eset's advanced heuristics does use an internal sandbox. Additionally, the Leak Test suite was developed for 32 bit apps and is 8 years old. In other words, it predates browser sandboxing that is common today.

The best 64 bit current leak test suite is the one Matousec used for its product testing. Again, this suite should only be used on machine where an image backup was done prior to testing. Also factored in is the high likelihood the testing will trash your current Win installation.

 

The question is "Why would you want to do it that way?" Win API monitoring of any type is risky due to the high likelihood of false positives. And, aside from monitoring API's that are associated code/memory injection is not recommended.

-EDIT-

McAfee Endpoint will allow you to monitor WIN API calls. You can use the "open_with_directive" option. Again, the recommendation is to monitor only API's that perform code/memory injection for vulnerable processes:

PROCESS_VM_OPERATION For VitualAllocEx/VirtualFreeEx
PROCESS_VM_WRITE For WriteProcessMemory
PROCESS_CREATE_THREAD For CreateRemoteThread

 

Actually, MRG did test "in the wild" rootkit remediation in a Zemana commissioned test; note that. The results weren't especially encouraging with ZAM scoring the highest(of course) with a score of 24/30 or 80%. Ref.:https://www.mrg-effitas.com/wp-cont...-Remediation-Comparative-Analysis-2015-Q3.pdf

 

We've discussed Trusteer at length here on Wilders.

Broadly speaking, Trusteer offers two protections; browser lockdown and unbreakable MITM protection in restricted configurations. Other security products now offer banking mode browser lockdown protection. If your bank has Trusteer software installed on its servers, a secure "tunnel" will be established between your PC and the bank's server. This will prevent any type of external MITM activity. This is what makes Trusteer unique.