Ver. 9 HIPS Still Doesn't Work Right!

[itman 1,659]

Against my better judgment, I decided to try the latest ver. of SS 9 again .............. under the assumption the HIPS issues were resolved. Well, they are not and I am definitely not a "happy Eset camper!" 

 

For starters, the existing ver. 8 rules end up a jumbled mess of allow and block rules instead of being sorted alphabetically as done in ver. 8. Far worse, many of my existing ver. 8 rules did not function properly in ver. 9. For starters, I monitor a few selected processes startup. One is my browser, IE11. For some unknown reason and most notable that rule was being triggered for a number of system processes startups e.g. svchost.exe startup of wmiprvse.exe, etc., etc.. And the list of "borked" rule executions goes on and on.

 

My existing HIPS rules ver. 8 work flawlessly and I expect the same from ver. 9. It is bad enough that the metro interface used by ver. 9 makes HIPS rule creation more burdensome to say the least. Obviously, whoever designed the ver. 9 GUI was not a technician and definitely not a power user. And not providing a way to at least to sort or reorder HIPS rules is inexcusable. 

 

It appears that Eset may not be aware of the fact that a number of its customers specifically use NOD32 or Smart Security for its HIPS feature?

Edited May 2, 2016 by itman

[SlashRose 25]

Can the only vollstens Agree! I had already written in another post of mine, Eset gets the hip problem is not solved and I write not only so!( German:Kann dem nur vollstens Zustimmen! Ich hatte es ja schon in einem anderen Posting von mir Geschrieben, Eset bekommt das Hip Problem nicht Gelöst und das Schreibe ich nicht nur so!)

[mma64 7]

 

[itman] (...) For some unknown reason and most notable that rule was being triggered for a number of system processes startups e.g. svchost.exe startup of wmiprvse.exe, etc., etc.. And the list of "borked" rule executions goes on and on. (...)

 

I don't quite understand what you mean with this. Are you saying that the automatic conversion of ESS V8 configuration into ESS V9 configuration went wrong, regarding HIPS rules? A speaking example would be helpful, ie. a copy / paste from the ESS V8 settings.xml and the corresponding copy / paste(s) from the ESS V9 one. I haven't noticed any conversion errrors after installing ESS V9 over ESS V8, except that immediately after this successful update I noticed HIPS duplicates popups, see here [link follows later]. (Hopefully you have exported ESS V8 settings before and after the update to ESS V9, this would be highly valuable data.)

 

