Classical HIPS and policy based HIPS discussion

Found two great utilities to analyze your MBR.

The first is from Eset and it also will find hidden files: http://www.eset.com/int/download/utilities/detail/family/173/

The other is from Emsisoft. This will also create a report on your desktop that will create a hash of the MBR for each drive. If you get by a suspected rootkit, you can run the utility again and compare the current hashes to the original report: http://tmp.emsisoft.com/fw/mbrmastr.exe

Both utilities are stand-alone .exe's that need no installation. And guess what? They both use direct disk access. So running them is a great check for your direct access blocking HIPS rule. Starting to get the picture? Any malware going after your MBR, VBR, etc, needs to do so using a low-level disk access method.

Also see this Widers thead: "VirusTotal Adds Support for Scanning Malicious Firmware Images." As noted, having a flash compatible media BIOS backup is recommended. My PC still has a floppy drive. A dual BIOS motherboard is also nice.

 

Yes but none of those tools use HIPS, they detect by signature.

 

Good thinking, so it's very likely that HIPS can protect against tampering with the MBR and VBR.

You want to do it, because after you have allowed driver loading or code injection, it's normally game over if they are both used in a malicious way. That's why the protection offered by Zemana, SpyShelter and Trusteer against banking trojans was quite revolutionary. They were the first one to monitor user-mode API hooking after code injection. But currently, not a single HIPS monitors driver-mode API hooking. So rootkits can still use this method without getting caught. M$ should really release a tool to monitor the kernel, something like Tuluka.

http://www.tuluka.org/screenshots.html

 

LOL, this seems to be a very nasty boot/rootkit. But that's exactly what I meant, not once does ESET mention if their HIPS could block some or all of the techniques that's being used. A couple of things that I noticed:

- It seems to make use of a non standard way of code injection into explorer.exe
- It hooks disk drivers (kernel mode hook) to protect the infected MBR/VBR and hidden file-system
- It makes use of process hollowing to start and hide the payload
- It hooks networking API's in svchost.exe (user mode hook) to hide network traffic
- It uses low level/direct network access to bypass HIPS and firewall

 

Pity, it is abandonware so far.

 

You said this previously - "if you block the code injection, there is no need to worry about API hooking." This is what the HIPS does - block the code injection. Think of the "cart before the horse" analogy. Here's a better one. If I can keep the invaders from breeching the perimeter, my fort is safe. But once inside the perimeter, my fort is "toast." I might be able to eventually repel the invaders, but the fort might be beyond repair.

If the malware first can't start let's say explorer.exe in a suspended state, it's game over at that point. If the malware can't modify explorer's memory or inject a .dll, it is double game over. Eset with custom rules will prevent all the above. Eset running in interactive/policy mode will prevent all the above.

 

You're missing the point. The whole point is to block malicious actions even if you have made the wrong decision to allow code-injection or driver loading. Because we all know that all of these actions can be used by both malware and legitimate apps. It's the same thought behind PatchGuard, even if a malicous driver is loaded, the Windows OS (64 bit) will block the rootkit from hooking or modifying the kernel.

BTW, I forgot to mention Webroot/Prevx, they were also one of the first to block API hooking (after code injection) to protect the browser against SSL logging. And back in the days there were some anti-loggers who could block key-logging even when global hooks were loaded. So basically this means that even when malware is inside the perimeter, your fort is still being defended.

 

I partial agree with you.

However, API monitoring is easier said than done. Here is a link to a commonly used API monitor used primarily for code debugging: http://www.rohitab.com/apimonitor . Note that it comes preloaded for detection of over 13,000 API's! Again, it is extremely difficult to distinguish legitimate from malicious API hooking. If it were so, it would already be employed in most security products.

Finally, API hooking is done by HIPS and behavior blocking products but only on a limited basis; primarily intercepting well known hooking techniques used by malware. I previous described API's used for code and memory injection.

You can create your own API monitor using MS's Detours for example. I wish you luck on that task.

Eset's HIPS in ver. 9 will also block keylogger associated API's due to the now permanent setting of its own hook in the browser. It didn't do so in previous versions since the hook was only set dynamically when suspicious activity was detected.

 

@Rasheed187 Here you go: http://read.pudn.com/downloads161/doc/727064/keylogr.pdf . Scroll down to 'Section 3 - Kernel Based Keyboard Filter Driver.' That is what you need. That section also gives the Win API's the filter should be monitoring. This will also prevent rootkit based keyloggers. Time to get cracking with the code ...........

BTW - kernel based keyloggers will attempt to install the same type of driver. A decent behavior blocker or HIPS should prevent this.

 

Thanks for this. Hope I can implement this info with SpyShelther (first time user).

 

Here's another good read on rootkits:

Phase 5 Kernel Root-kits – Many of the ideologies programmed thus far also apply to kernel root-kits. Hooking kernel functions is a common method, and behaves just as its user-space counter-part. Excellent uses of this are to circumvent firewalls by interacting directly with the network stack. A common way to do this is by creating a separate network device driver. The driver allows the root-kit to have its own IP Address separate from the one being watched by the firewall, as well as its own
separate interface mapped to the same piece of hardware.

Ref.: http://www.usna.edu/Users/cs/cstech/tr/reports/2010-02.pdf
​

 

Thanks, will check it out and report back.

You're misunderstanding, SS already protects against this stuff. It protects against hook and message based loggers with behavior blocking and with keystroke encryption. It also blocks kernel based keyloggers, by monitoring system drivers related to the keyboard.

 

