itman

Did you mistype that driver name? There is no Eset or Win 10 driver so named that I am aware of.

Do you have Win 10 Secure Boot enabled? If so, I would disable it and see if the PC will now boot.

Since attack methods of SamSam are similar to Matrix ransomware, here is a posting I made a while back in regards to additionally RDP mitigations that should be deployed: https://forum.eset.com/topic/17808-samsam-ransomware-targeting-multiple-industries/ . Also, here is a guide to adding additional HIPS rules to supplement Eset's anti-ransomware shield protection: https://support.eset.com/kb6119/?locale=en_US&viewlocale=en_US .

It's a new Matrix ransomware variant: https://twitter.com/demonslay335/status/1110188987690504193 Matrix ransomware attacks involved hacked RDP connections as described in this article: https://www.bleepingcomputer.com/news/security/new-matrix-ransomware-variants-installed-via-hacked-remote-desktop-services/

Thanks the for clarification!

Let's analyze this in detail. First screen shot is ThreatSense settings for Web Access protection. The important setting to note is "Advanced heuristics/DNA signatures": The next two screen shots are for Realtime protection. The important thing to note is the omission of the "Advanced heuristics/DNA signatures" protection on base ThreatSense settings: And for file creation and execution, advanced heuristics are performed for both. Of note is the absence of any reference to "DNA signatures": From the above, we can conclude that "DNA signature" usage is only used by default by Web Access protection. And that is indeed an issue. The solution to me appears to enable "Advanced heuristics/DNA signatures" scanning option for Realtime time protection. I assume that is disabled by default for system performance reasons. Also this issue doesn't just apply to FireFox Send delivered files. What about anything not Internet downloaded such as files on USB media?

I have been getting this same error occasionally in ver. 12.1.34 and I run the firewall in Automatic mode. So it is not unique to Interactive mode. Also, I have had a similar type error occur occasionally when creating HIPS rules. What I have discovered is the rule is actually created; at least on my current Eset installation. It appears to me the problem is some type of Eset GUI alert bug not effecting any actual Eset functionality.

The real question is are you vulnerable in regards to FireFox Send encrypted archives using Eset? The answer is no unless I am missing something. Once the archive is decrypted on the disk, it is still an archive. As previously noted, Eset's realtime protection covers you on any self-executing archives; e.g. .sfx, etc.. When the archive is extracted, a new folder is created with the files within. Eset's realtime protection scans all new files upon creation so those new files will be scanned. Additionally, if one or more of those new files are an executable, it will be scanned again upon execution. Bottom line, I really don't see a problem here.

If "you're following my drift" in the previous posting, it's starting to appear to me that some type of man-in-the-middle activity is occurring for your Internet connections. It is the only explaination I can think of for the Eset non-alert status when accessing the https://badssl.com/dashboard/ web site.

The situation with encrypted archive downloads is identical to that for password protected archives. With a strong algorithm used for encryption, it could take weeks to crack it. What I want to know is how Fortiguard can inspect password protected archives which it indicates it can. They must have figured out a way to bypass that feature. Finally, packed, encrypted, and obfuscated non-archive code downloads really aren't scanned until they are executed via heuristics. There is no known way to do the same with an encrypted archive file. It first has to be decrypted before the archive can be accessed. Also, determining a file's encryption status is far from straight forward: https://www.quora.com/How-can-one-tell-if-a-file-is-encrypted .

In IE11 and for the Eset forum web site, click on the lock symbol on the IE11 toolbar. Does it state Eset SSL Filter CA for Website Identification? Likewise, go https://badssl.com/dashboard/ and do the same and verify Eset SSL Filter CA is also shown. Also for both these sites, verify that the web site certificate chains to the Eset SSL Filter CA certificate: -EDIT- Additionally for both web sites, verify that the thumbprint for the Eset SSL Filter CA chained root certificate matches the thumbprint for the corresponding Eset SSL Filter CA certificate stored in the Windows Trusted Root Certification Authorities folder:

I'm logging off for the night. Will continue this tomorrow.

Why three certificate postings? There should only be one Eset certificate in the Trusted Root Certification Authorities folder. Also why is the last certificate shown with a valid from date of today? Did you reinstall Eset on the device today?

I have a theory about something. You stated that when you ran the https://badssl.com/dashboard/ test using IE11, you did not get any Eset alerts. On the device you did the testing using IE11, run certmgr.msc. Open the Trusted Root Certification Authorities folder. Open the Certificates folder. Navigate to the Eset SSL Filter CA certificate and open it. If the certificate doesn't exist, we have found the problem. If the certificate exists, does it show that it has been revoked, is expired, or untrusted? If the Eset root CA certificate exists and in a valid status and/or does not exist, this mitigation if implemented, might be factor: https://attack.mitre.org/techniques/T1130/

BTW - did you open an Eset support ticket on this? I don't know if this is solvable via forum replies.

Since you already did a Win 10 reset install and the issue still persists, do the following. At least, this will stop the Eset alerts for the time being and allow for hopefully, identifying which process is performing this activity. 1. Go to your Eset Filtered Web Sites log and search for all long entries related to amanda.run netc. Make a note of all IP addresses associated with the log entries. Hopefully, they are all the same IP Address or only a few. 2. Create an Eset firewall rule to block; i.e. "Deny", "TCP and UDP protocol", and Direction set to "Out." Name your rule something meaningful. Set Logging Severity to "Warning." Do not checkmark the Notify user option, since this will keep giving you alerts. Click on the Remote tab. Navigate to the window labeled IP. Enter each previously noted IP address. If entering multiple IP addresses, enter a comma after the end of the address, a space, and then the next IP address. Do not enter a comma after the last IP address entered. Click on the "OK" tab and every "OK" tab thereafter to save you newly created firewall rule. Once a few Eset Network log entries have been created from this firewall, copy those entries and post them into your next forum reply. Hopefully, this will point us to what process is performing this activity.

You will have to wait till @Marcos or someone else from Eset comments on this.

I also suspect your issue has something to do with the domain controller environment. What it could be I have no clue since I am not familiar with Eset's File Server or ERA; don't know what you use.

Yes. Or, the result shows "OK." Anything highlighted in red Is a failure.

Now I know what is going on with the https://badssl.com/dashboard/ test. I disabled Eset's SSl/TLS protocol scanning and passed all the tests using IE11; including the SHA-1 test I failed when SSl/TLS protocol was enabled. So Eset has a problem there. Bottom line - the only alerts you should receive from this test are Eset alerts. This test was set up primarily to test that AV's that perform SSL/TLS protocol scanning, do it correctly.

Browser alerts when the baddssl.com test was running. You already stated you didn't receive any eset alerts.

That is very strange indeed. Especially since Eset's root CA certificate is installed in Chrome's corresponding root CA store. Obviously, something blocked the connections since you passed all the tests; i.e. "cannot connect." Did you get any other alerts from the browser's themselves about an untrusted certificate when the test was running?

Did Eset certificate alert display for each test?

Passed all the tests except for SHA-1 Intermediate of which IE11 shows a few including Microsoft's. What about a Comodo code signing cert? Should I get rid of that one?

Some more info on FireFox send: https://blog.malwarebytes.com/cybercrime/privacy/2019/03/mozilla-launches-firefox-send-for-private-file-sharing/ In other words, this is the same as sending/receiving encrypted e-mail via e-mail client. Eset SSL/TLS protocol scanning can't scan the encrypted FireFox send files because it has no access to the public key used to unencrypt the files.