How are BBs different from HIPS?

[509322]

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.

There is a vulnerable process list here at MT and over at Wilders.

It's the best place to start.

 

[shmu26]

There is a vulnerable process list here at MT and over at Wilders.

It's the best place to start.

my problem with that list is I don't know which processes can be permanently blocked, and which should be monitored but not blocked. For instance, if you block rundll32, you are going to run into trouble, although it is a good process to monitor.

 

[aliali]

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.

The a malware sample
comodo very poor Behavior Blocker But very good hips

 

[509322]

my problem with that list is I don't know which processes can be permanently blocked, and which should be monitored but not blocked. For instance, if you block rundll32, you are going to run into trouble, although it is a good process to monitor.

You won't get into trouble blocking anything except critical windows processes such as winlogon, csrss, smss, etc. Block those and you'll brick your system. But those processes aren't on the list. Blocking most things isn't that big of a deal. Nothing is permanently broken since it can easily be unblocked.

rundll32 should be allowed to execute either with or without limited rights. It is up to the user how tight they want to make their security. msiexec.exe should be allowed to execute without restrictions because it will block Windows updates. The others on the list should be blocked\disabled if not needed on a regular basis. If you need any of those processes, re-enable it, do what you need to do, then promptly disable it again afterwards. If you need one on a frequent basis, then just allow it permanently.

The only way you are going to learn is by doing. There are no resources out there that will explain step-by-step "how to do this."

It's not rocket science.

 

[AtlBo]

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.

Good question. What about this? What are the vulnerable processes that are most difficult to protect? How can we build a strategy to protect them each individually?

Something else maybe...what are the most vulnerable/hackable/injectable types of files (maybe even down to what type of a type of file) and how can we protect them? This one I guess has been asked since protecting .dlls and driver files has been around since the late 90s or something like that? I remember that security programs that attempted to do this were just as likely to break Windows or break themselves and crash back in my first recollections of the concept. I wasn't focused on security at the time. Only interested.

 

[Wave]

What are the vulnerable processes that are most difficult to protect? How can we build a strategy to protect them each individually?