Regarding the dreaded HIPS duplicates popups I have written a program that analyzes the ESS V9 export settings.xml, prints some statistics and lists all duplicates, look at this printout snapshot ("Courier New" in this forum software doesn't seem to function correctly, all ":" are aligned reasonably):

 

----------------------------------------------------------------------------------------------------

some statistics...:

number of HIPS rules : 1989

whereof /w multiple app sources : 0

number of enabled HIPS rules : 1986

number of disabled HIPS rules : 3

number of logged HIPS rules : 1564

number of not logged HIPS rules : 425

number of HIPS rules /w notify : 0

number of HIPS rules /wo notify : 1989

number of HIPS rules /w 'allFileTargets' : 2

number of HIPS rules /wo 'allFileTargets': 1987

number of HIPS rules /w 'allRegTargets' : 1

number of HIPS rules /wo 'allRegTargets' : 1988

number of HIPS rules /w 'allPeTargets' : 0

number of HIPS rules /wo 'allPeTargets' : 1989

number of HIPS rules /w 'hasFileTargets' : 667

whereof /w multiple file targets : 8

number of HIPS rules /wo 'hasFileTargets': 1322

number of HIPS rules /w 'hasRegTargets' : 246

whereof /w multiple registry targets : 0

number of HIPS rules /wo 'hasRegTargets' : 1743

number of HIPS rules /w 'hasPeTargets' : 1076

whereof /w multiple PE targets : 12

number of HIPS rules /wo 'hasPeTargets' : 913

number of HIPS rules /w action=ALLOW : 1987

number of HIPS rules /w action=DENY : 2

number of HIPS rules /w action=ASK : 0

number of 100% HIPS rules duplicates ('Doublette!!!', 'Doublette in a row!!!'): 363

number of possible, but still to verify HIPS rules duplicates ('Doublette???'): 89

-------------------------------------------------------------------------------

(after this, "sorted list of HIPS rules /w multiple targets:", "automatically detected HIPS duplicates sorted list (including those that are fully prior to ESS V9):", "automatically detected HIPS duplicates sorted list fully prior to ESS V9 Update:", "[mma64] automatically detected HIPS duplicates which I haven't recognized as such immediately:")

 

- yes, I have ~12 HIPS duplicates, of which I have checked two for correctness, prior to ESS V9, ie. ESS V8 ones, that totally slipped my awareness as it seems... Look at this snapshot showing one of them:

 

C:\...\firefox.exe#C:\...\plugin-hang-ui.exe#0#0#0#1#0#1 -> [bASE,peOps]#1AB#[Pre-ESS-V9!]#User rule: allow firefox.exe

C:\...\firefox.exe#C:\...\plugin-hang-ui.exe#0#0#0#1#0#1 ->                       #1AD#[Pre-ESS-V9!]#User rule: allow firefox.exe

 

- this program will be downloadable in the near future for all. And everybody that's using HIPS in interactive mode should give it a try.

 

 

[itman 1,659]

I don't quite understand what you mean with this. Are you saying that the automatic conversion of ESS V8 configuration into ESS V9 configuration went wrong, regarding HIPS rules?

Yes, that is exactly what I am saying.

 

First, I am not going to post my detail HIPS rules via attachment of the .xml backup file publicly for obvious reasons.

 

Below is a screen shot of the way HIPS rules are ordered in ver. 8. Note they are sorted alphabetically. Also as best as I can determine, they are executed in top to bottom order. At the minimum, allow rules are executed before block rules.

 

After the conversion to ver. 9, all the HIPS rules are reordered in a jumbled fashion with allow and block rules appearing in some unknown order. This makes maintenance extremely difficult.

 

Initially, I also believed this was also affecting the order in which the rules were executing. However, most of the rules were behaving the same in ver. 9 but I was still receiving alerts on activity that was previously allowed in ver. 8. Worse, the alerts were unrelated to the activity being performed. For example as stated previously and belaboring the point, I have two browser related rules that control its startup. The first rule allows which processes are allowed to start the browser. The second rule is an ask rule that monitors the startup of browser by any other process. The ask rule for some reason in ver. 9 was being triggered by unrelated activity e.g. svchost.exe startup of wmiprvse.exe. Worse the triggering was random and not being done upon every execution of svchost.exe startup of wmiprvse.exe. This is only one example of much more erratic and inconsistent behavior I observed in the ver. 9 HIPS. 

 

[itman 1,659]

I will also add that it would be very helpful if Eset would display in the HIPS what the HIPS default rules are under the auto and smart modes. Or alternatively, publish same in a help document or the like.

 

Eset stores those default rules in a .bin file which makes it impossible to see what rules are being executed by default. I know of no other security vendor that employs a HIPS that doesn't not display its default rules. It makes it impossible to prevent duplicate user rules from being created for which Eset default rules already exist.

[toxinon12345 32]

v8 predefined rules are listed as user rules (allowed drivers)

smart mode use some predefined rules which are hidden and intend to protect modification of services and so on.

 

@itman, I would like to know under what filtering mode are you running the HIPS?

I ask this because, there is no sense running it under a mode which doesnt correspond to the user rules.

[toxinon12345 32]

@mma64, good to know you will share such util in the future.

In addition, I see any rule exported in the XML expand their environment variables. So a rule in a X system running the same OS as Y system, probably will fail across.

[itman 1,659]

v8 predefined rules are listed as user rules (allowed drivers)

smart mode use some predefined rules which are hidden and intend to protect modification of services and so on.

 

@itman, I would like to know under what filtering mode are you running the HIPS?

I ask this because, there is no sense running it under a mode which doesnt correspond to the user rules.

Actual there are default Eset rules under both Auto and Smart mode. For example, both have rules to prevent Eset processes and directories from being tampered with.

 

Smart mode adds a few additional protections such as protection of Win system files in memory; areas in the registry targeted by malware and the like; etc..

 

In my testing, I can tell when an Eset default rule is triggered because I will see the activity blocked but I will not receive an alert from the HIPS. You can also see this activity by enabling the "log blocked activity" option in the HIPS advanced settings.

 

My testing has also shown the Smart mode coverage is limited in scope in what it does protect. So I supplement it with my own custom rules. Problem is I am positive some of my custom rules are duplicates of Eset's Smart rules. Problem is I can't tell what is a duplicate since I have no way of knowing what Eset's default rules are.

 

Finally Eset's default rules regardless of HIPS mode selected, Auto or Smart, always take precedence over any user rules. It is a bit aggravating to see in the log "some action partially allowed or blocked." In any case, I have never encounter any operational issues or conflicts between my user rules and Eset's default rules.  Most likely as stated previously because Eset default rules take precedence.

 

-EDIT-

 

I was running in Smart mode when I had ver.9 installed. Again the issues I encountered were not directly related to my ver. 8 rules.. Startup rules for iexplore.exe should only apply to that specific process ....................... 

Edited May 3, 2016 by itman

[toxinon12345 32]

Yes, I know what you are refering to. Self-defense predefined rules are default deny rules, and they work no matter under what filtering mode you are running. They cannot be overriden (for example create a rule based on self-defense and change to default allow; it will be blocked anyway)

You should understand each filtering mode as doing what they are intended to do, and rules as exceptions of what that filtering mode do.

Now, between user rules the precedence is first the Block rules and just then the Allow rules

I think Smart mode rules and Allowed drivers rule cannot be overriden, it is something I will evaluate.

[itman 1,659]

Now, between user rules the precedence is first the Block rules and just then the Allow rules

That is what Eset states. However in ver. 8 and verified by my own testing, that is not the case.

 

For example, I have more than one rule set where I only allow certain executables to run in a directory and block everything else from running in the directory. Rule set works fine. Now if block rules executed prior to allow rules, nothing in the directory would execute. Also in this example, the block rule is really an ask rule with alert and logging enabled. I have never observed either unless the executable was indeed something I had not specifically allowed. And yes, I tested this rule set as I do with all the HIPS rules I create.

 

I believe what Eset is referring to is the fact that the default action for any event is as follows. When no specific user rule has been created or default rule exists, Eset's HIPS allows the event. So if I only block program x, y, and z in a directory, Eset will allow all other executables to run in that directory.

Edited May 4, 2016 by itman

[toxinon12345 32]

 I just noticed Smart mode rules cannot be overriden also, a good thing in my opinion: I dont imagine to click Allow in a dialog just to notice after it was logged as Blocked by a explicit user rule. It would lead to confusion.

EDIT: Smart mode rules can be overriden, too. I noticed that when enabled the rule notify/logging.

Allowed drivers can be overriden, is explicitly written in documentation.
Also some system processes are allowed access by default. (Regedit to registry keys, Explorer to write Thumbnails etc) they can be overriden also.
 

the block rule is really an ask rule with alert and logging enabled.

This particular sentence... an ask rule is just that: an interactive rule, but if you manage to disable globally the GUI alerts, that would be just a matter of a !¿temporal hook.?!!!
Just trying in Advanced setup > User Interface > Alerts and notifications

Edited May 6, 2016 by toxinon12345

[itman 1,659]

Allowed drivers can be overriden, is explicitly written in documentation.

 

The default allow driver loading in ver.8 in my opinion is non-functional. A number of drivers listed there don't even have the right paths associated with them. I enabled logging for that rule and received zip output. Also drivers are loaded from Windows boot loader before Eset has even started execution. I also have not seen anything to show that Eset's emon,etc. driver is loaded prior to any other drivers. This is the only way Eset could monitor any subsequent driver loading.

 

A while back as a test I created a user rule to ask for any driver loading from C:\*.*. Then I ran Process Explorer which loads its own kernel driver on the fly. I received zip alerts from Eset's HIPS. So as far as I am concerned, Eset doesn't monitor anything in regards to drivers and that includes any write activity to C:\Windows\Drivers directory. 

[toxinon12345 32]

Drivers could also be loaded at any time after boot, it should makes sense when switched to interactive or policy based mode.

I, for one, cannot see any important bug in the HIPS.

Also, Smart rules seem to be dynamic for each HIPS update, maybe adapting to current threat landscape.

Sometimes I see some notifications stating the HIPS user rule file was sent for analysis, which suggests a community ruleset.

[itman 1,659]

@toxinon12345

Here's how to determine how effective Eset's Smart rules are. Download the latest ver. of the old Comodo Leak Test. Run it with HIPS mode set to Smart mode. Note what your score is. Not very good.

With my custom rules, I essentially score 340; the highest score available. The only tests I failed are the global hooking test since it tries to inject a 32 bit dll into a 64 bit process which is not allowed, and the knowndlls test since that area is protected by x64 PatchGuard. Additionally with the custom HIPS rules I use, I receive no alerts with my configuration since I have allowed trusted system processes, apps, files, and registry mods. to execute but be protected against both file and memory based malware.

Edited May 5, 2016 by itman

[toxinon12345 32]

¿¿¿Have you tried Keylogger protection for your specific browser, since that is positively a protection feature ESET security producte claims??? a.k.a Online Payment Protection...

[itman 1,659]

¿¿¿Have you tried Keylogger protection for your specific browser, since that is positively a protection feature ESET security producte claims??? a.k.a Online Payment Protection...

I used the SpyShelter keylogger test previously when I initially tried ver. 9. Eset's OPP protection does scramble all keystrokes. That is all it does which is adequate protection for all practical purposes. OPP does not block keystroke interception however. 

[stackz 112]

A while back as a test I created a user rule to ask for any driver loading from C:\*.*. Then I ran Process Explorer which loads its own kernel driver on the fly. I received zip alerts from Eset's HIPS. So as far as I am concerned, Eset doesn't monitor anything in regards to drivers and that includes any write activity to C:\Windows\Drivers directory.

 

The same holds true for versions 9 and 10 beta.

[toxinon12345 32]

if I remember correctly SysInternals's util doesnt load the driver again if It remained in memory.

[itman 1,659]

if I remember correctly SysInternals's util doesnt load the driver again if It remained in memory.

No, it loads it dynamically upon execution and deletes it upon termination. The way it loads though does leaves traces which can be viewed using the series of "set devmgr ...." commands to show non-present devices followed by the "start devmgmt.msc" command. Then select "show hidden devices" option in device manager and you will see the ghosted driver it used.

 

-EDIT-

 

Looks like you are correct that when Process Explorer runs once, its driver remains loaded into memory. How I got around that was to delete its ghosted drivers as mentioned above. I then created a HIPS rule to monitor any driver loading from C:\Windows|System32\Drivers\*.*. I then disabled my existing allow rule for Process Explorer.

 

Ran Process Explorer. My HIPS rule that monitors write activity to C:\Windows|System32\Drivers\*.* was triggered showing PE's driver creation in the directory. This proves the driver was being created from scratch. Not a peep from my newly created HIPS ask rule to monitor driver loading from C:\Windows|System32\Drivers\*.*.

 

Bottom line - Eset HIPS driver loading option does not work.

 

-EDIT 2-

 

To make matters worse, Eset's HIPS default rule appears to be partially overriding my user rule to monitor access to C:\Windows|System32\Drivers\*.* as noted in the below HIPS log entry. Hopefully, all it is allowing is read access to the directory.

 

5/6/2016 1:52:34 PM C:\Users\xxxx\AppData\Local\Temp\procexp64.exe  Get access to file C:\Windows\system32\Drivers\PROCEXP152.SYS 

some access allowed   User rule: block changes to Windows directories    Get exclusive access to file,Write to file

 

And here's the service keys creation for the driver that would be allowed under HIPS default mode:

 

5/6/2016 1:53:01 PM C:\Users\xxxxAppData\Local\Temp\procexp64.exe    Delete from registry HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PROCEXP152\Enum   allowed   User rule: block changes to registry service keys 

5/6/2016 1:52:59 PM C:\Users\xxxx\AppData\Local\Temp\procexp64.exe   Modify registry HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PROCEXP152\ImagePath allowed User rule: block changes to registry service keys 

5/6/2016 1:52:55 PM C:\Users\xxxx\AppData\Local\Temp\procexp64.exe   Modify registry HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PROCEXP152\Start   allowed   User rule: block changes to registry service keys 

5/6/2016 1:52:48 PM C:\Users\xxxx\AppData\Local\Temp\procexp64.exe   Modify registry HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PROCEXP152\ErrorControl   allowed   User rule: block changes to registry service keys 

5/6/2016 1:52:43 PM C:\Users\xxxx\AppData\Local\Temp\procexp64.exe   Modify registry HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PROCEXP152\Type   allowed   User rule: block changes to registry service keys 

 

Bottom line 2 - as best as I can determine, Eset HIPS has zip default protection when it comes to malware installing a signed kernel driver let alone a user mode driver.

Edited May 6, 2016 by itman

[toxinon12345 32]

Seems the rules are applied in the way described in the below image:

 

[itman 1,659]

Glad you showed the registry transversal.

 

People have to be careful to code "*.*" and not just "*" if they want the rule to apply to all subordinate primary registry keys.

 

Another thing I found out through testing is the HIPS "start new application" option is pretty comprehensive. It will detect any PE regards of what suffice might be employed e.g. .txt, .tmp, .scr, etc.. However, I don't believe it detects scripts e.g. .ps1, .js, .vbs, etc..