steingat

I suspect a false positive as well, we even had one detection in Esets own logs.

So, from my understanding of the way WSL (Windows subsystem for linux) works is that both windows and the linux distro run on hyper-v on the machine that it was installed on as separate, but co-equal kernels. If Eset Endpoint security for windows is installed, can it scan the memory space for threats in the WSL 2.0 memory space without having to install the linux client? My concern on this is installing Kali Linux is fully supported under WSL 2.0 and I am concerned that it could be used as an attack platform outside the reach of Eset endpoint security.

https://d3qkumov2e0xmk.cloudfront.net

Hello, We have some users who are attempting to access some documents from a hiring service we use When the users attempt to access the documents, it looks like they are attempted to be accessed via a CDN and this is marked as a phishing CDN. How would we get more info about the below website and possible a second review as to why we are getting these alerts? Hash: 0608825F6B54238A452E3050D49E8AA50569A6C9

In some cases we are not, the issue did come back on our end too after working correctly for a few days. This would be a nice policy option to have for the next version of eset.

As an update, as I am not sure what changed, but all of our problematic endpoints seem to have been fixed and none that are currently connected are reporting a cloud connection problem. This seems to have happened with in the last few hours

Its possible that the user disconnected or reconnected to the VPN. But no other changes would have taken place on the users machine.

The most problematic endpoints are. But other endpoints who connect to the VPN with the same configuration do not have issues.

Did I upload the wrong logs in my previous post?

Here are my traceroutes along with some logs. It seems that the connection to 91.228.165.44 is much worst. Endpoint 1 C:\temp>tracert c.eset.com Tracing route to c.cwip.eset.com [38.90.226.12] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 26 ms 20 ms 29 ms nwblwihed11-lag11-433.network.tds.net [184.61.161.97] 4 30 ms 29 ms 28 ms nwblwidst52-tg0-0-2-0.network.tds.net [64.50.229.61] 5 36 ms 36 ms 30 ms chi-b23-link.ip.twelve99.net [80.239.135.66] 6 * * * Request timed out. 7 32 ms 28 ms 24 ms be2766.ccr42.ord01.atlas.cogentco.com [154.54.46.177] 8 51 ms 45 ms 46 ms be2832.ccr22.mci01.atlas.cogentco.com [154.54.44.169] 9 54 ms 47 ms 46 ms be3036.ccr22.den01.atlas.cogentco.com [154.54.31.89] 10 76 ms 73 ms 68 ms be3047.ccr21.elp01.atlas.cogentco.com [154.54.1.125] 11 67 ms 69 ms 68 ms be2930.ccr32.phx01.atlas.cogentco.com [154.54.42.77] 12 85 ms 80 ms 82 ms be2941.rcr52.san01.atlas.cogentco.com [154.54.41.33] 13 82 ms 82 ms 91 ms te0-0-0-35.nr61.b036483-1.san01.atlas.cogentco.com [154.24.24.186] 14 85 ms 80 ms 84 ms 38.88.58.18 15 84 ms 83 ms 96 ms 38-90-226-12.ptr.eset.com [38.90.226.12] Trace complete. C:\temp>tracert c.eset.com Tracing route to c.cwip.eset.com [91.228.165.44] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 21 ms 21 ms 21 ms nwblwihed11-lag11-433.network.tds.net [184.61.161.97] 4 31 ms 30 ms 31 ms nwblwidst52-tg0-0-2-0.network.tds.net [64.50.229.61] 5 29 ms 26 ms 30 ms chi-b23-link.ip.twelve99.net [80.239.135.66] 6 42 ms 48 ms 44 ms nyk-bb2-link.ip.twelve99.net [62.115.137.58] 7 120 ms 118 ms 120 ms ldn-bb1-link.ip.twelve99.net [62.115.113.21] 8 * 140 ms * prs-bb1-link.ip.twelve99.net [62.115.135.25] 9 142 ms 140 ms 138 ms ffm-bb1-link.ip.twelve99.net [62.115.123.12] 10 139 ms 146 ms 143 ms win-bb3-link.ip.twelve99.net [62.115.137.203] 11 145 ms 142 ms 141 ms win-b2-link.ip.twelve99.net [62.115.114.185] 12 165 ms 145 ms 143 ms 87.128.239.252 13 141 ms 222 ms 141 ms 80.150.170.82 14 150 ms 146 ms 177 ms st-static-bckb-22.213-81-252.telecom.sk [213.81.252.22] 15 * * * Request timed out. 16 * * * Request timed out. 17 146 ms 148 ms 146 ms h1-c04-s.eset.com [91.228.165.44] Trace complete. Endpoint 2: C:\temp>tracert c.eset.com Tracing route to c.cwip.eset.com [38.90.226.12] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 41 ms 42 ms 55 ms nwblwihed11-lag11-433.network.tds.net [184.61.161.97] 4 40 ms 41 ms 33 ms nwblwidst52-tg0-0-2-0.network.tds.net [64.50.229.61] 5 35 ms 36 ms 34 ms chi-b23-link.ip.twelve99.net [80.239.135.66] 6 * * * Request timed out. 7 34 ms 34 ms 34 ms be2766.ccr42.ord01.atlas.cogentco.com [154.54.46.177] 8 56 ms 56 ms 60 ms be2832.ccr22.mci01.atlas.cogentco.com [154.54.44.169] 9 57 ms 58 ms 63 ms be3036.ccr22.den01.atlas.cogentco.com [154.54.31.89] 10 84 ms 85 ms 82 ms be3047.ccr21.elp01.atlas.cogentco.com [154.54.1.125] 11 85 ms 79 ms 82 ms be2930.ccr32.phx01.atlas.cogentco.com [154.54.42.77] 12 92 ms 91 ms 91 ms be2941.rcr52.san01.atlas.cogentco.com [154.54.41.33] 13 91 ms 87 ms 93 ms te0-0-0-35.nr61.b036483-1.san01.atlas.cogentco.com [154.24.24.186] 14 110 ms 105 ms 111 ms 38.88.58.18 15 105 ms 88 ms 92 ms 38-90-226-12.ptr.eset.com [38.90.226.12] Trace complete. C:\temp>tracert c.eset.com Tracing route to c.cwip.eset.com [91.228.165.44] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 40 ms 34 ms 33 ms nwblwihed11-lag11-433.network.tds.net [184.61.161.97] 4 43 ms 41 ms 35 ms nwblwidst52-tg0-0-2-0.network.tds.net [64.50.229.61] 5 43 ms 44 ms 59 ms chi-b23-link.ip.twelve99.net [80.239.135.66] 6 52 ms 60 ms 59 ms nyk-bb2-link.ip.twelve99.net [62.115.137.58] 7 126 ms 132 ms 124 ms ldn-bb1-link.ip.twelve99.net [62.115.113.21] 8 * 150 ms 152 ms prs-bb1-link.ip.twelve99.net [62.115.135.25] 9 149 ms 146 ms 147 ms ffm-bb1-link.ip.twelve99.net [62.115.123.12] 10 149 ms 149 ms 151 ms win-bb3-link.ip.twelve99.net [62.115.137.203] 11 151 ms 148 ms 150 ms win-b2-link.ip.twelve99.net [62.115.114.185] 12 152 ms 146 ms 159 ms 87.128.239.252 13 150 ms 218 ms 153 ms 80.150.170.82 14 152 ms 153 ms 156 ms st-static-bckb-22.213-81-252.telecom.sk [213.81.252.22] 15 * * * Request timed out. 16 * * * Request timed out. 17 156 ms 154 ms 152 ms h1-c04-s.eset.com [91.228.165.44] Trace complete. C:\temp> 2yn0vn2 Joshcollected_eset_logs.zip 399qnq2 collected_eset_logs.zip

