itman

In that posting I was referring to the default Log Maintenance scan. And it is running correctly now at its scheduled scan time. Note that the missed scan option for this event is ASAP. Try this. Set your missed scan time to 1 hour. See if the scan runs at boot time if your PC is powered off at the scheduled scan time.

Rebooted. Everything remains as I previously described including the release version. BTW - I am not an Eset insider unless someone enrolled me as such w/o my consent.

To clarify, this was a production update and not a pre-release update? I don't have pre-release updates enabled. Also my BP&P module is 1146 dated 3/1/2019.

For consistency, should not the browser redirected web page also not show the same BP&P layout?

The content isn't showing.

Win 10 x(64) 1809, Eset IS 12.1.31. When I just clicked on B&PP desktop icon, I see the following screen in IE11. It wasn't this way previously.

I believe category blocking capability; e.g. pornographic, etc.., sites only exists in Parental Control option of the Eset Home versions.

Did you uninstall Eset using the Eset Uninstaller utility in Safe mode as described here: https://support.eset.com/kb2289/?locale=en_US&viewlocale=en_US ? Also, return your OS default firewall and Win Defender settings. Disabling those in itself could cause Eset installation problems.

Its primary purpose is to allow Eset to intercept encrypted SSL/TLS traffic prior to entering the browser or e-mail client. Note however that Eset now scans all incoming SSL/TLS source. So all incoming app web traffic is being scanned. It then decrypts the traffic and examines it for malware. It then re-encrypts the traffic and forwards it to the target app. Without decryption, there is no way Eset can examine the traffic. Note that today with the almost all web sites and servers being HTTPS, disabling Eset' SSL/TLS protocol scanning puts one at considerable risk to Internet sourced malware. As far as your goes, it appears to be some type of hybrid router administration setup. Normally when one connects to their router/gateway via its locally assigned IP address, the connection never leaves the local network. Verizon appears to have "cloud" sourced some its router's admin functions. In other words, your actually connecting to Verizon servers to configure your router which is a bit strange. In any case, the Verizon alert you posted previously appears to be related to you having to accept the installation of its own self-signed root CA store certificate that will allow Verizon to also intercept SSL/TLS communication to/from your router. Most likely to perform the same type of malware scanning Eset's SSL/TLS scanning possibly; just for router admin maintenance purposes; or who knows what else they are doing? -EDIT- Another possibility is the connection to the router is now https based versus the usual http connection. Whereas the Verizon root CA store certificate to allow https router configuration is a legit use, that same certificate could be used to intercept all your https traffic for inspection by Verizon. This is highly unusual and personally something I would never allow my ISP to perform. Did you verify with Verizon that the certificate install request is legit? It could be a "spoofed" alert from an attacker to allow him to perform a man-in-the-middle attack

Actually this is an improvement since previously if a scheduled run ASAP scan was missed, it never ran until its next scheduled scan time.

If they were script based, PowerShell for example, and the script was encrypted, obfuscated, etc., Eset would not have detected it at file creation time. If you are running Win 10, Eset most likely would have detect it when the script was executed. As far as your case where a later on demand scan detected the ransomware, it assumed Eset had blacklisted it or created a sig. for it after the time it was downloaded to your HDD. So if it was subsequently executed a day later regardless of on demand scan status, Eset would have detected it upon start up.

We're "shooting in the dark" on this one without being able to identify the source process for this activity.

The file hash search came up with nothing which is not surprising. Here a link to a discussion of the malware on the Apple forum: https://discussions.apple.com/thread/8410305 . I can't vouch for anything recommended there especially uninstalling Eset. I saw a couple of web postings that recommended opening up Applications on the Mac. Then searching for JS/Redirector and moving it to the Trash folder. This didn't make a lot of sense to me that the trojan would be listed by there by name. Then search for a liked named extension in whatever browser you are using and deleting it. You should probably open up a support ticket with Eset on the issue for assistance in malware removal. Almost everyone on the forum is knowledgeable in Windows PCs but not Macs. Note that Eset is currently blocking any outbound connections from the Trojan but it does need to be permanently removed. Have you run a full system drive scan with Eset to see if it detects and removes the malware?

Also strange is all the detection hash values are different. Copy and post the first three hash values shown and I will see if I can find a match for them.

In the Windows ver. of Eset, there is an "Information" column in the Detected Threats log. This column if it exists in the Cyber Pro ver., will show what application was running when the threat was detected.

Correct. All that is happening is the scan is running an hour ahead of schedule. As far as Log Maintenance goes, it has nothing do with realtime scanning. If you have user created scheduled malware scans and those are running ahead of schedule, you might have to ensure your PC remains powered up an hour ahead of the scheduled scan time. There was an issue prior to ver. 12.1.31 where missed scans were not being run per scheduled event missed scan settings. Don't know if that has been resolved on ver. 12.1.31.

When you changed the time on the Log maintenance event, did it run immediately? Note the default missed scan option for that event is run ASAP. Appears to me, the immediate run after event time change is necessary to resync Eset to its correct time recognition behavior.

Click on the arrow symbol associated with Eset Network Troubleshooting wizard. Then unblock any alert associated with your Android SMB device. This will auto create the appropriate firewall rule/s for you. Also if you have changed Eset's default IDS settings; specifically in regards to blocking access to admin shares via SMB protocol, this also could be a factor. Finally, note that any use of the SMB protocol is a security risk: https://www.us-cert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices

My first reply your question mirrors exactly what @Marcos just replied to your exclusions question. Since it appears you are ignoring my replies, I will in the future ignore your inquiries.

I'm curious about something since you reside in Canada. Do you reside in one of the areas that do not switch to DST? I still believe this is a bug in the way Eset is determining DST. Perhaps there is something internally within Win 10 for example, where the Windows clock does not factor DST. Some algorithm is run at boot time, etc. that recalculates the DST time based on location telemetry or the like. Eset is extracting the non-DST factored internal clock for its Scheduler purposes?

The HTTP filter detections shown in the Cyber Security Pro log are detections and mitigations when a web site attempts to run a malicious JavaScript. There is nothing to remove on your device since the malware is resident in the web page you accessed. In your case, the web page attempted to redirect the browser to another URL that was known to be malicious. Eset blocked the redirection attempt. Obviously in the future, you want to avoid browsing to the source web site where the redirection was attempted. Are you stating that these HTTP filter detections are occurring other than when a browser session is active?

I will also add that since it appears you are a firewall expert, you should most certainly know what exclusions they would require. Just don't expect Eset to be the least bit "accommodating" when it comes to conflicts with an obsolete and unsupported circa 2013 firewall.

Here's a FireFox posting on the error: https://support.mozilla.org/en-US/questions/1170738 Check FireFox's root CA certificate store and ensure only one Eset root CA certificate is present. If multiple ones exist, keep the one associated with Eset 12.1.31 installation and delete the rest.

Confirmed this was a "glitch" in the Security Report. Resetting it did the trick and all incoming e-mails are correctly identified count wise in the report. Well, in-box wise they are. Appears that anything dumped into the Bulk e-mail; etc.. folders in Thunderbird are not reflected in the report counts but I am not sure those are actually physically downloaded to my device.

I believe this one of the detections Eset uses when it detects a suspicious driver. Here's a 2013 Eset posting where it was flagging Windows Defender engine related file: https://forum.eset.com/topic/990-windows-defender-false-positive/ . In this case, it was positively identified as a FP.