Well, processes like winlogon.exe, csrss.exe, smss.exe are much better protected these days (since Windows 8) since they became "protected processes". They are being protected by mechanisms from a kernel-level, therefore you'll be unable to obtain a handle to those protected system process from user-mode... However, explorer.exe is still not a protected process and can potentially be abused, and this is not a flaw by design - it's done since explorer.exe may need to restart and if it is a protected process then it cannot do this if the user needs to do it themselves, etc. (It's also not running with admin privileges for security purposes - this is why the user needs to provide UAC consent when attempting to access protected directories, etc).

However, processes like wscript.exe and cmd.exe can be abused for malicious purposes... I would just follow that @Jeff_T - Testing Group said about them, since he knows a lot about this section.

what are the most vulnerable/hackable/injectable types of files (maybe even down to what type of a type of file) and how can we protect them? This one I guess has been asked since protecting .dlls and driver files has been around since the late 90s or something like that?

I believe that protection against DLL injection/driver loading was introduced with Windows 2000 however I could be wrong with this, I started developing from XP so I am not actually sure. However, any executable can be injected into, and any file which is going to be used for a specific purpose can be modified for malicious intent - e.g. a PE (Portable Executable - format is *.exe) can be injected into both statically and dynamically (e.g. patch the executable to have your own code executed before the actual programs code or inject dynamically to get code execution within the address space of the process on a new thread/hijack an existing thread).

I remember that security programs that attempted to do this were just as likely to break Windows or break themselves and crash back in my first recollections of the concept.

This is still the case! When security software load device drivers to perform kernel-mode patching techniques, if something goes wrong then it can start causing BSoD crashes (e.g. they mess up in the callback and cause the system to hang or even crash, forget to un-register the hook on the DriverUnload routine so when the driver is forced to unload manually it causes BSoD crash, etc). Regarding user-mode hooking methods, this can cause instability in running programs (and may result in them crashing) when there is a problem with the code.

That being said, testing takes a lot... Effects can be different for everyone, and everyone may be using different software combinations (opening a door for unknown software compatibility problems - therefore conflicts start occurring).

Injection/hooking overall can be a very unstable thing since it's manipulating the execution flow (controlling memory), however can be very good and useful if done correctly with lots of testing being performed to make sure it's done safely. (I mention hooking since this is usually common for a number of things: self-protection, BB/HIPS monitoring, sandboxing, etc.).

Sorry if I misunderstood what you were actually asking about.

 

[AtlBo]

Really helpful. Thanks once again Wave. Yes, that was exactly what I was asking.

I do think there were some crazy breaches in Windows 98 and in 95 too with .dll injection and manipulation. I can't remember. Lots of it was associated with floppys, but there was definitely a very dark side to the internet by 98. I guess it was the beginning of what we see today with seriously commercialized hacking and mal-coding.

 

[509322]

Good question. What about this? What are the vulnerable processes that are most difficult to protect? How can we build a strategy to protect them each individually?

Something else maybe...what are the most vulnerable/hackable/injectable types of files (maybe even down to what type of a type of file) and how can we protect them? This one I guess has been asked since protecting .dlls and driver files has been around since the late 90s or something like that? I remember that security programs that attempted to do this were just as likely to break Windows or break themselves and crash back in my first recollections of the concept. I wasn't focused on security at the time. Only interested.

There is vulnerable process list here at MT and over at Wilders.

There is no complicated strategy.

If you don't need it, then disable it. If needed, allow it - either temporarily or permanently based upon your needs.

Nothing gets broken.

You have to learn by doing = trial-and-error.

There is no step-by-step "how to do this" guide out there.

 

[jamescv7]

This topic as been discussed on MT way back before and let it simplify since all members who post here are right on the difference of BB and HIPS.

HIPS can prevent certain events in wide perspectives,which why it will halt the execution of program fully once you are not agree on the part of behavior.

Meanwhile BB blocks any suspicious behavior however if the program blocks the payload only then chances of infection is present.

Nowadays all AV focuses to detect the file from main source itself rather payload to ensure halt operation.

 

[frogboy]

A great thread thanks to all I have learned a lot here today.

 

[Behold Eck]

Am I the only one here that doesn`t get inundated with HIPS alerts (Comodo firewall on "clean pc mode") ? Outpost Pro on my desktop is a bit more chatty but nothing too annoying.

Then again maybe it`s the way you use your pc i.e. constantly installing new programs or games then maybe a HIPS would be a bit of a pain.

Regards Eck

 

[Handsome Recluse]

Are Behavioral Blockers a subset of HIPS?

 

[509322]

Are Behavioral Blockers a subset of HIPS?

Basically

 

[AtlBo]

Behavior blockers are sort of like HIPs except they monitor for specific activity outside of normal HIPs boundaries and also exclusive/independent of the rules of HIPs (even a HIPs allow typically will not lead to a BB allow-my experience ). This is my perception.

So security program monitors certain actions in a manner similar to HIPs but that aren't covered by its HIPs rules (if it has such). Program then applies specific protections based on run-time activity that tests these rules. This is how I see BB. BB is directed toward a specific type of protection/run-time behavior rather than toward generalized protection or part of an overall protection scheme.

If I described a term "smart HIPs" it would be BB + HIPs together. I can easily see why someone would call BB HIPs or a subset for sure. Is Kaspersky's roll back element HIPs? Is it behavior block? Is it smart HIPs? For Kaspersky it's required to block an action so I think it is one of them. It's not traditional HIPs I don't think (not by any current definition I know). It's more to me like a required element of a "smart HIPs" module for protecting files and the system from damage.

 

[Handsome Recluse]

@AtlBo How likely is it that the difference in coverage in your experience is because of who built them rather than the fundamental difference between the two?

 

[AtlBo]

I guess HIPs vs BB could be defined relatively. I haven't ever seen a formal definition of either, so the definitions I use for the terms I have defined for myself. These are based on experience with products that I felt defined abstractly a purist way to consider the concept, be it HIPs or BB.

For me the purist angle on HIPs can be found in Private Firewall. 21 HIPs rules that are applied to every process. PF was pretty good for its time and way better than most people knew. That said its HIPs had holes. Anyway, I don't think purist HIPs add up to a practical solution for a complete security plan, even excluding internet regulation (or considering it separately). For BB, I explain this in terms of Qihoo 360 TS, which doesn't have a HIPs module. It just has some files and executables that it protects. It even has a log section specifically called Behavior Blocking. There is File Protection, Web Protection, and Behavior Blocking. This kind of gives away how Qihoo are thinking about BB, i.e.->it's better than HIPs.

Using Comodo Firewall for now. I like it. However, the HIPs are very standard. If you strip the Trusted Publishers element from the equation, it's easier to see. This affects HIPs dramatically I know, but the same principle applies over a long term. Standard HIPs are going to become bothersome.

So, BB then might come along for some presenting standard HIPs front and center. These can condense the HIPs rules into one super important addendum->BB rule. If you can combine the two, then you have super HIPs or what I called smart HIPs.

Just the way I have grown to see things based on experience over the years.

 

[AtlBo]

@AtlBo How likely is it that the difference in coverage in your experience is because of who built them rather than the fundamental difference between the two?

Took me a while to get to a direct answer on your question. Thanks for asking this. Not sure how good the answer is though. It is this:

If developers are determining independently/differently what is HIPs or BB, I hope we see a standard from someone for each. I would really like to see this (don't think such a thing exists in either case at the present time).

 

[Wave]

Are Behavioral Blockers a subset of HIPS?

Behavior Blockers do cover areas that a HIPS will cover, however the aim of a Behavior Blocker is to focus on identification of malicious software dynamically, as opposed to just alerting for access/modifications to specific areas.

A Behavior Blocker can be approached many different ways... Some products may call it "dynamic heuristics" and auto-quarantine instead of alerting the user for the action to take place, while at the same time they may not have any features which belong to the definition of a Host Intrusion Prevention System (an example here would be GData - they have a good behavior blocker however it's a different approach to a vendor like Emsisoft). Whereas, some other vendors may develop a Behavior Blocker system which also concludes to being a mix of BB + HIPS (an example of a vendor which have done this would be Emsisoft).

All in all, a HIPS will protect specific areas from access/modification (such as preventing AutoRun modifications, hosts file modifications, web browser home-page modifications, and things like this), whereas a BB will be monitoring for activity which shows a more clear identification of malicious software (e.g. attempting to patch a system file, attempting to drop an executable into the Windows folder, attempting to launch a fake copy of explorer.exe to trick the user, attempting to allocate memory/write memory/create a remote thread in an innocent process for DLL injection, etc.).

The definition between the two really depends on your own personal opinion on how they work and what product you're thinking of which include the protection mechanisms when writing the definition, since many vendors approach it differently - if you use an Emsisoft product then chances are you'll think of a Behavior Blocker as a mix of monitoring for malicious behavior (BB) while protecting against modifications to specific areas (HIPS) combined with the alerts, whereas if you use a product like GData then you'll just be used to malicious behavior being identified and the threat being handled with appropriately.

In my scenario for example, I am developing a HIPS product, however it's a mix of both Behavior Blocking + HIPS... It will alert for behavior which is indeed showing a clear pattern of malicious software, however HIPS features can also be controlled - combined with automatic mitigation based on dynamic heuristics. This approach is a bit different, and other products will work differently.

 

[HarborFront]

@Wave

Hi

For Emsisoft, if the malicious file is dormant does its BB + HIPS detects such a file? Or does it depends on the BD engine to detect the malware?

As for your new product without an AV engine will it detect if the malicious file is dormant?

Thanks

 

[Wave]

@HarborFront If the File Guard is enabled and configured properly to scan the files then when the scanning is triggered (depends on the configuration but an example would be on write requests to the file which includes when a file is downloaded by the web browser) it will apply it's standard engines to determine if the file is clean or malicious (which will use their own signatures combined with the BitDefender signatures).

When a new program is started up, once again depending on the configuration of the file guard, it'll be scanned by Emsisoft again with the normal real-time engines (also including the BD engine). The execution will be prevented from going any further if it's found to be malicious by either the checksum signatures or the static heuristics (which can include byte detection for example, which is essentially generic detection which most vendors use to detect samples which they haven't even seen yet based on patterns in the executable, based on it's code).

If the program which is starting up is not found to be malicious by the real-time engines then I believe Emsisoft will apply a cloud check-up with the program (may depend on the configuration - if I remember correctly you can opt-out of the cloud network via settings). If the cloud check-up does not recognize the program as being malicious then it'll be allowed to proceed execution and the program start-up request will successfully follow on-to the program starting up, if not the program won't be started any further and will never reach the stages of executing it's own main code. However, if the program is in the cloud and known to be safe/genuine then it may be auto-white-listed (if I recall correctly), probably depends on the settings.

Moving on from all the different scenarios, the Behavior Guard itself won't determine if a program is malicious or not without it executing first. Once the program has started up if it's being monitored by Emsisoft then they'll be watching what activity the program is performing, and as soon as the program attempts to do something which is in the scope of what Emsisoft is configured to intercept, the alert will be displayed and the user is allowed to decide if they wish to quarantine/allow,... etc. That being said, Emsisoft won't know if the program is really malicious or not, however it'll change it's alert based on the reason for interception (since some behavior shows a more clear sign of malware than others, since modifying an AutoRun entry isn't deemed as being "malicious", whereas attempting to inject code into an external genuine program running is deemed to be malicious of course).

I assume this is how Emsisoft works at least based on memory from awhile back - of course they may have changed things around since last time I used them myself.

As for your new product without an AV engine will it detect if the malicious file is dormant?

My product is being designed to be as dynamic as possible - the BB/HIPS will allow the user to allow/block programs from performing specific actions during execution (or Quarantine if the user wishes, which will be recommended in the situation of a program attempting to alter the Master Boot Record for example - it's already working well at blocking Petya through this functionality). The BB/HIPS itself cannot know if a program is malicious since there will be no virus signature database for known malware based on check-sums or static generic detection, however the alerts will change depending on the behavior being intercepted (therefore for an injection attack, the alert will be red to signify that the behavior is indeed malicious and shouldn't be allowed, where the recommended action will be to quarantine, but if the user trusts the program they can allow it).

On top of this, since I am aware that many people mess up with BB/HIPS alerts if they do not know what they are doing, I am investing time in development of dynamic heuristics which will monitor the behavior of the untrusted programs, but instead of alerting the user for specific behavior requests, it'll sit tight until there is clear logged evidence of the program being malicious, and then it'll auto-block (or depending on the configuration, alert the user that the program is showing clear signs of malware and allow them to make a decision). The dynamic heuristics will be sort of an auto-pilot protection mechanism at best on it's default settings, however it's early stages for this feature.

There will be a database of trusted publishers for the white-list to prevent false positive alerts, so lots of genuine software can pass through without bothering you at default settings, however as the user of course this will be changeable via the white-list settings. Chances are there will be a cloud network shortly after the first release (there is no ETA but I hope it's soon), but to do this it'll require funding from the paid version of the product (there will be both a Free and Paid version).

Sorry if anyone thought I hijacked this thread, I didn't mean to if I did!