I have ruled this out as a possibility and verified that the computers are only on one internet connection (wifi), enabled google public DNS on the wifi connection, and disabled IPv6 on the Wifi network controller. At this point, the most problematic machines are ones that connect/disconnect from our VPN while on wifi. The vast majority of our systems that connect to this VPN do not have any issues, its just a small handful of PCs

Ya, What I found is the following: V9 Seems to help with this issue Some of the endpoints I was able to fix by changing their Wifi DNS to Google public DNS Some of the endpoints connect/disconnect from a VPN on a regular basis, These endpoint are still problematic with this error and suspect that the network switching to be the issue. As for logs, I will be enabling logging on a few of the endpoints to narrow this down.

Its not just one machine, its several, is there a policy option that can be enabled to re-route this connection through the ESMC Server? Its possible that there are a few machines that change wifi networks or connect/disconnect from the VPN as well. If a policy based option is not available, then I would be able to gather the requested logs from some of the worst offenders, however, like i said, we do not control the network connections of most of these endpoints so attempting to reach out to the ISP or modifying router settings is not a realistic option in most cases.

We get this error on a number of our endpoints who are working from home. There are all personal internet connections the we do not control. Is there a way to route this connection though the ESMC server? This never use to be a problem in older versions of eset until they changed the way that this attempt to reach the server.

Marcos, Sent you a PM with the logs collected from one of the problematic endpoints

Hello Marcos, This is happening on multiple endpoints with multiple ISPs. However, our users do jump on/off a VPN connection on a regular basis, and at least today, 7 end points were affected, 4 were connected to a VPN connection at the time of the error, one was on wifi and a ethernet connection at the same time, 2 were directly connected to the internet via a network cable and not on a VPN/Proxy. We have Proxy auto detection turned off on all of our endpoints so these endpoints should not be using a proxy. I will attempt to gather the requested logs from at least one endpoint.

We are running into this problem as well with multiple random endpoints. From my testing, rebooting the endpoint seems to resolve the issue at least temporality, but then the problem can re-occur on the same endpoint days later.

Ya, Sure. One more item of information, If I run into this, I have also found that I can unplug the network cable and then plug in the network cable during the same boot provided that I do not switch networks and it seems to pick up on the correct profile. Note, All 4 images below are referring to the "USB 10/100/1000 LAN" interface Image1 - computer did not have USB NIC plugged in on boot, USB Nic was plugged in after logging into MacOS Image2 - Unplugged network cable, plugged network cable back in, on the same network as image1 (Work) Image3 - Unplugged network cable, plugged network cable back in On a different network then image 1, should be public Image4 - Unplugged network cable, plugged network cable back in, Same network as Image3, should be public

Equipment: Macbook Air running Catalina and 6.10.300.1 with USB network adapters/docking stations We have a firewall profile called WORK. I have set the activators on this profile to be based on subnet. I have also tried IP range. If the USB network adapter is plugged in on restart or boot everything works fine and the correct profile, WORK is selected. If the network adapter is plugged into the machine after the machine is booted, then all we get is ??? for what profile has been selected and the profile seems to default to PUBLIC. For our application, setting the network profile by interface name is not workable as we do not want certain firewall setting to be enabled if they say go home and connect to their home network. Is there any solution to this other then to reboot the machine? We have had this issue with Macs since we started using Eset on macs 2 years ago so this is not something new with the latest version. However, we plan on deploying more then just a hand ful at this point.

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

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.

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.

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.

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.