Deep inside one of Stuxnet’s configuration blocks, a certain 8 bytes variable holds a number which, if read as a date, points to June 24th, 2012. This is actually the date when Stuxnet’s LNK replication sub-routines stop working and the worm stops infecting USB memory sticks.

Kaspersky Lab chief technology officer Nikolay Grebennikov joins Ryan Naraine to discuss the evolution of anti-malware software. Grebennikov talks about the changing face of the malicious threat facing desktop users and the additional components added to Kaspersky's anti-malware products to move beyond signature-based detection of threats. He goes into detail about heuristics and emulation, behavior-based detection and newer proactive technologies to handle real-time malware detection.

Apple has released MacOS X 10.6.7 with several bugfixes and security-patches. This patch bundle also includes a silent update to Apple‘s built-in Xprotect anti-virus functionality.

Xprotect
With the release of Snow Leopard (Mac OS X 10.6) Apple introduced a basic antivirus protection called „XProtect“. It scans and detect threats when files are downloaded through Safari, Mail, iChat, Firefox and a few more and afterwards executed. The Signature-List is updated via Apples Software Update.

Till now Xprotects database contained signatures for three well-known threats:
- OSX.RSPlug.A: changes local DNS-entries, came through fake video-codecs
- OSX.Iservice: attacks websites (DDoS), came bundled with pirated applications
- OSX.HellRTS: known as HellRaiser, tool which gives the attacker full access ofver the victims system. Version 4.2 public available, version 4.4 sold for 15$ by the creator in underground forums.

A trojan called Bohu that was spreading earlier this year caught people's attention: it has the ability to block cloud-based anti-virus services, which is kind of a new thing. The malware spreads via social engineering and mostly targets China. The guys over at MMPC have published a nice blog post with more details here.

First off, our products already detected and blocked Bohu based on its behavior profile even before we had any signatures out for it. On the contrary, if a system was already infected before the installation of a scanner, you might be in trouble...

Amongst other things, Bohu also prevents access to a Kaspersky server that hosts virus signature updates by hooking the DNS resolver in order to filter out resolution attempts for the corresponding domain name. Consequently, an infected system is prevented from automatically updating its Kaspersky signature databases, so it cannot detect and remove the threat.

However, the domain name filter can also be turned into an infection check! We have prepared a little web page at http://www.securelist.com/bohucheck that takes advantage of Bohu's blockade and displays different messages depending on whether a system can access the blocked domain or not. Users can now simply surf to this page to find out if they are infected with the trojan. If the page shows the above message, the trojan is not present.

But if the web page shows a warning message, the system is most likely infected:

In any case, if you see the message above, you should manually scan and clean your system. To do so, you can download our freely available rescue disk image and burn it to a CD or USB drive, then boot into it. As the scanner on the rescue system is not affected by the trojan's domain filter, it can still update its signatures and detect and remove the malware. More information on how to use the rescue system is available online on this link.

Security researchers work together and share information in many ways and in many contexts that aren't constrained by company boundaries, but it's unusual for security researchers working for different vendors to join forces in a company blog.

However, John Leyden of The Register contacted us both when he was writing an article on the controversy following Kaspersky Lab's dramatic demonstration of the way in which false positives can cascade from one vendor to another. This is a major issue, because it can and does introduce a serious bias into comparative detection testing and analysis. After responding to John's questions, we continued the discussion subsequently by email and found that we (along with most of the AV industry) were in agreement on all major points, and decided that it was more important to clarify those points, than to continue debating the detail of the demonstration.

The fact that the demonstration used Virus Total as a channel for cascading the "artificial" false positives to other vendors should not be seen as in any way detrimental to Virus Total. Hispasec have never endorsed the use of the service as a substitute for comparative testing or for sample validation, either of which are very likely to generate misleading results.

Multiple scanners are not in themselves the problem, whether they're hosted on public sites, specialist resources, or used by testers or anti-malware companies in-house. As tools for comparative analysis or precursors to more detailed analysis, they have a great deal of value. However, that value depends on the user's knowledge and understanding of how to make the most appropriate use of them.

Mainstream testers and security vendors have extensive understanding of these issues: however, many tests do not take them sufficiently into account. The Kaspersky Lab experiment did at least bring the issue to the attention of some of the press and publishers who most need to be aware of it, and who would probably have taken far less notice of a less controversial presentation.

As supporters of AMTSO, the Anti-Malware Testing Standards Organization, we are in emphatic agreement that away from static testing and toward dynamic testing is a positive direction. We hope that more reviewers now appreciate that dynamic testing with small but properly validated sample sets offers more realistic assessment of detection capability with less risk of unintended bias. If more people realized this, it would allow vendors to spend more time on real threats and less on making sure they detect samples that shouldn't be included in a test set.

