Testing anti-virus using web threats

At Dennis Technology Labs we test anti-malware software a lot.

In fact, earlier this year we started the process of constant testing, which involves exposing some of the world's most popular anti-malware software to some of the most prevalent threats.

Testing anti-malware software is not a new thing either for us or for the industry, but methods have evolved over time. Since we started testing web threats around five years ago we have stuck to the same self-imposed rules.

Some people assume that we do the same as other testers, but that is not the case. Each testing organisation has its own approach and this is ours.

We do not take sample feeds from vendors.

In other words, we don't collect viruses, Trojans and infected files from anti-malware companies in order to test anti-malware products. The reason is somewhat obvious!

We do not (usually) download executables directly

Some testers will introduce threats to target systems using URLs like these:

http://www.example.com/dir/nasty.exe

http://www.nothereg.cc/annoying.exe

http://bad.tld/evil.scr

We do not, as in most cases this is an unrealistic test that does not permit the security products to use their full range of mechanisms to prevent an infection.

We almost exclusively use URLs containing exploits

Instead of downloading malware directly we expose targets to the full 'experience' of the threat. This usually means either visiting a webpage that contains exploit code, or loading a page that contains an iframe, which in turn directs the browser to exploit code.

However the threat works, the end result is usually a drive-by attack that requires no interaction from the user to succeed.

We may include social-engineering attacks

Sometimes we will encounter a threat that attempts to trick the victim into downloading and running a malicious file.

In such cases the entire scam has to be available, not just the payload.

In other words, we would use something like http://www.example.com/fakeyoutube.html, which might pop up a message saying, “To watch this video you must download a Codec” and then offer a download. We would download and run the file.

We would not just hard-link to the download.

Our samples are complex

The sample files that we generate are not single files like bad.exe.

They are re-playable HTTP sessions that contain all of the network transactions involved in the attack. This usually includes iframe redirections, exploit code, downloaded binaries and other commands. This means that, bar the odd anomaly, security vendors can replicate our tests quite easily.