How are BBs different from HIPS?

[Handsome Recluse]

Are there any notable differences between the two aside from the scope of their protections?

 

[Wave]

Yes, a Behavior Blocker (also known as a BB) and Host Intrusion Prevention System (also known as HIPS) are a bit different.

The purpose of a Host Intrusion Prevention System (HIPS) is to monitor the running programs (e.g. the ones which have been set to be monitored by user-defined methods or if the program is unknown/appears to be suspicious based on static characteristics) and prevent specific behavior from being carried out based on the user's settings configuration for the HIPS rules (e.g. prevent new driver installations, prevent modifications to the Windows Hosts file, prevent suspicious memory attacks towards external processes, prevent new start-up entries, etc.).

The purpose of a Behavior Blocker (BB) is to monitor the running programs and based on the logged actions from that specific program, block actions based on how malicious the action is determined to be/match the logged behavior to a specific threat type (e.g. worm, backdoor, bootkit, etc.). Therefore, if I wrote a sample which was ran with administrative privileges (for the correct privileges) which then tried to open a handle and write to it for Master Boot Record modification (boot sector on the physical drive) then the Behavior Blocker may support monitoring of this behavior and prevent the sample from performing this action since it's very high up on the scales for determination of malicious activity; it may show an alert to ask the user what they want to do (and indicate the activity is definitely malicious-appearing as opposed to just suspicious), or it may auto-quarantine the sample.

They both differentiate since HIPS supports prevention of general activity which can be used by both genuine and malicious software, whereas the Behavior Blocker is meant to be designed and aimed towards only malicious software, by logging the behavior and identifying specific behavior which may be on-going based on the logged activity (since adding to start-up is not malicious, whereas attempting to write to the Master Boot Record to remove the boot signature so the system cannot boot properly or attempting to inject code into an external process is malicious behavior).

That being said, it's common to find both protection mechanisms working together and they are both very good dynamic protection methods to fight against zero-day malware; however to use a HIPS/BB properly, you need to understand what is going on and make the correct decisions. If you get an alert about a program attempting to do something and you make the wrong decision, then your system can end up toast anyway - therefore you cannot just auto-allow things or it'd be pointless, and some people really do this and ignore the security alerts.

As well as this, both protection mechanisms are usually developed with an identical method... The security product usually injects into the target programs and then performs API hooking methods to log which APIs the program is executing. However, the BB/HIPS can be further developed through the use of device drivers (which can be better for monitoring file modification attempts -> could be used to monitor ransomware encryption behavior).

I apologize for this basic explanation, hopefully it will be detailed enough for you to understand.

Hope this helped and stay safe,
Wave.

 

[AtlBo]

HIPS is blocks are based on a set group of rules from the security program that exist for each executable. You define which of the rules are or are not allowed for each executable. Behavior blocks are blocks based on the activity of a process. If your a-v has BB and notices a program attempting to change a driver, for example, you could be alerted to this. Depending on the HIPS rules in your security program, you would probably get a HIPS alert for the behavior too, but then there might also be others.

Good behavior blocking is better on pop ups than HIPS, because it's more focused on specific behaviors , such as those, for example, that might be associated with ransomeware.

Example. I think Private Firewall has 21 HIPS rules for each process. They are rules that permit or deny a process/executable from things like "create processes", "open processes", "monitor keyboard", "simulate input", or 'adjust privilege". Each rule generates its own pop up on the strict settings of the program, so the number of pop ups can be crazy honestly. Then it can be easy to be lulled into pattern of allowing once or allowing and remembering until you make a mistake.

With the good BB a-vs and the good anti-exe (VoodooShield and others) on the market now, I feel the best way to go is with a top BB and an anti-exe. BTW, anti-exe is sort of a misnomer I think in one way. That is that it can seem like it blocks everything, making choices difficult, but that's not necessarily the case. VoodooShield is a pretty smart application in this way. It will develop a whitelist and then also has cloud/VirusTotal analysis of files that it can use for helping users make decisions about what to block. Its pop ups are actually very helpful...VERY and meanigful, much more so than a standard HIPS alert.

The new Malwarebytes 3 looks exceptional in the tests I've seen as a behavior blocker. However, I'm not sure if it's that their sigs are that good or it actually is BB. Combine that with anti-exe, and system should be good to go.

 

[RejZoR]

Explanation simplified, BB is a clever system which identifies threats based on behavior, so it has a very high detection ratio with malware, but rarely ever gives a false flag of legit program.

HIPS, even more clever ones are just a dumb blocker following predefined rules and relying on user decisions.

 

[Wave]

HIPS, even more clever ones are just a dumb blocker following predefined rules and relying on user decisions.

How is HIPS a "dumb blocker"?