Magnus Kalkuhl, Senior Virus Analyst, Kaspersky Lab
David Harley, ESET Research Fellow & Director of Malware Intelligence

mwcollectd v4, a next-generation low-interaction malware collection honeypot, has just been released. It's written in C++, but the easy integration of additional Python modules means that malware researchers around the world can easily extend the honeypot with new protocols and features.

We're happy to be sponsoring this project, which was mainly developed by Georg Wicherski (one of our virus analysts in Germany) and Mark Schloesser, from RWTH Aachen University. It's published under the LGPL license. If you want to take a look at mwcollectd, it's here, and libemu, which is used by mwcollectd, is here.

The other week I blogged about the newly accepted AMTSO documents.
Over the next weeks, I'll go through all the documents individually in some more detail and why they are important.

The first document we're going to have a look at is the Best Practices for Validation of Samples document.

Samples are obviously a crucial component in good testing. There are other important aspects such as proper configuration of the products and interpretation of the (scan) results.

However when we think about testing samples come to mind first and foremost.
When we're talking about validation we're strictly looking at making sure all samples in a set are functional. So this doesn't include looking at either relevance or classification of a sample.

Why is validation important? Because non-loadable files will pose no threat to the user. Therefore they don't have to, and even shouldn't be detected.

Having non-loadable files in the set will influence the test results. Let's have a look at a theoretical example. We have a 100 KB large network worm which is detected by AV product A, B and D, but C does not detect it.

Now let's look at what happens when the worm loads. As this worm is trying to infect a honey pot the connection gets broken after only 80KB of the file was transferred.

Suddenly the test results look completely different:

• Product A still detects this file as it has a signature in the first 80KB of the original file.
• Product B no longer detects this file as it had a signature that relied on the last 20KB of the file.
• Product C sees a miss-match between the info in the PE header and the actual file size and suddenly starts detecting this file heuristically.
• Product D no longer detects it as it has an emulation-based detection for this particular worm. With the worm no longer loadable it can't be emulated.

The document primarily focuses on the validation of PE (portable executable) files as these make up the vast majority of today's malware. Ideally the sample handler tries to actually execute the sample in a secure environment as this will give the most accurate results. If that's not possible for reasons such as time or resource constraints the document gives hints for statically checking if a sample is loadable.

You can find all of the published documents here.

We've been receiving a number of new samples of Trojan-Downloader.Win32.Delf.awg from users. It looks like this program, which will download Email-Worm.Win32.Scano, Trojan-Proxy.Win32.Xorpix and Trojan-PSW.Win32.LdPinch, has been widely spammed.

Delf.awg hides its network activity from firewalls by invading the svchost.exe process. The Trojan creates its own thread and uses it to download the malware, thus avoiding firewalls, which naturally allow network activity for svchost.exe.

The bad news is that you always need to be careful, and never open suspicious attachments. The good news is that KAV 6.0 and KIS detect these new modifications of Delf proactively. So even if you haven't managed to update recently, you're still protected.

I think I speak for just about the entire security industry when I say that I really value the work of the people who help out on security forums.
These people put in a lot of hard work and effectively it's all voluntary.

Some of these people create tools to remove certain malware families/types, and these tools will be very popular within the communities that they belong too.

Recently the tools created by members of one community have proved so popular that someone decided to copy them. Most of these tools are scripts, which means that they can very easily be edited. Normally editing is done to update the scripts so that they can detect new malware. Sadly, in this case someone has basically copied the scripts and put his own name to them.

This copying and taking credit for other people's work has been going on for quite a while now. Normally ignoring such people is the best course of action, so as not give them any (more) attention, but I think a line has been overstepped.

'Pcbutts1' is actively promoting 'his' anti-malware tools which remove a number of threats. This is what people see when they go to his very recently updated downloads page.

The people listed on this page are well respected within the security community and a number of them are actually Microsoft MVPs. It's 'pcbutts1' who is the fraud, not them.

Let's hope 'pcbutts1' grows up - and fast.

I now travel a lot. Trips - mostly business - make up about half my life.
Conferences, exhibitions, meetings (with short stops at the seaside or ski resorts if I stop at all). And at these events I'm asked lots of different questions. Last year one of the most frequently asked questions was my opinion about Microsoft's anti-virus, and the changes it might cause in the anti-virus industry.

That question started me thinking about the situation on the anti-virus market - and here's the result