Eset blocking Encryption product

[steingat 1]

Hello,

We use a enterprise encryption product called SecureDoc by Winmagic.  Since version 7.2.2055 of Eset, whenever we attempt to remotely deploy updates to this product with our remote management tool we run into intermittent issues with Eset blocking the installs and crashing the application mid-way through the install.  I have tried adding a bunch of performance exclusions and other exclusions to the policy for Eset.  However this has not helped.  The remote management tool runs the installer (MSI deployment) with SYSTEM permissions.  Most of the time, If I login as a user with local admin rights, the installer runs without issue.

  I have also noticed that Eset has started to block certain types of registry edits.  Such as if I use logmein or our remote management product to edit some keys such as hklm\software, but If I log onto the machine locally or using the windows "Remote registry" tool using the SAME Permissions then I am not denied access.  

 

The reason I suspect Eset is on these machines, if I completely uninstall eset I do not run into these issues.

What I need to figure out is the following:

1. How do I find and generate logs to verify it is heuristics or the Machine learning that is trying to block this action?  Does Eset log EVERY block?

2. How do I correctly whitelist this installer from EVERY module in Eset and every process spawned by it?  The installer throws files into c:\windows\temp directory and needs to run these to verify the encryption currently on the drive as part of the install process.  I have attempted to already add a performance exclusion for the programs install directory, its original execution directory, AND I excluded files sent to livegrid by hash, However, it seems Eset just ignores these exclusions on multiple machines. I do have the policy exclusions enforced.

[Marcos 5,070]

Please narrow it down by doing the following, one at a time:

1, Pause real-time protection
2, Disable real-time protection in the advanced setup and reboot the machine
3,  Disable HIPS and reboot the machine

Quote

However, it seems Eset just ignores these exclusions on multiple machines. I do have the policy exclusions enforced.

You can test performance exclusions with eicar test file. If you put it to an excluded folder or rename it so that it has the name of an excluded file, it must not be detected.

[steingat 1]

Last night LiveGrid automatically submitted a bunch of the Securedoc encryption install files to Eset.  Since this morning, I have tested 5 installs with the same settings as last night and so far no issues.  There was also a modules update to the Eset server.

I can only conclude that these items were added to the Eset models update in some way for the client/servers.  I will post again If i continue to have issues.

 

Edited April 22, 2020 by steingat

[Marcos 5,070]

Weird. Definitely the fact that some files were submitted via LiveGrid had nothing to do with the issue and didn't affect it at all.

[steingat 1]

Hmm, I'm not so sure about that, I did some more digging, found out that the "Livegrid" submission option was not locked down in our environment.   Detection Engine>cloud based protection>enable ESET LiveGrid® feedback system.  So some computers had this ON and some had this OFF.

 

I Locked down the setting to ON.  The next two computers I attempted to upgrade bombed in the middle of the install.  Forced the setting OFF, so far only had a chance to test one system, but the install went through without a issue.

 

Will try a few more with the setting in the OFF position.

 

With that said, this application aggressively defends the files in its install folder, here are the patch notes from 1 minor revision ago:

Patch notes from securedoc:

SD-30091: Protection has been made stricter for the contents of the UserData folder, barring users from deleting, moving or renaming files from this folder required by SecureDoc Client software. In SecureDoc 8.5, permissions and file verification have been made stricter on all files in the userdata folder. Users are still allowed to create and modify files in that folder, but they will not be able to rename/move/delete them. In addition, modifications for SD configuration files are still restricted for users and optionally (based on settings) for admins per profile configuration.

SD-31670: Some customers who are using the UEFI Boot "Patching" method (to patch windows boot manager in order to load preboot) reported that windows updates had the potential to overwrite the patch. Issue: SecureDoc has the ability to load pre-boot by patching windows boot manager, such that the bios will launch SecureDoc pre-boot authentication when it thinks it is launching windows. This method is normally used for devices where the alternate method of adjusting the bios boot order is not properly supported. It was found that when Windows updates the boot files, this patch could be removed and not restored before the system reboots. Normally, WinMagic SecureDoc implements additional protection at the BIOS level, however in some cases this protection is unavailable. Solution: WinMagic has developed additional protection at the windows level to protect the boot patch from being overwriting by a Windows update or upgrade process.

 

