Eset Internet Security v11.0.159.9 update to v11.1.42

[senna 3]

5 hours ago, Marcos said:

If you would like to install EIS 11.1.51 release candidate, you can download it from:
ESET Internet Security 32-bit
ESET Internet Security 64-bit

This version has passed QA testing and will be released very soon, probably as version 11.1.52. It addresses all known issues reported with v11.1.42.

@Marcos

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

[Marcos 5,071]

13 minutes ago, senna said:

@Marcos

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

It's it detected upon download ?

[senna 3]

@Marcos

No it's not. I can download it (8kb file) and can perform a manual scan but it's not detected as malicious

[itman 1,659]

5 hours ago, Marcos said:

If you would like to install EIS 11.1.51 release candidate, you can download it from:
ESET Internet Security 32-bit
ESET Internet Security 64-bit

This version has passed QA testing and will be released very soon, probably as version 11.1.52. It addresses all known issues reported with v11.1.42.

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.

Edited April 16, 2018 by itman

[itman 1,659]

40 minutes ago, senna said:

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

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.

[senna 3]

15 minutes ago, itman said:

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.

Yep. Using Microsoft Edge the tesfile is blocked. Using Firefox (v.59.0.2) it's still not working.

Edited April 16, 2018 by senna

[itman 1,659]

@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.

[Marcos 5,071]

13 hours ago, itman said:

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.

This is highly unlikely related to ESET. We are pretty much sure that uninstalling ESET would have no effect on this.

Quote

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.

I have informed in the appropriate topic that the event will be eliminated as of the HIPS module 1316. It's not meant to be fixed in the product itself.

[Marcos 5,071]

13 hours ago, itman said:

Upon installation, I noticed it created network adapter connections for 6to4 and ISATAP.

We use whichever protocol is available. If IPv6 is not available, we communicate over IPv4. Nothing has changed in this regard for ages I would say.

[itman 1,659]

5 hours ago, Marcos said:

This is highly unlikely related to ESET. We are pretty much sure that uninstalling ESET would have no effect on this.

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.

 

5 hours ago, Marcos said:

We use whichever protocol is available. If IPv6 is not available, we communicate over IPv4. Nothing has changed in this regard for ages I would say.

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. 

Edited April 17, 2018 by itman

[psychopomp1 5]

Hi

Does anyone know why I was able to upgrade within the software from v11.0.159.9 to v11.1.42 on my Windows 10 32 bit PC, however on my Windows 10 64 bit PC, no updates are available to v11.1.42, and it is still stuck on v11.0.159.9 ?

Cheers

Edited April 18, 2018 by psychopomp1

[Marcos 5,071]

37 minutes ago, psychopomp1 said:

Does anyone know why I was able to upgrade within the software from v11.0.159.9 to v11.1.42 on my Windows 10 32 bit PC, however on my Windows 10 64 bit PC, no updates are available to v11.1.42, and it is still stuck on v11.0.159.9 ?

Currently the latest available version is 11.0.159. We will resume updates to v11.1 (probably v11.1.52) soon. New v11.1 installers have passed QA tests and will be released within the next few days.

If you want to install v11.1 manually now, download it from the links posted above and install it over your current version.

[itman 1,659]

@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?

[Marcos 5,071]

The interval has been about 15-20 minutes for a quite long time already so it's nothing new in v11. Of course, the program may query LiveGrid servers for information about specific objects  as needed.

[itman 1,659]

@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?

[Marcos 5,071]

I don't see anything wrong with that. As long as the LiveGrid feedback is enabled, it is normal that nfi files may be created in the charon folder. Please provide me with the nfi file for perusal.

[itman 1,659]

3 minutes ago, Marcos said:

I don't see anything wrong with that. As long as the LiveGrid feedback is enabled, it is normal that nfi files may be created in the charon folder. Please provide me with the nfi file for perusal.

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

FND0.NFI.txt

[itman 1,659]

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

[itman 1,659]

@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.

Edited April 19, 2018 by itman

[itman 1,659]

@Marcos, another FYI. Same behavior I posted above in regards to return from standby mode is occurring if the LiveGrid option to submit detected malware is enabled. This one is a bit more predictable. Appears if LiveGrid detects anything in Quarantine, it triggers the continuous LiveGrid port scanning that never ends:

A FND1.NFI file is created. A bit ludicrous to say the least. Since Eset already detected the malware by signature, there is no reason to upload it again to LiveGrid for further analysis.

So it goes without saying, LiveGrid detected malware option is also now disabled. 

[itman 1,659]

Another possibility is there might be an issue with how LiveGrid is detecting Quarantined files in ver. 11.1. I forgot to mention that I had multiple files previously in Quarantine. All those files were test malware files from places like AMTSO and Wicar.org. As such, they were all detected originally by positive signature detection.

[Marcos 5,071]

If a file is detected doesn't mean that it won't be submitted. Even in the LiveGrid feedback submission setup, you can set actions separately for infected and suspicious files. And even if an nfi file is created, it may be refused by LiveGrid servers and would be subsequently deleted, e.g. if somebody else has already submitted it.

Another question is if the nfi file was really related to the above mentioned detection. If you would like me to check, provide the nfi file.

[itman 1,659]

7 hours ago, Marcos said:

And even if an nfi file is created, it may be refused by LiveGrid servers and would be subsequently deleted, e.g. if somebody else has already submitted it.

That's the problem as I see it; the NFI file never gets deleted. Hence the constant LiveGrid polling activity.

7 hours ago, Marcos said:

If you would like me to check, provide the nfi file

Here it is:

FND0.NFI.txt

[itman 1,659]

@Marcos, actually here's what occurs since I was monitoring this activity.

1. Eset immediately detects the wicar malware upon execution.

2. Eset and native SmartScreen alerts are displayed. I have "strict cleaning" set in Realtime scan options. As such, file is immediately deleted and placed in Quarantine.

3. At this point, no FNDx.NFI file exists. So I assume that the processing you described took place; submitted to LiveGrid, rejected since already detected, and any associated FNDx file deleted. I also visually verified at this point no NFDx file exists.

4. PC later enters sleep mode due to inactivity.

5. Upon resume from sleep mode, FNDx file exists and never ending LiveGrid connection looping starts.

[Marcos 5,071]

31 minutes ago, itman said:

That's the problem as I see it; the NFI file never gets deleted. Hence the constant LiveGrid polling activity.

Is such small nfi file created even several times a day every time the system wakes up from hibernation? Do you run scans with Windows Defender?