Marcos

A Process Monitor log from the time when a high CPU usage is observed might shed more light. Please provide me with both a Process Monitor log as well as logs from ELC. See my signature for links to the appropriate KBs with instructions.

You can change the cleaning mode from standard to No cleaning in the real-time protection setup so that you will be always asked for an action when a threat is detected.

The operation reads "Delete from registry" so it might be ok. Not sure if it will be possible to confine asking for an action only for write attempts to that registry key in Smart HIPS mode, we'll see.

Ok, so I take it that there's no ESET root certificate on the Authorities tab with SSL/TLS filtering disabled but when you re-enable it the root certificate is added automatically. Is that correct?

You can create a firewall pcapng log for further analysis as follows: 1, In the advanced setup -> Tools -> Diagnostics enable advanced personal firewall logging. 2, Restart the computer. 3. After you've received a notification about a duplicate IP address, stop logging. 4, Compress the log and attach it to a personal message for me. Also it may be useful to provide me with the output from ESET Log Collector from that machine (see my signature for instructions).

We tested RanSim and it didn't encrypt users' data. Otherwise it'd not be a simulator but actual trojan that would be detected by ESET. RanSim does not tell how well a particular AV would protect you from file encryption by Filecoder ransomware. I recommend reading Itman's post https://forum.eset.com/topic/10792-ransomware-simulators-a-detailed-analysis/.

What is the hardware spec. of the computers? An on-demand scan can utilize 100% of one CPU core so it should not affect performance on multi-core CPU systems much unless the problem is with slower reading of data from standard (non-SSD) disks. Wouldn't it be better to schedule the scan at the time when the computers are not being used by users?

This FP was discussed here: https://forum.eset.com/topic/10796-eset-blocking-facebook-javascript-from-major-australian-website/. To prevent duplicate topics on the subject, we'll draw this one to a close.

Try the following: 1, Disable SSL/TLS filtering. 2, Restart the computer. 3, Launch Firefox. 4, Check Firefox' Trusted root CA certificate store and make sure there is no ESET root certificate installed. 5, Close Firefox (make sure it's not among running processes). 6, Re-enable SSL/TLS filtering. If you go to https://www.youtube.com for instance, does it open fine or you get SSL_ERROR_BAD_MAC_ALERT error?

I've disabled the Windows firewall service but EPFW continued to work as supposed. I've tried creating a basic firewall rule for http communication and it worked.

In the policy editor you can find IDS exceptions here:

The epfwlwf filter is not used any more on Windows 8 and newer if I remember correctly. Instead we utilize WFP via epfwwfp.sys driver.

Do you have a legitimate application that scans remote ports on computers in LAN? You can set IDS exceptions under Settings -> Personal firewall -> Advanced -> IDS exceptions.

Note that in case the site becomes actually infected, ESET won't block it. The owner of the website should rather replace the obfuscated code with an image containing the contact email address.

This was already replied in https://forum.eset.com/topic/10796-eset-blocking-facebook-javascript-from-major-australian-website/. We'll draw this topic to a close to prevent duplicate topics on the same subject.

Are you able to reproduce it when running a Smart scan?

The block has nothing to do with firewall; it's web access protection that is blocking it. It's a highly suspicious javascript obfuscation used on the website which triggers the detection. I'd like to bring this article about using obfuscation to your attention: http://www.welivesecurity.com/2011/05/17/obfuscated-javascript-oh-what-a-tangled-web/.

I don't get any block when opening the website. You can submit it for a review as per the instructions at http://support.eset.com/kb141/ and include a screen shot of the alert that you're getting (with the IP address unhidden).

It was a false positive triggered by a suspicious javascript. As you have already found out, it's already fixed. This FP was also discussed at https://forum.eset.com/topic/10796-eset-blocking-facebook-javascript-from-major-australian-website/. To prevent duplicate topics on the same subject, we'll draw this one to a close.

Ask the owner of the website to replace the obfuscated script for displaying an email address with an image containing the address. The suspicious script commences with "var s="=b!isfg>#nbjmup;xfcnbtufsAs.qspkfdu/psh#?xfc!qbhf!dpoubdu=0b?";"

Please elaborate more on the issue you are having. Are you unable to open any website? Or only https websites? If the latter, are you getting some kind of error message in the browser? Is the problem occurring only with a specific browser or with any?

If it's not innocuous that you're saying it's not a simulator but actual malware that encrypts files without user's consent. Nope, RanSim does not use the same techniques as most of ransowmare does. If it would, AVs that pass the tests would 100% protect users from encryption but that's not the case in the real-world scenario. Quite the contrary, despite failing these tests ESET provides excellent protection when it comes to Filecoders and file encryption. Also malware writers can use RanSim to find out what techniques of encryption to avoid in order to get around those AVs behavioral detections. It may give you a false sense of security that using a software that passed the test will 100% protect you from malicious file encryption. Don't blindly trust some fancy graphs without knowing what is behind and how things differ in real world.

I don't see any obvious error in the log. Was the log generated by Live Installer and installation of v10 did not continue because of the error?

This is just a simulator of a specific behavior. It doesn't tell how well a particular AV protects from ransomware. That said, AV that fails the "tests" may protect you way better from ransomware file encryption than most of AVs that pass them. We don't detect innocuous applications as part of the detection process is also checking its code in memory for resemblance with actual malware to prevent FPs and this application (simulator) is indeed innocuous. By the way, I reckon that in order to pass the tests it should be enough to create a HIPS rule that would ask for an action if a write operation on "my documents" folder is attempted. As long as you use the latest version (ie. Endpoint v6 in business environment) and have all features enabled, the chance of getting files encrypted by malware should be pretty low. I don't tell none because there's no security solution in the world that would provide 100% protection from all threats without excessive number of false positives.

Please elaborate more on the issue you're having. Had you had both v9 and Comodo fw installed in tandem without issues and after upgrading to v10 ekrn didn't start any more? If so, what happens if you temporarily uninstall Comodo fw and install v10 from scratch?