Jump to content

HIPS Serious Problem!!!


Recommended Posts

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.

Link to comment
Share on other sites

  • ESET Insiders

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.

Link to comment
Share on other sites

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:
1.PNG.7bf4d904bb5ddf628b665bc5833d4c6e.PNG2.PNG.e397d0fdbf6c1b1a4052a12308ba7591.PNG3.PNG.5588e0048f792f2462aff6d7b72398ea.PNG4.PNG.a8a09ff6a029fad84e388b63631a2fbe.PNG5.PNG.829c4a964d3a208137dcce96bae178b9.PNG

Video recording:

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

Clearly there must be a serious problem with HIPS.

Link to comment
Share on other sites

  • Administrators

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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..)? 

Link to comment
Share on other sites

  • Administrators
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.

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...