HIPS Serious Problem!!!

[Mr_Frog 14]

I don't need speech too much, you can see from this video recording i made.

https://mega.nz/folder/K1ETlQZQ#zfHwuYK-ktD2LViXHxt9Zw

[stackz 115]

Just tested and confirmed. This is a real show stopper.

[Marcos 5,259]

Could you please explain what the problem is? You renamed the folder so the HIPS rule was no longer applied to the file.

[Mr_Frog 14]

28 minutes ago, Marcos said:

You renamed the folder so the HIPS rule was no longer applied to the file.

Shouldn't it be full path protected?

I have tested in previous versions and supposedly folders and files can't be renamed.

[Marcos 5,259]

Tested with HIPS from Jan 2021, it behaved the same way.

You must create another similar rule for the folder itself, with the target path set exactly to
D:\frog

[stackz 115]

It just seems rather ridiculous, that if I have for example, C:\1\2\3\protected_file.txt

If I make a rule to prevent modification of any file in 3, I also need to make a similar rule for 1 and 2 in case either 1 or 2 get renamed.

[Mr_Frog 14]

1 hour ago, Marcos said:

Tested with HIPS from Jan 2021, it behaved the same way.

I just create new rule and the result same, Marcos!

Like this:

Video recording:

https://mega.nz/folder/K1ETlQZQ#zfHwuYK-ktD2LViXHxt9Zw
 

Clearly there must be a serious problem with HIPS.

[Marcos 5,259]

You cannot use \* at the end of the path. That's why I wrote:

You must create another similar rule for the folder itself, with the target path set exactly to
D:\frog

In this case it'd be D:\Racoon

[Mr_Frog 14]

14 minutes ago, Marcos said:

You cannot use \* at the end of the path.

This is ridiculous, Marcos. To protect 1 file that is in 3 levels of directory I have to make 4 rules. It should work with wildcards.

[Marcos 5,259]

There are very good reasons for this behavior. Protecting each of the parent folders could lead to serious issues that users are not normally aware of, including problems with applications using ADS for instance.

[czesetfan 29]

Can you explain what actually happened here? To "break" the file/folder protection, is it enough to rename the parent folder? 

So how should the rules look like, for example to allow access to the "Documents" folder only for certain programs (MS Office..)? 

[Marcos 5,259]

3 minutes ago, czesetfan said:

Can you explain what actually happened here? To "break" the file/folder protection, is it enough to rename the parent folder? 

So how should the rules look like, for example to allow access to the "Documents" folder only for certain programs (MS Office..)? 

You must have a custom HIPS rule created for files in a folder. In order to protect the folder itself from renaming, you must create another rule for the folder itself. It does not affect ESET's ransomware or other threat protection in any way.

[czesetfan 29]

Can you give a concrete example of this? Or is there a guide somewhere on how to implement this?

[czesetfan 29]

So how should the rules look like, for example to allow access to the "Documents" folder only for some programs (MS Office..)?

[itman 1,746]

Here's the problem the OP is showing as I am interpreting it.

When a directory/folder or file is renamed using Win Explorer, Eset HIPS modification rule does detect it and alerts. However, the renaming remains in effect. This might have something to do with Win Explorer performing the rename activity. I suggest creating a .bat script with the following command for example:

rename c:\computer\test.txt test.exe

Run the .bat script by double mouse clicking it and see if the renaming activity is prevented.

-EDIT- I ran this test myself and there is a problem with the HIPS. It recognizes file renaming as file modification activity, but does not prevent the file from being renamed. This parallels a long known issue with Eset real-time scanning in regards to file renaming activities.

Also, it appears none of the file modification mitigations are working. I can delete a file as well. Again, the HIPS alerts it blocked the delete, but the delete occurred.

Edited January 14, 2022 by itman

[czesetfan 29]

As I understand it, it is also possible to rename a directory and then the files in it are no longer protected against tampering. Correct?

[itman 1,746]

Looks like this is indeed a serious problem. I thought I could get around the block action not working by changing the rule to ask. Then selecting deny when the alert appeared. A no go on that idea. The file still got deleted.

Edited January 14, 2022 by itman

[itman 1,746]

This is indeed a weird one!

