Virus Bulletin
Copyright © Virus Bulletin 2017
With a few notable exceptions (such as the infamous WannaCry [1] 'ransomworm' spread via SMB), users get infected with malware either via malicious emails or via malicious websites, both of which delivery methods come with their own advantages for the attacker: malicious emails work well against a fully patched system, but if a browser or its plug-ins are vulnerable, malicious websites have the advantage of not requiring any user interaction.
In recent months, many security researchers have noted a decrease in the use of malicious websites as a malware delivery system, attackers instead tending to favour email – a trend we have also observed in our lab at Virus Bulletin. However, such trends are rarely, if ever, permanent, and they do not mean the web has all of a sudden become safe. There are still exploits out there (RIG in particular remains very active), and 'unprotected' browsing remains as bad an idea as ever.
We thus continue to recommend patching operating systems, browsers and plug-ins as the first and most important step in fending off web-based malware. But, as this test shows, web security products are an important second layer of protection that, in a world where things are never perfect, can make a huge difference.
During March and April 2017, a number of web security products were run in Virus Bulletin's test lab and exposed to various real-time, web-based threats, including exploit kits and direct malware downloads. While some vendors elected to be tested privately (with the results for these products not being made public), this report features those that submitted to the public test. (For obvious reasons, once a test has started, participants may not switch from 'public' to 'private' testing or vice versa.)
As on previous occasions, there were two vendors that opted to enter their products publicly, and once again their decision proved to be justified. Both Fortinet's FortiGate appliance and Trustwave's Secure Web Gateway (SWG) product blocked all the live exploit kits they were exposed to, as well as all but a handful of direct malware downloads. (It should be noted that the latter threat is less of an issue in both qualitative and quantitative terms – since the malware is stored on the local disk before being opened, there is a better chance of an endpoint security product blocking the threat – hence such cases are given a lower weight in the test.) While we will not comment publicly on the individual performances of those products that opted to be tested privately, we note that not all of them managed to block all the live exploit kits they were exposed to, thus underlining the fact that a 100% block rate was no trivial achievement for the two products in the public test.
Products were also exposed to a number of malicious URLs that ended up not delivering a payload – a not uncommon occurrence in the complicated world of web-based malware. Of course, it is not essential for products to block these failed infection attempts, and not doing so is not taken as a sign that the product wouldn't have blocked the attempts in the real world. However, blocking them indicates a good level of proactive detection, which is an interesting data point for those trying to understand the way web-based threats are fought.
Both FortiGate and Trustwave SWG blocked the overwhelming majority of such failed attempts, and there is reason to believe that they would have blocked the remaining cases had they resulted in actual malicious traffic.
On top of this, neither product mistakenly alerted on any of the legitimate sites we exposed them to. Both products thus earn the VBWeb certification and we are happy to recommend either of them to organizations looking to mitigate web-based threats.
The disappearance of prominent exploit kits such as Angler, Nuclear and (at least temporarily) Sundown has made RIG the most prominent exploit kit by far. All the exploit kit cases in our test were RIG; they used the EITest and PseudoDarkleech campaigns and the Seamless, GoodMan and HookAds gates. We recorded a few failed cases of the Terror exploit kit in the category of potentially malicious cases.
Matrix ransomware infection.
Web-based threats continue to spread ransomware: we noticed various exploit kits dropping ransomware such as Cerber, Matrix and Ransomlocker, as well as the downloader Smoke Loader, which in turn would have downloaded other malware.
Cerber ransomware infection.
The direct malware downloads included dozens of different malware families such as Ramnit, Sality and Bladabindi, as well as several downloaders, which in turn would have downloaded other kinds of malware.
RIG EK followed by Smoke Loader traffic.
Drive-by download rate: 100.0%
Malware block rate: 97.8%
Weighted average: 99.8%
Potentially malicious rate: 98.6%
False positives: 0.0%
With three VBWeb awards already under its belt, Fortinet's FortiGate appliance seems, so far, to have had little problem in keeping apace with the changes in the threat landscape.
Indeed, this month the FortiGate appliance once again blocked all infection attempts through drive-by downloads, resulting in a 100% catch rate. It also blocked all but six direct malware downloads – and proactively it blocked more than 98% of potentially malicious cases.
Of course, this means Fortinet is well deserving of its fourth VBWeb award.
Drive-by download rate: 100.0%
Malware block rate: 97.8%
Weighted average: 99.8%
Potentially malicious rate: 96.4%
False positives: 0.0%
Trustwave's Secure Web Gateway virtual appliance has only appeared twice before in our public tests, but has put in exceptional performances and earned VBWeb awards on both occasions.
On this occasion, SWG once again blocked all infection attempts via exploit kits. What's more, it also blocked all but six direct malware downloads – and proactively it blocked more than 96% of potentially malicious cases.
Trustwave is therefore once again a worthy winner of a VBWeb award.
The test ran from 27 March to 10 April 2017, during which period we gathered a large number of URLs (most of which were found through public sources) which we had reason to believe could serve a malicious response. We opened the URLs in one of our test browsers, selected at random.
When our systems deemed the response sufficiently likely to fit one of various definitions of 'malicious', we made the same request in the same browser a number of times, each with one of the participating products in front of it. The traffic to the filters was replayed from our cache within seconds of the original request having been made, thus making it a fully real-time test.
We did not need to know at this point whether the response was actually malicious, thus our test didn't depend on malicious sites that were already known to the security community. During a review of the corpus some days later, we analysed the responses and discarded cases for which the traffic was not deemed malicious.
In this test, we checked products against 116 drive-by downloads (exploit kits) and 270 direct malware downloads. To qualify for a VBWeb award, the weighted average catch rate of these two categories, with weights of 90% and 10% respectively, needed to be at least 70%.
We also checked the products against 244 URLs that we deemed 'potentially malicious'. These were URLs for which we had strong evidence that they would serve a malicious response in some cases, but they didn't when we requested it. There could be a number of reasons for this, from server-side randomness to our test lab being detected by anti-analysis tools.
While one can have a perfectly good web security product that doesn't block any of these, we believe that blocking such URLs can serve as an indication of a product's ability to block threats proactively without inspecting the traffic. For some customers this could be important, and for developers this is certainly valuable information, hence we decided to include it in this and future reports.
The test focused on unencrypted HTTP traffic. It did not look at extremely targeted attacks or possible vulnerabilities in the products themselves.
Each request was made from a randomly selected virtual machine using one of the available browsers. The machines ran either Windows XP Service Pack 3 Home Edition 2002 or Windows 7 Service Pack 1 Ultimate 2009, and all ran slightly out-of-date browsers and browser plug-ins.
We found that, in practice, we were far more likely to be given a malicious response for the Windows 7 machine using Internet Explorer; hence most cases that ended up in the test used this configuration. Of course that does not mean that Windows XP is more secure – on the contrary, it has not received regular security updates since April 2014 – rather that exploit kit authors consider infecting the more modern operating systems to be of greater value.
[1] https://www.virusbulletin.com/blog/2017/may/modern-security-software-not-powerless-against-threats-wannacry/.
