0xDEADBEEF

This issue has now also surfaced on my laptop (yesterday was desktop). was a bit surprised that no other people have encountered this in beta phase.

yes, EICAR also result in the same behavior. Seems it is not dependent on the threat type, because now that the camera protection popup will also bring up the main GUI window Another observation is that when I close the main window, the egui.exe will stay in the process list for some while. During this time if another popup is triggered, the main window will not be brought up. It happens only when egui is not in the process list.

attached is the zip containing the GIF recording demo.zip

Seems there is a bug with 12.1.31 GUI. Sometimes when the main GUI is not opened (egui.exe not in the process list), and when a threat is detected, the main GUI window will popup along with the notification on the bottom right corner.. I don't think this is expected. Please let me know what needs to be logged because the issue can be reproduced.

After updating to 12.1.31, the performance issue gets largely resolved. The sample that originally takes 15 sec to delete now only needs 3~4 sec in the latest version. Anyway I've messaged u the new log on 12.1.31

seems the performance issue is largely resolved in the latest version that is just released today. The deletion latency has dropped from 15 sec to 3~4 sec.

did you observe the same thing on your side? The samples, upon being detected, will show in explorer as 0kb and takes a long time before being deleted and the notification.

I have sent u a message containing the log It takes more than 15sec to delete this sample and when the logging is enabled it takes several minutes

I think this doesn't happen until recently... Generally when the ESET scan engine detects a malware, it is taking unusually long time to delete that specific malware sample and show notification popups (I think it is definitely more than 40s to process one sample with very high cpu utilization on a high-end CPU). The EIS version is 12.0.31.0. Any changes under the hood that leads to such behavior?

SHA256: 1f15a3e297b9017c40276ad1c32d606c8beebbf432227b47360f3674bfb60127 already 30/70 detected in VT but still pass through all defense layers by ESET

My personal view on these discussions is that the two products are not comparable with such drastic difference in false positive rate. It is much easier to achieve a "100%" rate in such test if you are willing to sacrifice the detection accuracy (i.e. mark benign files as malicious) by tuning your detection knob of the model to be a bit more aggressive. ESET can definitely do this, but ESET chose not to do such thing for a good reason (there are more reasons but those are beyond the scope of this post) : in reality users are more likely to be bugged by FPs instead of real threats if the detection threshold is too aggressive. When users are getting used to dealing with FPs of a security product, they are more likely to blame and turn off the AV to use unknown riskwares next time. This generally makes a security product useless. Therefore, controlling the FP is of great great significance. And honestly speaking, even some products have very nice looking FP scores in this test, in reality they do noticeably worse than ESET. For many products which perform flawlessly in AVC's FP test (like those 0 FP ones), I can easily find FP PE files distributed by large IT companies with valid digital signature every month or two (yes, they still make such mistakes even with the help of very mature reputation cloud), but it is really hard to find such FP cases in ESET products. FP is much harder to be measured by a standardized test like AVC because there are grey zones. Plus the realworld situation of white files are far more complex than the training set in the lab. Only extensive real-life use experiences of these products will tell.

No, the user doesn't seem to have such configuration. I think this issue needs some troubleshoot tools from ESET to find out what flipped that switch automatically

A friend of mine experienced the issue that the LiveGrid feedback system will automatically be turned off some time after turning it on in EIS 12.0.31.0. OS: Windows 10 Pro x64 17134 Is there a way do diagnose this issue? Reinstalling EIS doesn't help.

It works after resetting ESET Management Agent settings. I think it was indeed due to the pre-release repository setting. Thanks!

ah, that's a good point. I will try tonight and see if it helps.

The issue does repeat. I can't get any of the machine update to 2091 due to such issue except for one laptop. Please let me know if any info is needed.

When I tried to push EES 7.0.2091 update through the cloud administrator, the task failed saying cannot find the package in the repository. Has ESET withdrawn this update? The package list's update log corresponding to 2091 points to the update log of 2073.0

Yes, as I said, HIPS is the foundation of Ransomware Shield. In general, you can view the ransomware shield as HIPS + a complex rule set made by ESET that is not visible to end users. And that's why it is a behavioral-based defense layer.

In most cases it should be ok. But as the forum rules said: https://forum.eset.com/topic/76-rules-of-the-eset-security-forum/ I just don't want to touch any topics that fall inside the grey zone

I think Marcos was referring solely to the HIPS module (by default the auto mode indeed doesn't block most behaviors, but it is serving as a foundation for other protection layers like memory scanner and ransomware shield). Ransomware shield is different. It is a behavior-based defense layer. It is more complicated than writing custom rules in the HIPS rule table because so far there is no simple rule in the world that can block ransomware with the guarantee of low FPs. I can say this for sure because I've tested the ransomware shield using my own code.

Kaspersky indeed has some decent behavioral defense mechanisms, but it is not without its issues. I tend not to compare products in this forum so I will stop here ? Generally there are always trade offs

yes it is a behavior monitoring component (potentially combined with cloud reputation and other methods). The thing to keep in mind is that it is hard to distinguish malicious file modification behaviors versus legitimate ones. So to balance the detection rate and false positives, there will be weaknesses of such protection layer. And that's why multi-layer protection is important.

Yes I have the habit of zipping the sample sand name it using the sha1 hash before submission. I have observed this for months(I was using Chrome), and I think it is a bug. Previously opera has this issue with vpn on, then this issue propagate to chrome and potentially more browsers. If you use the built in vpn in opera, you will find the quarantined sample downloaded through opera can’t even be restored to its original place btw, nearly all FPs I’ve encountered in ESET product is such Generik detection, which makes sense

Is this sample indeed malicious/PUA? Though I didn't do careful analysis on this sample, judging from the source and digital sig it is likely to be benign with not-so-few users (according to LiveGrid). It is a bit unusual to see ESET holding a potential FP for such long time.

Nope, and I also tested two other browsers (Chrome and Opera, also tested the incognito mode), both have the same issue.