itman

Have no idea since I haven't used MBAM for years. Like any realtime scanner, it shouldn't be installed as such on any PC using PCMatic, Eset. or any other realtime AV solution.

To begin with, I have never had FireFox installed on any Win 10 build on my PC. It currently has x(64) 1809 installed. As such, I have no old and possibly borked Firefox files and registry entries from prior versions of it, etc.. To get to the bottom of this current FireFox baloney in regards to EIS 12.1.34, I went to the Firefox web site and downloaded and installed it. I believe the current ver. is 66. I then opened FireFox and checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was not there as expected. I then rebooted the PC to try to simulate the behavior posted in this thread; namely if "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" alert/log entry would manifest. It did not. I then again checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was there as expected: Finally, I rebooted again to see if I could see if Eset would created the "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" alert/log entry. It did not. All this leads me to believe that whatever is causing this behavior on user's PC's has nothing directly to do with the Eset installation but rather, some misconfiguration issued with their current Firefox installation. I would advise uninstalling Firefox, clearing out all past remnants of it on your OS installation, and rebooting. Then install the current version of Firefox from the Mozilla web site and repeating the installation steps I posted above. As far as running development or beta versions of Firefox concurrently with Eset, you do so at your own peril; just like if you were running a pre-release ver. of Win 10.

Yep. Alive and kicking. AV-Test includes them in their consumer test series. It is still "the king" of FP detections though drastically improved from the days when the FPs numbered in the thousands.

It appears to me this "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" message is being generated when Eset can't access Chrome's or FireFox's certificate store to verify that the Eset certificate is installed. As has been noted, the Eset certificate actually exists in these browsers and yet the Eset log event keeps recurring. This activity would be indicative of some type of permissions issue in regards to Eset accessing either Chrome or FireFox internally. Is Chrome's or FireFox's sandbox feature enabled by anyone having this issue?

The only U.S. based AV concerns I can think of are McAfee, Symantec, Malwarebytes, and PCMatic. And Symantec is questionable since most of their operations are in India these days.

It just started working again! Question is ……. for how long?

https://support.eset.com/kb6308/

Also and unless Eset change this option in regards to this: You have to manually store the web site the certificate as shown below, or do as @Marcos posted and set SSL/TLS filtering to Interactive mode and have Eset auto create the web site certificate:

In this instance, you can disable Eset SSL/TLS scanning for the app by setting the app status in "List of SSL/TLS filtered applications" Scan Action to "Ignore." If that doesn't work, your can exclude the app altogether from SSL/TLS protocol filtering by entering its related .exe into Protocol Filtering -> Excluded applications section.

I will make this general statement. FireFox is so screwed up presently, I just wouldn't use it for anything.

Yeah, I assumed that is what you meant. Just did the "local" bit to see if that would have any effect.

Yes, you can. Also remember a reboot is required for new registry settings to become effective.

When I initially entered the Eset forum web site 10 mins. ago, signed on users were displayed. Then out-of-the-blue, they are no longer being displayed. Flushed IE11 cache, shut it down, restarted it, all to no avail.

Are you still getting the Eset alerts?

Yep. Same here. It was working OK this morning though. Eset needs to dump Cloundfront. Ever since they have been using their servers for the forum, I have had various issues. Web site security is great as long as it doesn't negatively impact usability.

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