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