25 Oct Cryptolocker Wants Your Money! Costin Raiu
25 Jun The Day The Stuxnet Died Costin Raiu
12 Nov LANDesk Interchange 2011, Poison Ivy, and US Incidents Kurt Baumgartner
15 Sep Lab Matters - The Evolution of Anti-Malware Protection Ryan Naraine
22 Mar Apple's silent updates Marco
23 Feb Checking for infections with the Bohu trojan Tillmann Werner
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
You may have read about the Cryptolocker malware, a new ransomware Trojan that encrypts your files and demands money to return them.
In the past, we have witnessed similar malware like the famous GPCode that used RSA keys for encryption. Back in 2008, we cracked the 660 bit RSA key used by GPCode and provided the victims with a method to decrypt and recover their data. Later, the GPCode authors upgraded the RSA key to 1024 bits, putting it perhaps only in the realm of NSA’s cracking power.
LANDesk Interchange 2011 is winding down in Las Vegas today. The event gathered partners and displayed newer technologies offered by the decade old systems management company. It was interesting hearing from IT "old-timers" that have worked with the technology, describing the company's impact on the industry - its spinoff from Intel, the original LANDesk AV product that wound up in another vendor’s product, and what they like about Kaspersky Lab technologies integration into the security suite. We were happy to present at our partner's conference with "The Dark Side of Unmanaged Desktops", where I described 2011 incidents that both I and our Global Emergency Response Team have investigated and remediated, some incidents in the news, and some of the IT mismanagement issues that enabled these incidents to occur.
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.
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 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:
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.