Comparing Anti-Virus Solutions

Published: 2007-03-05
Last Updated: 2007-03-06 21:45:46 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Every so often we get requests from readers asking us about comparisons between the different anti-virus products. These requests range from recommendations on how to compare oneself over to ready made comparison reports.


Typically we tend to use virustotal output in a lot of the diaries we write as it gives a good overview where a given malware is detected and how the different vendors named it. E.g:

Antivirus Version Update Result
AntiVir 20070305 TR/Dldr.Small.ego.55
Authentium 4.93.8 20070305 -
Avast 4.7.936.0 20070305 -
AVG 20070305 Downloader.Generic3.VCI
BitDefender 7.2 20070305 Dropped:Trojan.Rootkit.AN
CAT-QuickHeal 9.00 20070305 -
ClamAV devel-20060426 20070305 -
DrWeb 4.33 20070305 -
eSafe 20070305 Win32.Small.ego
eTrust-Vet 30.6.3455 20070305 -
Ewido 4.0 20070305 Downloader.Small.ego
F-Prot 20070304 -
F-Secure 6.70.13030.0 20070305 Trojan-Downloader.Win32.Small.ego
FileAdvisor 1 20070306 -
Fortinet 20070305 W32/Small.EGO!tr.dldr
Ikarus T3.1.1.3 20070305 Trojan-Downloader.Win32.Small.ego
Kaspersky 20070305 Trojan-Downloader.Win32.Small.ego
McAfee 4976 20070305 -
Microsoft 1.2204 20070305 -
NOD32v2 2097 20070305 Win32/Wigon.K
Norman 5.80.02 20070305 W32/DLoader.CDZC
Panda 20070305 -
PandaBeta 20070305 -
Prevx1 V2 20070306 -
SAVMail 1.0 20070302 -
Sophos 4.15.0 20070305 Troj/Agent-ECZ
Sunbelt 2.2.907.0 20070305 -
Symantec 10 20070306 -
TheHacker 20070305 -
UNA 1.83 20070305 TrojanDownloader.Win32.Small.C329
VBA32 3.11.2 20070305 Trojan-Downloader.Win32.Small.ego
VirusBuster 4.3.19:9 20070305 -

Name ccc.exe
Size 23040
md5 46241d432831fec22fd38c135ab96523
sha1 9d3dbf5c11779b4aceed2b2b2ff3735e9c483997
Date scanned 03/06/2007 00:52:27 (CET)

Obviously some vendors are absent from these results.

Virustotal keeps some limited statistics online, but they're not useful in comparing products.

Build your own

Now if you collect enough of these you might build your own statistics on which product detects things you encounter better than the competition. It's not easy to collect enough of them to get a statistically significant sample, so running 2 or more of your favorite scanners in-house might be easier to get more significant results -but more limited in scope-.

Getting enough malware to scan could be done using proxy logs, stripped email attachments etc. Do take care with local privacy rules/laws before doing this!

3rd Party Reports

There are some reports available about 3rd party testing of anti-virus products.

  • updated every so often, includes a rating system.
  • article, more than a year old.
  • runs out of a German University, not updated recently
  • last updated in August 2006
  • Consumer Reports has a comparison of 12 anti-virus products (subscribers only), it did get heavy negative feedback from the anti-virus vendors who seem not to like being put to the test.
  • Virus bulletin has a report online for registered users and is referenced by many of our readers.
  • Some more comparisons can be found at and


What's important to evaluate anti-virus products on? A test with a well known fake virus to see if it is detected (eicar), just will not expose the strengths and weaknesses of the different products and allow us to make a choice. Depending on the specific situation, we can be interested in:

  • Few false positives: detecting known good software as malicious and crippling systems as a result has happened before, the impact of recovering from this should not be underestimated. While looking forward is hard, the hindsight view might tell it's own tale
  • Few false negatives: not detecting malware is a bad thing, but it does happen by default in a technology that is basically reactive and where those creating the malware actually test their contraptions against the anti-virus products to make sure they are not detected at the time they release them.
  • Timely signature updates: signature updates is the main vector anti-virus software uses to fix the above problems. The faster they are released the more protection you get as a customer.
  • In corporate settings we want excellent centralized management. This should at least include a report that points us to individual machines not updating their definitions at all or in a timely manner. Ideally it does this without blocking signature updates when the roaming laptops are not connected to the corporate network or a VPN back to the office.
  • Few vulnerabilities: Vulnerabilities in our security solutions are somewhat of a nightmare as they not only fail in their goal of making us more secure but also introduce more security problems.
  • We do want variety if possible so that we use different engines in the different roles by e.g. using a different vendor on our email infrastructure and the desktops. The same goes for desktops and file servers.
  • Ease of use.
  • Price
  • ...

