The focus needs to shift from just the 'mark of the web' to the actual behavioral triggers I described. Those are the conditions that must be met.
I don't disagree with you, but AMSTO is never going to adopt those conditions due to complexity and expense of effort required. As far as Youtube testers, they're never going to do it. Oh, it's easy enough to write a script, Office macro, short-cut file, etc to perform a download or spawn child processes - but only a few such testers are capable or willing to do it.
For the Emsisoft Behavior Blocker most of that will not matter, which is part of the point. It is a HIPS style behavior blocker that monitors for certain generic actions. In my own testing, if Emsisoft does not prevent the download or block the first stage file, in a significant % of instances the behavior blocker will fail to stop malware from infecting a system even when the user responds to the manual BB alert with "Block Always" or "Block Once."
In some respects, the Emsisoft Behavior Blocker is a lot like the old SpyShelter HIPS. While it was rare for SpyShelter HIPS to stop a malware infection when the user chose "Terminate (the process)" (the correct choice in all cases), it did not prevent many infections when the user selected "Block (the process action)." Even when selecting "Block Always," which is the equivalent of the "Terminate" within old SpyShelter, the Emsisoft BB often failed. The Emsisoft BB is not at the same level as Kaspersky's System Watcher (behavioral monitoring system).
I get the point of testing using download cradles and other means of delivery, but 85% or so of malware is still delivered as a fully-contained executable via user download, drive-by download, or email attachment within a .zip archive - now that is both consumer and enterprise combined. Contained within that 85% is infected USB flash drive delivered malware.
Most threat actors perform simple "Spray and Pray" campaigns of .exe files. They don't take the time or make the effort to craft themselves or purchase more sophisticated attack methods. Malicious PDF and Office Macro campaigns have dropped-off significantly within the past decade because of the preventions and countermeasures added by Adobe and Microsoft to prevent those attack methods from working by default.
So while none of that invalidates or undermines your advocacy of full-chain testing, execution from the desktop remains a fully legitimate test methodology. Testers, test labs, and software publishers are going to do what is lowest cost in terms of time, effort, and expense. Human nature.
It would be nice if AV labs would do the type of testing that you advocate for, but it is so time consuming and expensive to do so, that only a couple do it and only then rarely because the publishers don't want to pay for the testing costs. Heck, AV publishers themselves don't do that kind of testing. Some do if they are fortunate enough to locate "live in-the-wild" samples, but they will not go through the trouble of creating entire sophisticated exploit and infection vector chains for testing purposes. The vast majority are going to use static and dynamic analysis, with a heavy reliance upon sandbox analysis.
When AV test labs or publishers do make the effort, then the criticism becomes "Well that is a simulation and not a real-world in-the-wild kill chain." So even when they try, there are critics that immediately bash the effort.
The "issue" with Emsisoft raised in this thread is that it did not stop one (1) infection. Immediately the Emsisoft bashing began without any analysis or confirmation of the malware type tested. Malware evolves. New malware is developed. Behavior blockers only improve if someone reports the issues to the software publisher - which is main point regardless of the test methodology utilized.
avlab.pl
