itman

First, all avcloud.e5.sk resolved IP addresses are correct. The difference between my avcloud.e5.sk IP address resolution is I resolved to LiveGrid servers in the IP address 38.90.xxx.xx and domain h5-c0x.eset.com range. I am assuming this is a different Eset server. Also note that for DNS server xxxx:xxxx:1dff:fea5:4445, local DNS Server name is unresolved. That is a problem. Since this appears to be a native IPv6 network, I assume the ISP is using 6rd tunneling, like mine is, to convert IPv6 addresses to IPv4 format. Upon receipt by ISP network assigned tunnel broker server, the IP address is converted back to an IPv6 format address and forwarded to its final destination. I can't begin to describe the nightmare I have had with Eset networking processing to get the 6rd tunneling to work correctly. Eset networking is totally clueless about this type of tunneling activity.

Perform nslookup of avcloud.e5.sk as I posted previously.

Based on the IOC's linked in the TrendMicro analysis of the malware here: https://www.trendmicro.com/en_vn/research/23/h/an-overview-of-the-new-rhysida-ransomware.html , Eset detects existing known variants of it.

Another thing that needs to be done is to perform a nslookup to Eset LiveGrid domain as shown in the below screen shot: First, the DNS IP address resolution should be instantaneous. Next, the Server address shown should correspond to a DNS domain name associated with your ISP or third party DNS provider; e.g. Cloudfare, if so assigned. Most important, the Address shown should be an IPv4 or IPv6 DNS address associated with your ISP or third party DNS provider. Finally, avcloud.e5.sk domain resolved IP address should be displayed. If all the previous is not applicable, there is a problem with DNS processing on your device.

Same here and I opened every link shown on the web site home page.

Check out this posting: https://forum.eset.com/topic/38890-eset-browser-privacy-security-extension-installed-without-user-permission/ . User states he never received the Eset notification to add BP&S extension in Chrome and it was Chrome itself that alerted on attempt to add a new extension.

You would have to set the current date/year for your Windows installation back to Dec. 6, 2023 via Windows set current date/time option. Since Windows has problems when the current date/time is not properly set, this might cause problems with Windows operation itself. In any case, you have been warned that re-installation of your current Eset product is far from a "slam dunk" event.

There is another possible explanation here based on the above posted DNS log entries. It appears that both DHCPv4 and DHCPv6 are being deployed to assign actual ISP DNS servers IP addresses from the router. Some router/gateways; notably AT&T issued ones, are slow to respond to assignment of DNS server IP addresses and end up timing out prior to assignment being made. One possibility here is ver. 17 is not waiting long enough for DNS server assignment to be made and defaulting to DNS resolution failure.

Another Eset ver. 17.0.15 user was having this same problem: https://forum.eset.com/topic/38859-limited-direct-cloud-connectivity-issue/#comment-176295 . He was also using a VPN and appears to have resolved the issue by excluding ekrn.exe and equi.exe from the VPN processing. Hence, my prior question in regards to VPN usage.

There are multiple recent malware that are performing AMSI bypasses. This might be related to one of those. I would perform a full admin level Eset scan and see if it detects anything.

Yes until Eset discontinues support for ver. 16.

Refer to this Eset posting: https://support-eol.eset.com/en/trending_weol2023_10_2022.html . The important part to note is;

If you are referring to engaging Sucuri to remove the malware from your web site, the answer is obviously no.

Are either of you using a VPN?

Not sure this is an Eset problem. According to this; https://www.reddit.com/r/privacy/comments/13canhc/a_guide_on_how_you_can_enable_ech_and_http3_in/ On my Firefox installation, network.trr.mode is set to default setting of 0. Force setting it to a value of 3 still does not enable Secure SNI. Also it appears this is the correct Cloudflare HTTP/3 test: https://cloudflare-quic.com/;

The first question is where did you purchase your Eset license from?

Eset needs to clarify license purchases from authorized third party sources in light of the new ver. 17 subscription model with forced use of Eset Home portal. The main advantage in the past was by purchasing a license from a third party. one could activate the new license by license key when the existing subscription expired. It appears license activation by license key is no longer possible for ver. 17?

That's a great deal at Eset U.S. eStore web site - 50% off normal retail price. As far as when the Eset subscription starts in regards to Eset eStore purchases, it starts at time of purchase. Now if you perform an existing Eset license renewal purchase, any remaining time for your existing license is added to the license renewal duration. Unfortunately, the Black Friday discounts don't apply to license renewals.

I am wondering if this issue is due to Eset reverting to Google DNS 8.8.8.8 server when it has cloud connectivity issues? This might not play nicely with the VPN being used.

First, you will have to uninstall ver. 17.0.5. Prior to doing so and if you have made custom changes to Eset default settings, ensure you export your existing Eset settings. Next, refer to this article:https://support.eset.com/en/kb2885-download-and-install-eset-offline-or-install-older-versions-of-eset-products. Scroll down in the web page to this section, Earlier versions of ESET Windows home products. Download ver. 16.x for your respective Eset product. After ver. 16.x completes installation, import your exported Eset settings if done so previously.

As far as Win 10 22H2 Nov. update, MS pushed additional updates besides the cumulative and .Net update listed in the below screen shot. It's possible the Eset WSC issues is related to one of those;

There's a bug in the ver.17.0.15 in-product upgrade installer. It is installing Browser Privacy & Security with "Display Browser Privacy & Security notifications" disabled.

After Win 10 22H2 Nov. cumulative update, my build no. is 19045.3693 and this is the one Eset ver.17.0.15 is causing WSC event log errors. Also within this Win Update was a .Net update but don't believe that is the source of the problem

As far as a strong possible suspect in regards to the Win Nov. cumulative update, Microsoft patched a zero day vulnerability in SmartScreen. Since SmartScreen directly interfaces with WSC, "my money is on" this being the the source of conflict with Eset and WCS processing at system start up time.