itman

Since FireFox appears to be the issue, the best solution is to export Eset's root CA store certificate and import it into FireFox's Authorities certificate store. You can export Eset's root CA store certificate from either the Eset GUI itself or using Win's certmgr.msc utility. This article will show you how to use certmgr.msc to export the Eset root CA store certificate: https://www.thewindowsclub.com/certmgr-msc-certificate-manager-windows. Note that the Eset certificate is located in the "Trusted Root Certificate Authorities" folder. Save the certificate to your desktop or where ever. You can then import the Eset certificate into FireFox's Authorities CA store. Symantec has a guide on how to do the importing here: https://portal.threatpulse.com/docs/sol/Solutions/ManagePolicy/SSL/ssl_firefox_cert_ta.htm . Note: Do not checkmark the SSL 3.0 option.

Considering the "chaotic" situation the Firefox browser is presently in; e.g. letting its root certificates expire, multiple rapid fire updates to fix it, etc., this FP by Eset is perfectly understandable.

"Click once" are .Net based apps and Microsoft intentionally made this registry modification for security reasons on Win 10: https://en.wikipedia.org/wiki/ClickOnce Note what I underlined above. Bottom line - these types of apps can silently install which makes them an ideal delivery mechanism for malware payloads. My next question is why is NAV using ClickOnce methods for updating purposes?

Appears to be an Eset issue. It was a false positive detection. They happen with all security software. Thankfully and historically, they are a rare occurrence with Eset software.

See this: https://forum.eset.com/topic/19491-firefoxvisualelementsmanifestxml-generikhbkpftf-trojan/?do=findComment&comment=95058 . Eset pushed a module update about a hour ago; at least in the U.S., to fix the issue. If you're still getting the Eset alert detection, manually perform an Eset update.

Poster on wilderssecurity.com related the following: Since this is a generic detection, hopefully its a FP. Otherwise, "the Firefox world" has "big problems." I would also submit the file to Eset as a possible FP.

Submit the Firefox directory based .xml file for a scan at VirusTotal. If no one except Eset detects, it is probably a FP. Note that the fact the file is showing up in your User\AppData\Local\Temp directory is not a "good sign."

This article should explain what Win services are used by both Eset firewall and IDS processing: https://support.eset.com/kb2906/ . Enabling/disabling noted services will cause the Eset firewall rules to be correspondingly modified to reflect the change.

If you employ an ad blocker in your browser, you could probably still use the web site. As I posted previously, I received no Eset alert in IE11 which employs AdBlock Plus ad blocking when I accessed the site.

Getting back to the VM issue, was Eset installed on both the host and the VM? Also there might be a licensing issue here in that a separate license or seat of multi-device license might be required for both the host and VM. I could not find an Eset knowledgebase article for Eset Home versions but I assume the below applies to them: https://support.eset.com/kb3674/?locale=en_US&viewlocale=en_US

As far as I am aware of, Eset firewall Zone categories are nothing more than a "shorthand" method to refer to multiple IP addresses. The are only used in firewall rule creation for that specific case. The fact that IP addresses are not shown in the DNS address zone is irrelevant since that zone is never specifically reference in the Eset default firewall rules. The most important zone is the Local Addresses zone and for the Work or Home network profile, the Trusted Address zone, since these zones are referenced in multiple Eset firewall default rules. The above said, the fact that IP addresses are not being populated to their respective firewall Zone categories would be indicative that Eset is not properly interfacing with the device's active network adapter connection. It appears to me that something is "busted" firewall-wise in your and the OP's Eset installation in regards to this "Error: nonexistent zone" message. For a test you can create a firewall rule specifying the DNS address zone and see if the same error message manifests.

Eset Network Potection acquires DNS server addresses based on the Windows network adapter it discovers at installation time. See the below screen shot. Additional Local Connection IP address are populated based on network adapter settings. On my Eset installation both IPv4 and IPv6 DNS server addresses are correctly populated.

As I posted previously, I do not receive the error. Switch to the Public profile and create a firewall rule specifying the Trusted Zone. If you don't receive an error on the Public profile, then we can establish the problem lies on the Private/Home Network profile.

My best guess at this point is the issue is VM related. Since nothing is populated Firewall Zones settings, you can't refer to any of the categories listed directly in the firewall rules. What I would test is that the ESET firewall is functioning properly in the VM. What I suspect might be going on is its just allowing all inbound and outbound traffic.

I am on Eset's Public profile. In sprite of this, I had no problems creating both inbound and outbound rules specifying the Trusted Zone. Now I do have the Firewall filtering mode set to "Automatic." So one factor might be your "Interactive" mode setting. To verify, temporarily switch to Automatic mode and see if you can now create a firewall zone specifying Trusted Zone. Another factor might be the VM element you running under. The Eset firewall might just not recognize Trusted Zone in that environment under the default global profile it uses. The Eset firewall by default applies all existing firewall rules to all recognized network adapters. I suspect the VM is using that "localdomain" Eset network connection and something about this setup is "confusing" Eset when it comes to finding the Trusted Zone.

Is that "localdomain" network entry associated with a domain controller on your network?

Also far as the Eset alert description goes: https://www.virusradar.com/en/HTML_ScrInject/detail As far as the URL referenced, https://www.limetorrents.info, it appears to be clean: https://www.urlvoid.com/scan/limetorrents.info/ Follow the procedure here to info Eset that you believe the URL detection is a false positive: https://forum.eset.com/topic/18734-how-do-i-report-a-false-positive-or-whitelist-my-software-with-eset/ Finally, I was just able to access https://www.limetorrents.info w/o issue in IE11. The site might now be unblock by Eset.

Ignoring the Trusted Zone issue for the time being, my primary concern is why the OP's DNS servers and Local address are empty in the Firewall zones GUI display. Those two areas need to be populated for the firewall to function properly.

Thanks!

Agreed. However in the OP's case, it appears no network adapter connection is being recognized by Eset. @jimmerthy post a screen shot of what is displayed in Eset's Known networks section as shown in my above reply.

It appears you have never setup any network adapter connection in Eset. Note that your Eset Firewall Zones screenshot is empty. At a minimum, Local and DNS addresses section should be showing IP addresses: Refer to the below screen shot to determine if any discovered network connections exist:

Provide your Eset public license ID as previously requested. See the below screen shot to find where it is located:

Here's an interesting posting: https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/chromium-host-executable-shows-high-cpu-usage.html . You might want to add the following to your Eset exclusions:

That might be your next step since I am out of ideas.

Were these recommended directories and executables excluded in Eset? https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/Are-there-antivirus-exclusions-I-can-implement-to-make-programs-run-better.html