The purpose isn't to identify malware in itself but prevent restricted programs from performing specific actions on the system, therefore keeping you better protected against malicious software should the user use the component correctly... It's a good addition to work alongside a Behavior Blocker in the case of a program not providing sufficient evidence to be matched to a specific threat type, not to mention that some samples may just install a device driver (leaving the scope of monitoring since once you obtain kernel-mode execution it's game over), and monitoring driver installations is typically a rule within the HIPS component, however it isn't "malicious" to install a device driver with a Windows Service.

Of course the Behavior Blocker is smart and more useful in terms of malware mitigation however if they are both used together into one component (or two separate components working alongside) like how it is done in the Emsisoft Behavior Blocker feature then it can be really good and work well (e.g. start-up protection is a feature of HIPS and is not in itself malicious, the user may not want a program to do this without additional consent).

Sorry if I misunderstood what you were trying to say.

 

[RejZoR]

I have yet to see HIPS that's not annoying as hell or actually does anything other than just asking user with "dumb" questions like "Wanna allow that?". Which is why I'm so fascinated over behavior blockers. They are clever, aren't annoying and have superior protection in most cases.

 

[BoraMurdar]

Imagine system protected with HIPS as a house with a lot of rooms where most/or some of them are locked and you cannot enter.
System protected with BB is a house with almost all rooms unlocked but in every room a guy sits and waits you to make a wrong move

 

[Wave]

I have yet to see HIPS that's not annoying as hell or actually does anything other than just asking user with "dumb" questions like "Wanna allow that?". Which is why I'm so fascinated over behavior blockers. They are clever, aren't annoying and have superior protection in most cases.

I understand what you are saying better now, but that is the point in HIPS, because in some situations only the HIPS can protect the user as opposed to the BB based on sensible decisions. E.g. new driver installation (not actually deemed as "malicious" as it has genuine purposes however if it's allowed then potentially game over), hosts file modification (neither deemed as "malicious" as it has genuine purposes but blocking this can save you a lot of trouble), etc.

Whereas with the BB, it won't be triggered necessarily upon one action, but after a number to match the running program as actually being malicious. And depending on what the sample does, this may or may not ever actually happen.

But I agree that a Behavior Blocker is smart and better overall.

 

[AtlBo]

I have yet to see HIPS that's not annoying as hell or actually does anything other than just asking user with "dumb" questions like "Wanna allow that?". Which is why I'm so fascinated over behavior blockers. They are clever, aren't annoying and have superior protection in most cases.

And they are sure to be followed by more. Anyway, HIPS rules can get better with time in security software. I don't think the concept is 100% developed so to speak. If I look back at Private Firewall from 2009 or 10, it's HIPS rules are crude by the standards of many of today's security programs. I expect they'll get even better as time goes on, and we won't even understand the old block me 5 time HIPS rules.

Only problem with that for me is when developers reach into another area of security, in this case BB, to then turn it into HIPS. The change can be shrouded in mystery and the setting and choice difficult at least sometimes for me to understand.

 

[shmu26]

some antivirus programs incorporate a function that they call "HIPS", but it really fits the definition of BB.
An example of this is QIHOO 360 "HIPS" protection.
In Kaspersky, if you run it at default settings, the HIPS acts like a BB, but at custom settings you can bring alive the true HIPS capabilities.

 

[AtlBo]

For sure 360's HIPS is BB in my opinion, also. The logs kind of say so with File Protection, Behavior Blocking, Downloaded Files protection, and Web Threat protection logs. No mention of HIPS there, although I guess there may be HIPS elements that contribute to the block events at times. If so, the logs don't indicate so.

 

[Wave]

For sure 360's HIPS is BB in my opinion, also. The logs kind of say so with File Protection, Behavior Blocking, Downloaded Files protection, and Web Threat protection logs. No mention of HIPS there, although I guess there may be HIPS elements that contribute to the block events at times. If so, the logs don't indicate so.

It's a mixture of both, since it may ask for your consent to allow/block something which in itself is not actually "malicious" (but could potentially be abused for malicious intent), whereas other things it may alert about (e.g. ransomware identification) may indicate the program really is malicious due to the behavior being matched to something specific.

Therefore, when you get an alert for the webcam protection (I believe 360 has such a feature - correct me if I am wrong) then this would be something to expect in a HIPS component, whereas the component is linked together with protection against ransomware also (and many other features are included such as keylogger protection, etc.) and that would be an example of a Behavior Blocker feature, since it's matched to protect against a specific threat type/behavior which really is deemed to be "malicious".

It's essentially a mix of HIPS/BB features into one component which is perfectly fine and actually a good idea, and for the luck of the Qihoo employees it turns out to work quite neatly.

 

[AtlBo]

It's a mixture of both, since it may ask for your consent to allow/block something which in itself is not actually "malicious" (but could potentially be abused for malicious intent), whereas other things it may alert about (e.g. ransomware identification) may indicate the program really is malicious due to the behavior being matched to something specific.

Yep, I forgot about the webcam protection in 360. Actually, I guess I am accustomed to Private Firewall and thinking of anti-keylogging as HIPS. It's one of its 21 HIPS cats. If anyone gets bored one day, run a system with PF with the HIPS on and set the alerts to show for all events. I went with this set up for four years . Oh yes, try installing Blue Stacks, making sure to "allow and forget" so the installer won't show up in the rules dialog. Using PF is like using Windows XP...brutality, but I did it this way to learn about the paths of data through Windows, and I think it helped some.

 

[aliali]

comodo( hips)malware detected

 

[AtlBo]

Smart detection from HIPS . Must have been attempting to alter shell code or change a protected registry setting or something. Maybe I will test the HIPS of CF more once I get used to the sandbox.

 

[Wave]

comodo( hips)malware detected
View attachment 128450

No, it hasn't detected malware, it's identified suspicious behaviour which makes it question the intent of the program (e.g. whether it is malicious or not) - this is even stated on the alert.

HIPS does not identify malware, that is the job of the BB (if there is one). Of course, they can be mixed together to be one component.

 

[AtlBo]

Thanks for the clarification. I was going with the assumption (never a good idea for me!) that aliali had determined on his own that it actually was malware or knew, as in a malware sample. Basically, I thought he was implying the HIPS rule stopped the process and he then blocked it stopping an attack (as in HIPS was good enough for this situation), although I can see how your view of the pop up is 100% correct that it is not a detection.

Conclusion--Smart HIPS is smart user + HIPS

 

[Wave]

I was going with the assumption (never a good idea for me!) that aliali had determined on his own that it actually was malware or knew, as in a malware sample.

It probably is genuinely malicious, and based on the file-name I am assuming he got it from an external source providing packs of malware (or a list of downloadable samples), maybe VirusSign (since such services make sure the file-name is something like a checksum hash of the file)? (@aliali can you confirm?)

And you are definitely 100% right: Smart HIPS is a smart user + good HIPS, because if the user makes the wrong decision then nothing can save him/her.

 

[509322]

The inherent problem with classical HIPS is that it will generate essentially the same type of alerts for both safe, legitimate files and malicious ones. The user then has to make all the decisions to Allow, Block (what type of block), and whether or not to create permanent rules based upon what they know about the file. Most users cannot differentiate between a safe and malicious file's actions from within the HIPS alerts themselves.

How to handle a file with HIPS begins with a pre-execution file inspection - where was it downloaded from ?, is it digitally signed ?, is the certificate a valid one ?, is it detected on VirusTotal ?, etc. Even then, every single file check can fail a user - from novice to those with heavy experience. Plus, it is considered way too much work and the vast majority of users will not perform a pre-execution inspection. Since most people will not bother with the file checks, it is rather pointless for them to use HIPS because it isn't going to protect the system if the user makes the wrong decision and executes a dodgy file and doesn't use the HIPS conservatively or properly.

Even HIPS with "smart" policies will allow things that it shouldn't and the end result is an actively infected system. Behavior Blocker is triggered by specific actions - as opposed to generic "smart" policies.

The only important HIPS alert for most people is the very first file execution alert. At that point, the user must decide to Allow or Block.

If one is surfing the web, and all of a sudden they see a HIPS alert for p9af8hrpe915.wfs, the right thing to do is block. But it should not come as any surprise that a significant percentage of users will select allow all the way through the run sequence.

Classical HIPS is a very good tool for controlling the execution of Windows processes that can be used to smash the system. Only an experienced user is going to know that RegAsm.exe, vbc.exe, powershell.exe, etc should or should not be executing under the specific circumstances of what they are doing on their system at the time of the alert.

 

[shmu26]

The inherent problem with classical HIPS is that it will generate essentially the same type of alerts for both safe, legitimate files and malicious ones. The user then has to make all the decisions to Allow, Block (what type of block), and whether or not to create permanent rules based upon what they know about the file. Most users cannot differentiate between a safe and malicious file's actions from within the HIPS alerts themselves.

How to handle a file with HIPS begins with a pre-execution file inspection - where was it downloaded from ?, is it digitally signed ?, is the certificate a valid one ?, is it detected on VirusTotal ?, etc. Even then, every single file check can fail a user - from novice to those with heavy experience. Plus, it is considered way too much work and the vast majority of users will not perform a pre-execution inspection. Since most people will not bother with the file checks, it is rather pointless for them to use HIPS because it isn't going to protect the system if the user makes the wrong decision and executes a dodgy file and doesn't use the HIPS conservatively or properly.

Even HIPS with "smart" policies will allow things that it shouldn't and the end result is an actively infected system. Behavior Blocker is triggered by specific actions - as opposed to generic "smart" policies.

The only important HIPS alert for most people is the very first file execution alert. At that point, the user must decide to Allow or Block.

If one is surfing the web, and all of a sudden they see a HIPS alert for p9af8hrpe915.wfs, the right thing to do is block. But it should not come as any surprise that a significant percentage of users will select allow all the way through the run sequence.

Classical HIPS is a very good tool for controlling the execution of Windows processes that can be used to smash the system. Only an experienced user is going to know that RegAsm.exe, vbc.exe, powershell.exe, etc should or should not be executing under the specific circumstances of what they are doing on their system at the time of the alert.

seeing as that first prompt, the one for the initial execution, is the crucial one, what would you say are the vulnerable processes that should a user not be seeing under normal circumstances?
I guess this would divide into two categories: the processes that can safely be blocked altogether, and the processes that should only be seen in certain given circumstances.