Edited April 22, 2020 by steingat

[steingat 1]

I have more data, Please see below:

Before starting any of this, I had added performance exceptions for the final install location and the directory the installer was running out of under:
Detection Engine>Exclusions>performance exclusions
Detection Engine>Realtime fiule system protection>Processess exclusions - Whitelisted associated executables

Computer 1 - Policy Defaults, enable ESET LiveGrid® feedback system Most likely on (Not locked down) - Update Failed
Computer 2 - Policy Defaults, enable ESET LiveGrid® feedback system on (Not locked down) Saw Livegrid submit files of multiple securedoc files - Update Failed - 

At this point, ALL Eset files submitted to livegrid where whitelisted via hash for all computers

Computer number 3 - Created Test policy group, moved laptop there, per eset paused real time protection, Unknown status of "enable ESET LiveGrid® feedback system" - Update successful 
Computer 4 - Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off - Update successful
Computer 5 - Trying multiple hibernate/sleep/power off cycles, Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off - Update successful
Computer 6 to 9 - Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off, but inital status unknown - Update successful 

This is the point that I enforced "enable ESET LiveGrid® feedback system" to on via policy

Computer 10 - Policy Defaults, "enable ESET LiveGrid® feedback system" is on and enforced via policy - Update Failed
Computer 11 - Policy Defaults, "enable ESET LiveGrid® feedback system" is on and enforced via policy - Update Failed

Went back into the policy, I enforced "enable ESET LiveGrid® feedback system" to OFF

Computer 11-15 - Policy Defaults, "enable ESET LiveGrid® feedback system" is OFF and enforced via policy - Update successful

Please note, we are content with just turning off the Eset live grid feedback system as a solution, I did not test adding anything to Detection Engine>Cloud Based protection>submission of samples>exclusions
I will say that I am suprised to see this module cause issues even after we had added exclusions elsewhere in the system.

[Marcos 5,070]

It is important to have ESET LiveGrid Feedback system enabled. When disabled, we may not be able to respond to a possible new malware that you might encounter and may not be able to add appropriate detection that would enable cleaning. Does the issue occur after re-enabling the LG Feedback system and disabling it resolves the issue? If so, try enabling LG Feedback system but temporarily disable HIPS and reboot the machine. Does it resolve the issue?

[steingat 1]

When the installs of this encryption product fail, they fail in a way that requires we completely decrypt the drive and completely remove the software from the machine. Then do a reinstall.  These machine no longer serve as good test subjects as we are doing a new install and not a upgrade install, the new installs we use a local admin account to run, we do not use the remote deployment tool as the encryption software on the initial install needs to identify a primary user for logon purposes.

But, from the systems I have tested, the ones that have had LG enabled have failed, the ones that have LG disabled do not fail even if all other policy items are the same and the machine model/update level (windows/eset) are the same.

I have run out of in stock laptops at this point to do additional testing with to try leaving HIPS off and enabling LG.  I might have one additional system to test this with in 24-48 hours as we are upgrading a users system due to a failed touch pad (mechanical issue, not software or electrical).  If you would like me to generate logs/ a dump/etc please let me know what logging options you would like enabled.

With that said, we would consider re-enabling LG across the org once we are done with deployment.

 

One more item to note:

Live grid was also submitting multiple temp files from our PDF product, Foxit PDF, the files would exist in c:\user\USERNAME\appdata\local\temp\foxImgSteam.tmp and be submitted to LG up to 50 times per day per user

We had received some complaints from our users that PDF documents were being corrupted when saving to specific locations, I am not sure if this is related.

From the documentation I saw, I did not see a way to create an exclusion for users %appdata%\temp\foxImgSteam.tmp as Eset runs with system creds and it does not appear that you can use wild card inside of path names such as c:\user\*\appdata\local\temp\foxImgSteam.tmp or just specify a filename such as foxImgSteam.tmp