AVLab - "Protection test against drive-by download attacks" (April 2017)

OK I see your point. But for example MRG often uses banking trojan simulators, who simply hook the browser, just like real life malware. AV/BB's should be able to block those techniques, it's that simple.

We already had a huge discussion about this. IMO, if SmartScreen isn't able to identify malware, and only gives a warning that some app is unrecognized and might not be safe, then it should be marked as a fail.

 

Don't see why it should be a fail instead of "user dependent" like every other product/test.

 

Good point, now that I think of it, I wonder what "user dependent" means when it comes to AV testing. I would like to know what type of alerts are being presented to the user. If AV leaves the final decision to the user, then it's also a fail in my eyes.

 

https://static.emsisoft.com/images/layout/screenshots/eis/201705/en/alert_fileguard.png

Not certain of the specific technical explanation of what it is about how EMIS' behavior blocker works that results in "User Choice" for such. IIRC @Nightwalker and/or @Fabian Wosar has explained it on the Forum.

 

User must respond to an alert and make a decision. Same as SpyShelter alert. Alerts of any kind - "Do you want to allow or block ?"

100 % behavioral detection that is 100 % accurate every time is technologically not possible. It won't happen anytime soon. The best that can be done is to put code through and emulator and spit out an index (probability) number that a file is malicious, don't know, or safe. User must still make decision for the don't know files.

Until SkyNet arrives, the kind of behavioral monitoring, detection and auto-decision making that people expect just isn't possible.

 

So based on your interpretation, HIPS/BB/Anti-exe are mechanically full-failing solutions, since they warn for everything unknown or sometimes even safe...
SS isn't an AV, it is a reputation system. So if a file isn't classified yet or signed, SS may trigger an alert. nothing more , nothing less.

+1

What trigger a prompt is usually the prevention module added to the AV.

An AV is not BB/HIPS/anti-exe , it is primarily a blacklist + heuristic real-time scanner eventually linked to a cloud server for reputation check (or code analyze in the case of Ai based products).
So for an AV, if a file isn't verified (by hash) or considered (by heuristic) as malicious, it is just allowed: AV doesn't care of unknown files.

It is a fail if you're an idiot and click yes to a prompt without researching the cause, if the file was 100% verified and classified as clean, you won't get the alert.
"Unknown" files doesn't mean they are all the time clean or all the time malicious.

If the user doesn't know what he is doing by clicking yes , then it is a fail from the user, not the software (the software did its job properly, it warned the user)

However, if the software didn't prompt the user and automatically allowed the malicious file, then it is a fail from the software.
The latest example i remember was Comodo allowing a malicious file because the said file was mistakenly added as "trusted" to the cloud.

 

Not this stuff again. I already explained that if AV/BB do not automatically block malware, it should be a fail. We shouldn't talk about HIPS and anti-exe, because the first is geared to expert users that know how to respond to alerts, and the latter blocks everything no matter if it's malware or not. Same goes for a white-listing solution, it will block everything not on the list, so no wonder it will probably score a 100%, because it's not actually detecting malware.

Yes I know, but that's not the point. At the end of the day it's the job of AV's to make the decision for the user. AV testing should be about testing the ability of AV's to block apps that are known to be malware, so it's basically about blacklisting via signatures, heuristics and behavior blocking. If some AV generates a lot of false positives because BB is too aggressive, it's up to them to improve this.

Weird alert, if it thinks it's malware, why not auto block it?

 

Other than preventing FPs, and it will on rare occaisions call out an obvious FP, I dunno. I ask myself the same question - IIRC, has to do with the specific/unique way the behavior blocker works--need an @Fabian Wosar for the answer.

 

It's because of settings. The default setting notifies (fly-out toaster) and auto-quarantines malware. He must have File Guard detections set to "Alert" = the alert shown and the user must make the decision.