itman

@Marcos, there is definitely a problem with Eset LiveGrid statistical submission option in ver. 11.1.xx. I did some more testing and each time I enter standby mode via manual Win 10 standby option, a new FNDx.NFI file is created. Each new file creation results in 4 new LiveGrid connections being established. This explains my previous forum comments about my LiveGrid connections mysteriously increasing. For example, four standby events results in four FNDx.NFI files and 16 LiveGrid connections! Again my motherboard with is a bit dated and only supports S4 power saving mode. In this mode, the PC is actually powered down in standby mode. It goes w/o saying that LiveGrid statistical submission stays off in my Eset installation. In regards to my dual stack IPv4 and IPv6 network configuration, the issue appears to be related to the IPHelper service. When that service is active, a loopback; i.e. 127.0.0.0 connection, is established for it. At this point, Eset goes "bonkers." Since I have all the IPv6 tunnels disabled, the IPHelper service is not needed. As such, disabling the IPHelper service resolved the conflict with Eset.

Let's start all over again. Do you have the Eset firewall set to default settings? That is all outbound communication is allowed.

Please clarify what you mean. Are you referring to the fact that IE generates the outbound connection but other browsers do not?

Or are you stating this is a suspicious file awaiting Eset LiveGrid analysis? If so, why did it appear upon resume from standby mode?

File is attached. My main question is why did it take a day after installation for this behavior to exhibit? FND0.NFI.txt

@Marcos, there might be an issue with ver. 11.1.51 in regards to standby mode. Prior to entering standby mode today, the only file to exist in the directory, C:\ProgramData\ESET\ESET Security\Charon, was CACHE.NBD. Upon resume from standby mode, a file is created in the same directory named FND0.NFI as shown in the below screen shot: Contents of this new file is: Note that this file did not exist until resume from standby mode. With this new file creation, I am now observing four persistent LiveGrid server connections that were not present previously. Is this the way LiveGrid is supposed to work in 11.1.51? Why was this behavior not displayed upon initial installation yesterday?

Appears to be an Amazon backbone server located in Ireland per Robtex: If you are running the Eset firewall in Interactive mode, this connection is probably Microsoft dial-out activity from IE for "God only knows" what pupose; most likely telemetry.

Problem is it only applies to Intel processors. So if yours is AMD, you're out of luck.

@Marcos, how often is LiveGrid supposed to update under ver. 11.1.51? What I am observing is an update every 10 - 15 mins.; at least so far this morning. Is Eset now pushing the LiveGrid updates from the LiveGrid servers as required; only when an update occurs to the white/black lists?

Well, both GData and Sophos detect it as a PUA. Bitdefender, Emsisoft, Symantec, and TrendMicro didn't detect at all. Neither did Microsoft and a number of others. My guess is its packed malware bundled in an installer. Until the installer is run and the PUA is executed, malware properties won't manifest.

Appears that person didn't know what they were talking about. You can download Windows updates directly from the Windows Catalog Update web site here: https://www.catalog.update.microsoft.com/Home.aspx . Enter your OS and ver. in the search box; e.g. Windows 10 1709. Also using this search criteria, the cumulative updates are not shown for some reason. So you will have to enter Windows 10 cumulative for example. Finally, always ensure you download updates only for your OS, ver., and processor e.g. x(86) or x(64).

The issue mysteriously went away. I didn't see any new Win Updates installed as a result of the activity, so don't know what prompted it. I finally got this resolved and it wasn't easy. My ISP, AT&T, recent migrated IPv6 from 6rd tunneling, i.e. 6to4, to dual stack. In a dual stack configuration, both IPv4 and 6 connections are being sent. I have set my IPv6 connection to prefer IPv4 over 6 versus the default of preferring IPv6 over 4. I had also set the IP-HTTPS tunnel to disabled figuring it was no longer needed. Wrong! Appears Eset sends LiveGrid updates via IPv4 using the IP-HTTPS tunnel. What I observed was LiveGrid connections being made but no data being sent or received w/IP-HTTPS tunnel disabled. What was strange was with diagnostic logging enabled, LiveGrid didn't indicate there was any issues? My recommendation is Eset develop a LiveGrid diagnostic utility that can/should be run to verify LiveGrid is fully functional. Also and BTW, the AMTSO Cloudcar test is not adequate since the connection to LiveGrid servers is made directly w/o secure tunneling delivery being employed.

@Marcos, another potential issue I noticed in regards to ver. 11.1.41. Upon installation, I noticed it created network adapter connections for 6to4 and ISATAP. I have those IPv6 tunnels disabled by design on all IPv6 interfaces via DisabledComponents registry key setting. I need to know ASAP if Eset is sending LiveGrid updates using those tunnels. I don't know why it would be if IPv6 was set on for the network adapter and the ISP fully supported IPv6 as mine does.

It worked fine for me and I visually verified that an upload/download was made to Eset tsmxx servers. Now the behavior is the same as that for previous versions. Eset will alert and block. But in IE11 for example, you have to cancel or delete the IE11 download popup window. If you click "Save" from that window, the cloudcar test file will still download.

As far as the QA testing goes, appears the folks missed this one. Now at boot and shutdown time, I am receiving the Windows Update messages not to turn off the PC while updating is occurring or that Windows updates are being applied. Granted the displays are of short duration but this shouldn't be happening. Also if this behavior was intentional and to eliminate the registry key access denied event log issue, it is not working since that event log error is still appearing.