itman

That option still exists. But enabling it will cause everything to be written to all log files.

One other point about Eset's exploit protection. It is limited in scope in what it protects as noted below. Also in reality, it does not focus on CVE noted vulnerabilities. As such and in regards to application software outside of the scope noted, I would not rely on Eset's exploit protection in regards to application software vulnerabilities. https://www.eset.com/int/about/technology/

As far as the not patched local privilege escalation vulnerabilities, I would say the answer is no. As best as I can determine, no official CVE's have been issued for these. Eset's exploit protection protects against CVE recorded vulnerabilities. Ref.: https://www.cvedetails.com/vulnerability-list/vendor_id-10/product_id-33528/HP-Support-Assistant.html Note that the above CVE reference shows 5 vulnerabilities associated with Support Assistant. Three of these show they have been mitigated and two as partially mitigated. I can't however determine if any of these CVE's are directly related to the unmitigated vulnerabilities noted in the original posted article. As far as HP Support Solutions Framework, nothing has been listed since 2015. Ref.: https://www.cvedetails.com/product/31497/HP-Support-Solution-Framework.html?vendor_id=10

At this point, I would say that something in Windows Security Center is corrupted preventing Eset from properly registering there. Also whatever the issue is, it appears that Eset is indeed being initialized in WSC correctly but Eset is not recognizing this and is creating the log entries being observed. Another possibility is there is an issue for some reason with Eset's ELAM driver. Win 10 verifies that this driver is loaded and functioning properly and this activity is factored into WCS initialization processing. There also might a permissions issue in regards to Eset being able to access WSC settings, possibly in the Registry, to properly initialize itself in WSC. I have searched for articles on how to repair WSC and have come up empty. There are articles on how to reset Windows 10 security settings back to default that you might want to try. The final alternative is to run a Win 10 Repair which will keep all your files in place. You will however have to reinstall all your apps including Eset.

Correct. But you can't enable the Controlled Folder Access option if you are using a third party AV solution. WD has to be the active real-time solution in order to enable the Controlled Folder Access option.

Appears to be the setting indicated in the below screen shot. Also, enabling this will most likely create log entries for all network activity; not just blocked connections:

https://d4stiny.github.io/Several-Critical-Vulnerabilities-on-most-HP-machines-running-Windows/ I personally would opt for the uninstall option.

You should be able to uninstall the version of Smart Security on the laptop via the way you uninstall any other app. Namely, open Control Panel -> Programs -> Uninstall a program. Reboot after the uninstall is completed. Then download the current version of Smart Security as done previously and install it on the laptop.

Are you still getting update errors in the Eset Event log?

Assuming you're using Win 10, refer to this article: https://support.microsoft.com/en-us/help/4028379/windows-10-how-to-use-remote-desktop . This also only applies to client to client PC connections. To utilize full RDP connectivity in a client to server scenario, you need to have Win 10 Professional or above installed. The Win 10 Home version does not support full RDP connectivity. An alternative here is to determine if your workplace allows remote connection via a VPN connection.

I really don't don't know what you are referring to here. Windows Defender Controlled Folders option only applies if Windows Defender is the active real-time protection solution. If you have Eset installed, it is the active real-time solution and should be reflected as such in Windows Security Center. Activating the Windows Defender Periodic scanning option does not enable the Controlled Folders feature. In regards to this: I have never seen like setting. I do suspect however it might be indicative of both Eset and Windows Defender real-time scanning being enabled which should not happen if Eset was properly installed.

Sadly, this issue isn't restricted to fake certs.. Legit certs. have been stolen. The attackers then proceed to sign their malware code with them. In a couple recent incidents, stolen/misappropriated driver certs. were used. Now you can't get better than that. Win 8.1/10 Secure boot will protect you here but you need to have the hardware to support it. Bottom line - anyone in "the security know" will flat out state the whole certificate concept is completely broken. But that's a topic for wilderssecurity.com or malwaretips.com posting and discussion.

The above malware reference also brings up the issue if this move by FireFox/Eset to defer to the Win root CA store is the most secure thing to do?

It really appears everything is OK with Windows Security Center and Eset's registration of itself within. I would think that this flickering you are observing is more related to an issue with your graphics card/chip. Or possibly an issue with the driver/s it is using.