With thanks to epablo, Vincent,  Bryan, William, and many others for contributing to this diary

Swa Frantzen -- NET2S


0 comment(s)

Security update for QuickTime (7.1.5)

Published: 2007-03-05
Last Updated: 2007-03-06 08:02:45 UTC
by Bojan Zdrnja (Version: 3)
0 comment(s)
Apple released a new version of QuickTime (7.1.5) which contains numerous bug fixes and a lot of important security patches. This article ( lists the security content of this release – you can see that it fixes 8 security vulnerabilities, all of which just require a user to click on a specially crafted file.

If you use QuickTime I would definitely recommend that you install the update as soon as possible as some of those security vulnerabilities look nasty.

Mac users can obtain it via the standard Software Update (Apple->Software Update..., reboot required) or, if you wish to install separately, you can find the Mac version at, while the Windows version can be downloaded from


We received couple of e-mails from people telling us that the built-in (auto) updater in older versions of QuickTime (still) doesn't find this new release. In other words, if you click on the "Update now" button, it will tell you that you have the latest version running.
So, at this point in time, if you want to run the latest (patched) version, you'll have to go there and download the installation file and install it manually.
0 comment(s)

phpMyFAQ being exploited

Published: 2007-03-05
Last Updated: 2007-03-05 22:11:14 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
A vulnerability in phpMyFAQ, which is an open source FAQ system for PHP and various databases, has been published back in February (
Jeremy notified us that this is being exploited in the wild. The vulnerability allows an attacker to upload arbitrary files on the server. As you can probably guess, currently attackers first upload a php shell, after which the machine is typically turned into a spam spitting server.

If you are using phpMyFAQ, be sure to install the updates available on their web site (
0 comment(s)

JavaScript traps for analysts

Published: 2007-03-05
Last Updated: 2007-03-05 21:59:59 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)
On Friday, Lorna posted a diary ( about some malware we received that day. A compromised site hosted an obfuscated JavaScript program – a typical scenario you might say.
Over the weekend I received couple of e-mails from our readers asking how to deobfuscate that JavaScript so I spent more time analyzing it and I found some very interesting details and traps that are almost directly related to the nice diary Daniel posted couple of weeks ago (

If you haven’t read Daniel’s diary I recommend you definitely do so. Daniel showed 4 typical methods that you can use when analyzing obfuscated JavaScript programs. As you will see, of those 4 methods, 3 will fail on this example!

The JavaScript file that we will analyze is nicely obfuscated, as you can see below:

Malicious JavaScript program

As most of similar obfuscation attempts, first a function is defined, called OAEC86 (as you will see, absolutely all variables have similar names which makes them more difficult to read for a human). At the end, that function is called with a big string as the input parameter (the obfuscated content).

Replacing document.write() with alert()

So, we have to analyze what the OAEC86 function does. As you can see on the screenshot above, the function ends with a call to document.write() which causes your browser to execute the (deobfuscated) code. If you try to approach this with method 1 from Daniel’s diary (replace document.write() calls with alert()), and start the JavaScript program, your browser will appear to hang and you will have to kill it with Task Manager. We will see later why did that happen, but let’s analyze the function itself first.

As the code has been stripped down of spaces, it’s difficult to analyze so I added some spaces and tabs to make it more human readable. There is one interesting variable that gets declared immediately at the beginning of the function:

var A112FA=arguments.callee.toString().replace(/\W/g,"").toUpperCase();

When I saw this I immediately remembered another diary I wrote some time ago (, when I analyzed a similar thing, but this one goes a bit further.
So, the variable above gets its content from the arguments.callee.toString() call. This function returns back a text string which contains the whole called function, from the first line to the last one. A thing I found before was that there was a big difference between Internet Explorer and Mozilla in handling of white space, however, as you can see in the example above, that doesn’t matter as all non-word characters are stripped out with the replace() call (\W) and then converted to upper case. It's nice to see how attackers fixed this so it works correctly (from their point of view) in both IE and Mozilla.
So, after executing this call, the variable A112FA will contain the following string: “FUNCTION0AEC86T1F0AVARA112FA…”. You can see the beginning part of the code here.

As you can probably guess at this point in time, the function actually uses itself to deobfuscate the content. This way the author made sure that you can not change the function. However, this still doesn’t explain why the browser hangs when you change the the document.write() call to alert(). The answer lies further down.

Without analyzing every line of the code (that’s left as an exercise for you, if you are interested in this area), I’ll just explain why the browser hangs.
The big for loop in the code performs various permutations which deobfuscate the code. There is a while() loop in the code as well, which loops until the Q3A988 variable is different from zero. Now, when you change the document.write() call to alert() it will also cause this while() loop to keep looping (as Q3A988 will never have zero) which will in turn cause your browser to hang.
So the first method from the original diary is a no go here. Lets try with the second method.

Beware of </textarea>

Now, as the first method failed, you might want to try Tom Liston’s <textarea> method. First of all, I hope that you are aware that whenever you run code like this that you should do it in an isolated environment because you are running live, potentially malicious code. This is even more important in this case.

I’ll skip right to the point – when this program is deobfuscated, the result will be this:

</textarea><iframe src="http://[REMOVED]" width=1 height=1 style="border: 0px"></iframe>

What does this do? It closes the <textarea> tag that you might have put before. In other words, if you were running this in your browser and you used method 2) you would actually execute the malicious code! It is obvious that author of this code came prepared for analysts!

Next to method 3). In this case, method 3) isn’t really applicable as the deobfuscation code is way too complex to be rewritten in perl (if you really do it let me know).
So what are we left with? Method 4, or (my favourite), a debugger.

Defeating the obfuscation

One relatively easy way to deobfuscate this is to use SpiderMonkey, which is Mozilla’s JavaScript engine released as a standalone. It will not work just out of the box, though, as the JavaScript engine will not know what to do with document.write(), but folks at Websense wrote two nice JavaScript programs that you can use so you don’t have to replace any document.write() calls. Their method is explained at, it’s a nice read that I definitely recommend.

I personally prefer to look at things with a debugger, though, so I’ll explain how to do this with Rhino. Rhino is Mozilla’s JavaScript debugger. It has a nice GUI and is written in Java, so it will work on any platform. You just must make sure that you have JRE installed.
A lot of users have problems starting it – you have to make sure that your Java classpath will be set to js.jar file that comes with Rhino, otherwise Java will not know how to find the class it needs. In the example below, I’ve extracted Rhino in the D:\Rhino directory and the malicious JavaScript file (with all HTML tags stripped out) is in d:\malware.js. Rhino should be started with the following command:

D:> java –classpath D:\Rhino\js.jar D:\malware.js

This will open a nice GUI window that is pretty much self explanatory. It is advised that you make the code human readable before this as that will allow you to set breakpoints easier – and as we’ve seen, in this case you can do it as the deobfuscation function will strip out white spaces.
You can now either step through the program, debug it and see how it works, or simply set a break point on the document.write() call and then inspect the I4D790 variable, as shown below:

Rhino JavaScript Debugger

You can see that it contains the code that would have been executed in the browser.

As we saw, malware authors are definitely improving their work and are, almost certainly, aware of methods that analysts use. In this case, the </textarea> tag was directed against analysts, as it made no other sense in the rest of the code. Luckily, whatever has to run on your machine can be analyzed, but it will probably not be as easy to do that as it was in the past, as malware continues to evolve.


Couple of updates with good stuff we've received from our readers:

1) Peter wrote to correct me regarding the Tom Liston's textarea method. This method actually also modifies the function (by adding <textarea> and </textarea> tags before and after the document.write() function call) so it will also fail because of the endless while() loop. This is not directly related to thing that they close the <textarea> tag, but see 2).

2) Aaron sent us a nice function he uses to deobfuscate stuff. Basically, he replaces the document.write() call with a function he defines, called documentwrite. The function looks like this:

function documentwrite(txt){
    if(txt == txt0){
        document.write("<textarea rows=50 cols=50>");

So he makes sure that the output will go in a textarea, even if there are nested </textarea> flags. In this case this might even work since the . from document.write() is removed anyway, so this will pass the self checking test this malware implements.

3) An anonymous reader wrote to tell that there might be some dependencies/problems with running Rhino on Linux, due to its Java implementation. Also, on Linux, the classpath parameter is called with "--classpath".

Thanks to all for your contributions.

0 comment(s)
Diary Archives