I did a Win 10 system restart and all HIPS file modification activities are now properly being detected. This is both rename and delete activities. The strange part is the Eset alert appears that modification was detected and blocked. Then the UAC prompt appears to escalate to admin level. However, none of my test files were created with admin privileges. Allowing the UAC esculation just results in another Eset block alert and the above activity repeats. I have to cancel the UAC escalation to get out of the loop. Appears UAC activity is originating from dllhost.exe:

Time;Application;Operation;Target;Action;Rule;Additional information
1/14/2022 4:44:49 PM;C:\Windows\System32\dllhost.exe;Get access to file;C:\Users\XXXXX\Downloads\copy.bat;Blocked;Test;Delete file

This BTW is the first system restart performed since last Tues. Win updates. Possible those updates hosed something in Eset.

Edited January 14, 2022 by itman

[New_Style_xd 69]

46 minutes ago, itman said:

This is indeed a weird one!

I did a Win 10 system restart and all HIPS file modification activities are now properly being detected. This is both rename and delete activities. The strange part is the Eset alert appears that modification was detected and blocked. Then the UAC prompt appears to escalate to admin level. However, none of my test files were created with admin privileges. Allowing the UAC esculation just results in another Eset block alert and the above activity repeats. I have to cancel the UAC escalation to get out of the loop. Appears UAC activity is originating from dllhost.exe:

Time;Application;Operation;Target;Action;Rule;Additional information
1/14/2022 4:44:49 PM;C:\Windows\System32\dllhost.exe;Get access to file;C:\Users\XXXXX\Downloads\copy.bat;Blocked;Test;Delete file

This BTW is the first system restart performed since last Tues. Win updates. Possible those updates hosed something in Eset.

All that was said, just think here, are we really safe with ESET, it is letting you rename the folders even creating the rule.

[itman 1,746]

1 hour ago, New_Style_xd said:

All that was said, just think here, are we really safe with ESET, it is letting you rename the folders even creating the rule.

This incident is no where as serious as another one I discovered by chance a few months back.

Eset was not setting its deep behavior monitoring hook in select processes; e.g. cmd.exe. Not a peep from the Eset GUI status-wise that anything was amiss. The only way I resolved this one was to reinstall Eset.

Edited January 15, 2022 by itman

[New_Style_xd 69]

4 hours ago, itman said:

This incident is no where as serious as another one I discovered by chance a few months back.

Eset was not setting its deep behavior monitoring hook in select processes; e.g. cmd.exe. Not a peep from the Eset GUI status-wise that anything was amiss. The only way I resolved this one was to reinstall Eset.

But has the problem you identified months ago been fixed?

[itman 1,746]

9 hours ago, New_Style_xd said:

But has the problem you identified months ago been fixed?

As I posted, an Eset re-install fixed the issue. As such, assume there was some type of internal corruption with the original installation.

[itman 1,746]

I have a theory as to why these UAC alerts are appearing.

Appears Eset is attempting to use dllhost.exe to inject a .dll into explorer.exe. The strange part is both processes run at medium integrity level. As such, no elevation of privileges is required for dllhost.exe. This would indicate something has changed OS-wise in regards to explorer.exe internal protection mechanisms.

[itman 1,746]

There is more than the UAC issue in regards to HIPS file modification detection.

If I click on a file's Properties tab using Win Explorer, Eset will trigger a block alert even though no changes were performed to Properties settings.

I can open a file for editing and no alert is generated as should be the case. When I attempt to save the file after modification, Eset will block the change and interestingly no UAC alert appears.

Edited January 15, 2022 by itman

[itman 1,746]

I need to correct the UAC prompt reference in my above statements. What is being displayed is the Win file access prompt to escalate access to current logged on user access permission level. There is also no reason this prompt should be displayed since I have full access rights to any files I manually created.

There appears to be a "timing" issue in regards to the HIPS processing of file modification rules in regards to rename or delete actions. It appears the HIPS is blocking file access prior to Win 10 completing its file access verification processing. Since the OS can't access the file, it doesn't know what to do. It instead displays the file access prompt to escalate to the required current user access permission level.

Since I am running ESSP, I wonder if there is a LiveGuard file processing factor that is the source of this behavior?

Edited January 16, 2022 by itman