Yes of course, you can't monitor all API's. That would give a lot of false positives. That's why HIPS are mostly focused on network API's (user mode) inside browser memory. But in theory you could also focus on API's that are being used to hide processes and drivers for example. Then we are talking about kernel mode driver hooks.

 

Here's a good technical article on keyloggers: ref.: ref.: https://securelist.com/analysis/publications/36358/keyloggers-implementing-keyloggers-in-windows-part-two/ . Some additional API's of note:

Nearly all types of hooks are of potential interest to the creators of keyloggers: WH_KEYBOARD, WH_KEYBOARD_LL (hooking keyboard events when they are added to the thread event queue), WH_JOURNALRECORD and WH_JOURNALPLAYBACK (writing and producing keyboard and mouse events), WH_CBT (intercepting multiple events, including remote keyboard events from the system hardware input queue), WH_GETMESSAGE (intercepting an event from the thread event queue.)
​

As long as the keylogger monitoring driver executes prior to any of the system keyboard drivers, it can monitor all activity.

Note that Kapersky will catch all types of keyloggers but has to be configured properly. The article describes how to do that.

​

 

@Rasheed187 - Rather than "reinventing the wheel", there are two products I know of that will allow for low level system monitoring.

The first is McAfee's Host IPS which I mentioned previously. More detail on that:

How does Host IPS protection work?

Host IPS protection monitors executable system calls made using Application Programming Interfaces (APIs) on the protected system. These system calls are made to/from the operating system kernel for processing resources. Host IPS monitoring detects anomalies in system calls and blocks or logs those calls for analysis. Host IPS uses several monitoring Class engines to achieve this goal. For information regarding the Buffer Overflow, Files, Hook, Illegal API Use, Illegal Use, ISAPI, Program, Registry, Services, and SQL engine classes, see the following:

Host Intrusion Prevention 7.0 - Writing Custom Signatures: https://kc.mcafee.com/corporate/index?page=content&id=PD22525
​

The second is a little known but extremely powerful open source product that must be installed on a server. This puppy can monitor anything:

Ambush IPS

A new and dramatically more flexible host intrusion prevention system able to act on virtually any behavior. It can observe any Windows function calls, stop whole classes of attacks, and leave attackers with no idea what could hit them next.

Ref.: http://ambuships.com/details.html

​

 

@itman Have you used ambush, server code is not updates since 2013 ?

 

No, I haven't. But its forum is still active and the developer does respond to installation issues.
Developer recommends Bitnami server.

 

@Rasheed187 - Let's discuss kernel mode keyloggers since that appears to be your concern. Here's a link to code for a kernel based keylogger: http://forum.sysinternals.com/need-source-code-keylogger-kernel-mode_topic20875.html . This can be used for Win API reference.

However is not the best way to block kernel mode keylogging activity to block the loading of keylogger's own driver? Does not a product like Driver Radar Pro not do that? Additionally, a product such as Emsisoft with its behavior blocker will block the dynamic driver loading by malware.

 

No, I'm not concerned about kernel-mode keyloggers specifically. But I'm trying to figure out how HIPS can become even more powerful. Like I said, they can already block user-mode hooking, it would be interesting to see if they can also block kernel-mode hooking. This would mean that HIPS would still be able to protect the system even after code-injection and driver loading, two of the most used methods by advanced malware. So that's what this discussion was about.

 

Eset can only block global hooking i.e. SetWindowsHookEx and it must be explicitly coded in a HIPS rule. I have a feeling this is true for most HIPS unless they have an API interface such as the "set directives" option for McAfree Endpoint previously mentioned. I believe the anti-keyloggers like Zemana and Spyshelter have such API interfaces and target hook functions used by keyloggers. BTW - here's a MS ref. to all the hook and their functions: https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx . Almost all the keylogger hook functions are associated with SetWindowsHookEx. So HIPS blocking of SetWindowsHookEx will cover you on that regard.

What you're after are what is called "API Hooking." A good explanation of this here: https://books.google.com/books?id=MTcep7V6heUC&pg=PA159&lpg=PA159&dq=win+api+used+for+kernel+hooking&source=bl&ots=C3wgm1Sag2&sig=6-N3f02y3Pv_MEw2EIDEBWXZ68w&hl=en&sa=X&ved=0ahUKEwiX46OVhNrKAhVBkoMKHXE8BKEQ6AEIWjAJ#v=onepage&q=win api used for kernel hooking&f=false

"Both user and kernel mode rootkits use API hooking. The difference is user mode rootkits can only modify tables used by user programs on a per program basis. Kernel mode rootkits can achieve the same result by hooking a single structure all programs use."
​

So to be precise, it is not the hooks that are user or kernel level, it is the rootkit that is operating at a user or kernel level.

​

 

Yes exactly, I'm talking about API hooking, like I said that's not related to global hooking like in this link:

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

I know what you mean, but that's not entirely correct. If you hook the browser it's a user-mode hook, but you can also hook driver functions, that's a kernel-mode API hook.

 

BTW - Trusteer Rapport blocks keyloggers by encrypting your keystrokes so that keyloggers cannot read sensitive information. That is it; nothing more exotic than that.

 

Actually, this won't help against banking trojans running inside browser memory, so it also blocks API hooking. Blocking of API hooking (after code injection) was a major new feature introduced by HIPS, old skool HIPS like System Safety Monitor couldn't do this.

But I still wonder how SpyShelter manages to block API hooking, since it doesn't seem to inject code into the browser. It doesn't actually hook the browser, like Trusteer and G Data BankGuard. I don't know about Zemana.

 

It's API call interception by rootkit to modify process table data. If you wish to call that "hooking" that's OK.

 

That's how everyone is calling it.