Interesting. Appears the Eset cert. in the Win root CA store got corrupted somehow. Never seen that one before. However, there are malware that have been known to deploy certmgr.msc; e.g. https://thehackernews.com/2018/07/cryptocurrency-mining-ransomware.html . Maybe something escaped your VM with all the malware testing you do?😬

This is the standard display from Firefox when a third part root certificate is being used. It has always been displayed as such. You probably just never checked the HTTPS certificate status previously. -EDIT- The message display is slightly different now that FireFox is now deferring to the Win root CA store; i.e. security.enterprise_roots.enabled.

That's strange. Really don't know why a License key would be required for an uninstall. Here's a link on how to both use and download the Eset uninstaller tool for whatever Win version you have installed: https://support.eset.com/en/kb2289-uninstall-eset-manually-using-the-eset-uninstaller-tool . Note this must be run in Win Safe mode. Note: If this is a Win XP device, the OS needs to be upgraded to use any current Eset product. Once that hopefully successfully completes, boot back into normal Win startup mode. Download the current version of Smart Security Premium from here: https://www.eset.com/int/home/smart-security/download/ and install it. Then use the upgraded License key you purchased to activate it.

Based on the screenshot you posted here: https://forum.eset.com/topic/23125-certificate-issues-for-firefox-740-64bit/?do=findComment&comment=111963 and per @SeriousHoax previous reply to you, Eset's cert. is being used by FireFox w/o issue. So I really don't know what leads you to believe it is not.

I have a theory of what is going one here. It manifests when multiple Eset root CA certificates exist in the Windows root CA certificate store. Eset's root CA certificate is signed with a private key. That key is stored somewhere in the directories Eset creates at installation time. Whatever Eset certificate FireFox is extracting from the multiple ones stored in the Windows root CA certificate store has a private key that does not match the one currently stored in the applicable Eset directory. Hence use of the certificate extracted is rejected by FireFox. I would assume that the latest dated Eset root certificate in the Windows root CA certificate store is the one being used by the current Eset installation but there is no guarantee that is the case. Refer to the below screen shot: 1. Open Eset GUI and navigate to Web and Email settings. 2. Open SSL/TLS settings. 3. Under Root Certificate section, mouse click on "View certificate." 4. Mouse click on the Details tab. 5. Scroll down to a line named Thumbprint. Mouse click on it which will duplicate the value to the box below it. Copy that thumbprint value and save it somewhere. 6. Exit the Eset GUI. 7. Enter certmgr.msc in Win 10 desktop Search bar. 8. Open certmgr. Then open Trusted Root Certification Authorities -> Certificates. 9. Now compare the prior saved Eset cert. thumbprint to the thumbprint of all Eset certificates shown. 10. When a match on thumbprint is found, keep that certificate and delete all the other Eset certificates present. 11. Exit certmgr. At this point, FireFox should only access the remaining Eset root certificate in the Win root CA store and there should be no longer any private key issues with FireFox's use of that certificate.

"To add more confusion to the mix," my FireFox updated to ver. 74.0.1.

I also just noticed that you are attempted to upgrade Eset Smart Security 9. That product is no longer supported: https://support.eset.com/en/kb3678-is-my-eset-product-supported-eset-end-of-life-policy-home-products . This could be the issue. I suspect that what you purchased perhaps is a two seat license for Internet Security? I know Eset Smart Security 9 is the last version supported on Win XP. But again, it shows end-of-life as of 12/2019. As such, I don't see how you could have purchased an upgraded license for it.

https://support.eset.com/en/kb7297-resolve-act-or-ecp-errors-during-activation-home-users Did you purchase your upgraded license from an authorized Eset source in the U.S.? Such sources would be the Eset U.S. web site, an authorized Eset reseller in the U.S., etc.. Also make sure that U.S. is selected as the country during installation. This should have been done automatically since the first three characters of the license key indicate country; e.g. USAX- .........

If "worse comes to worst," you can always switch to pre-release updates. Ver. 13.1.24 should then be available for update. Appears ver. 13.1.24 contains Internet protection module 1395.

Check the Eset cert. in Firefox and verify its OK. Then mouse click on Edit Trust tab and verify that its set to identify web sites.

One thing that needs noting as far as Internet protection module 1395. It has a date of 3/31/2020 associated with it. So unless you have this module in your Eset installation, Eset's root CA certificate still needs to be installed in FireFox's Authorities certificate store.