itman

Sucuri scan is clean: https://sitecheck.sucuri.net/results/https/samples.rebackoffice.com/client/eleven-seventeen-interactive-stacking-plan/ .

The problem here has nothing to do with VPN usage. In fact, the only person who posted in the forum using a VPN resolved the issue: https://forum.eset.com/topic/38859-limited-direct-cloud-connectivity-issue/#comment-176295

Although the TrendMicro notes Rhysida ransomware attack vectors, an article by Checkpoint explains them better; https://research.checkpoint.com/2023/the-rhysida-ransomware-activity-analysis-and-ties-to-vice-society/ The primary attack method was via RDP; something that really shouldn't be used in corporate environments these days. Also, PSExec use should also not be deployed and its execution blocked or monitored.

The first thing to realize with ver.17 is that redirect to financial web sites when running the browser in non-always secured browser mode doesn't exist anymore. I suspect this has something to do with your not seeing the green border you are referring to.

Eset firewall issues with return from Win sleep mode is another issue that has never worked right on any Eset version I have used and I am on an Ethernet connection. As best as I can determine, the Eset firewall doesn't initialize fast enough resulting in blocked outbound network traffic including blocked DNS traffic. I suspect a Wi-Fi connection only exacerbates the issue. I resolved it by creating a firewall rule specifying my assigned IPv4 device address as remote IP address and my assigned IPv4 assigned gateway/router address as the local IP address. You will have to ponder this one for a while. Finally, I try to avoid Win sleep mode altogether and just shutdown my PC instead when not in use.

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.