itman

If you enabled the "Secure all browsers" setting, you're already running in Protected browser mode. When you open Chrome, you should observe the web page border in green color indicating protected browser mode. Hence why no separate B&PP opening of Chrome web page when you visit your bank web site. Personally, I don't understand this new "Secure all browsers" option. In the past, Eset specifically instructed that protected browser mode should not be used for every day web browser use. Additionally, this mode always on has caused issues for me in FireFox.

Maybe this is the reason Eset didn't detect this exploit activity. It was the source of the activity? I find it way too coincidental that Eset was performing crypto activity at the exact second this exploit activity was detected. Time to totally roll back ver. 14 entirely or just get rid of SSL/TLS protocol scanning. I for one have about had it with this activity.

Try the "Restore to" option; assuming it's available, to copy the file to wherever. Then manually move the file to the admin share you desire. Note that if the file is not excluded from real-time scanning by Detection name prior to restoration, Eset will just quarantine the restored file when you attempt to access the file in any way. As such, exclusion by file hash value would be a better exclusion method.

Yes. Doubt it. First, what is the exploit: https://packetstormsecurity.com/files/155961/CurveBall-Microsoft-Windows-CryptoAPI-Spoofing-Proof-Of-Concept.html Note that the Microsoft Win root CA cert. is signed as sha384ECDSA. Next, the above posted screen shot clearly shows a SHA1 signing attempt with that cert.. The question is and outstanding is what attempted this? It is noted it was a user mode process.

Just noticed this in my Win event log: I assume Eset didn't detect source of this via IDS protection since Win 10 caught it? Also and coincidental to this, I have been receiving a TLS based SChannel error at boot time originating from lsass.exe which started on 11/2. Only one error per day regardless of number of restarts done during the day. Perhaps related to ver. 14 SSL/TLS issues? In any case, I have previously set lsass.exe to a PPL processs. So need to know if Eset is trying to inject its amsi.dll into it.

Also has been pushed to regular update channel.

Here's something else to try. The OP originally inadvertently deleted the file: https://social.technet.microsoft.com/Forums/en-US/f6b4bf4a-8a55-41b0-a330-fc0df6588c32/recover-product-key-after-deletion

Try to restore from quarantine to another work directory. This way "you can play" with its permissions as needed. Then move this restored file to System 32 directory.

I was referring to why Eset deleted the .vbs script in the first place.

That's fine as long as you realize nothing to/from that server will be scanned. -EDIT- Also if you're in fact using IMAP versus IMAPS in Thunderbird for this server, Eset is not performing any SSL/TLS interception since the network traffic is not encrypted.

It appears that Eset doesn't consider script files as critical "system" files even if located in System32 or SysWow32 directories.

As far as DISM use, here's all the supported platforms for its use: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/dism-supported-platforms If for some reason: DISM /Online /Cleanup-Image /RestoreHealth doesn't work, here's another method. See the linked article for further details: https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image

One thing I am wondering is if copying slmgr.vbs from System32 directory to SysWOW32 directory will fix this issue? File sizes are identical and the .vbs script is plain text. Also and most important, is the .vbs file missing from the SysWOW32 directory a major issue for anyone running Win 64 bit version? I assume Win will use the .vbs script in System32 directory for any license validations

I also believe that running sfc /scannow from admin command prompt window will also restore the file/s.

Also note the following that confirms Outlook relies on Windows Security Center: https://support.microsoft.com/en-us/office/i-get-warnings-about-a-program-accessing-email-address-information-or-sending-email-on-my-behalf-86cc5ece-379e-45e3-b8eb-3fefba09946b

Actually there is. This popup is displayed: https://thomas.vanhoutte.be/miniblog/solve-outlook-pop-up-a-program-is-trying-to-access-e-mail-address-information/ What needs to be explored is why Outlook is not recognizing that Eset Endpoint AV is installed. Perhaps a Windows Security Center registration issue?

Referring to this: https://support.microsoft.com/en-us/office/pop-and-imap-email-settings-for-outlook-8361e398-8af4-4e97-b147-6c6c4ac95353 , G-mail settings should be SSL/TLS.

Can you connect to the e-mail servers using TLS? Is there any reason you're using SSL?

I would compare the network information shown for the two connections and see what is different first. Also, deleting the second connection many times is not the solution since it will probably just reappear again.

Another thing to verify is that only one Eset certificate exists in the Win root CA certificate store and it is identical to the one shown in the Eset GUI in the SSL/TLS section.

First, read this a couple of times: https://help.eset.com/eis/14/en-US/idh_config_epfw_known_networks_editor.html?idh_config_epfw_known_networks_group.html . If you are using Eset's Home or office network setting, you shouldn't be seeing this type of activity. With this setting, all local subnet IPv4 and IPv6 addresses are automatically trusted. What causes a new network to be detected and set up in Eset is when something changes in regards to what was originally setup in the network adapter settings Eset detected. Those settings are shown in the network identification tab associated

This one is a mystery. I also use FireFox and its ver. is 82.0.2. I have zip HTTPS issues with Eset SSL/TLS protocol scanning enabled. Verify that FireFox's about:config parameters are configured per those highlighted in the below screen shot:

And just what does this mean? Protocol use is app dependent. Using Win 10 1903+ for example, all these cypher's are supported: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903 . And quite a few support below TLS 1.2 level.

I am starting to believe there is a Microsoft element to this issue. They are in process to deprecate all protocols below TLS 1.2+: https://docs.microsoft.com/en-us/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide One possible scenario in play here is Eset SSL/TLS protocol processing is allowing a protocol downgrade during the e-mail server handshake to something below TLS 1.2+. When Eset re-encrypts the e-mail and passes it on to Outlook, it is rejected by Outlook.

First, monitoring Win 10 individual services via Eset firewall is somewhat an effort in futility. Eset attempted that a while back in a prior release and quickly abandoned it. Hence, why all Eset default firewall rules for svchost.exe are not service specific. Why? Because there are many hidden services used by Windows that are not specifically listed or controllable via Control Panel -> Admin Tools -> Services. In regards to DoSvc, it is Win 10's Delivery Optimization service used to speed up downloading of Win Updates primarily but also used for other Microsoft apps. If Win 10 is