ESET Threat Blog

Further to my recent post on the venerable (but still out there) Slammer worm, we were asked recently about a real old-timer, a boot-sector infector called Stoned.Angelina. (Oddly enough, I think this was the last BSI reported to me when I was still doing occasional 2nd-linet AV support earlier in this decade.) How could such an elderly virus infect a protected system?

For those who may have missed out on this phase of virus pre-history, a BSI infects when a PC is booted with an infected floppy (remember those?) in drive A. (The floppy doesn’t have to be bootable.) Which is why we used to advise people to reconfigure their PC CMOS settings so that the system would boot by default off the hard disk even if there was a floppy disk present – when people made extensive use of the funny little things, it was surprisingly easy to forget there was one still in the floppy drive when you switched off the system.

From a detection point of view, the difficulty is that if the system isn’t initially booting from the hard disk, the infection has already taken place by the time a scanner gets a look-in, and, unfortunately, NT derived systems can present particular problems if a BSI does manage to infect the hard disk.

Because so many systems nowadays are floppy-free zones, we tend not to give much thought to the issue. However, there are clearly still vulnerable systems and infected diskettes out there. If this might apply to you, you might want to consider:

• Checking CMOS configuration on all systems (especially older systems) and fix any that are still set to boot by default from drive A
• Doing a little data housekeeping. Floppy disks aren’t the most reliable of media for very long-term storage, and you may want to transfer data that still need to be kept to a more resilient and less risky storage medium.
• While you’re doing that housekeeping, you might want to take the opportunity to scan those disks with an up-to-date scanner. Certainly I have floppies around here that were probably last checked with scanners that don’t even exist any more.

David Harley
Research Author
ESET LLC

With the release of ESET’s Mobile Antivirus, a security solution for smart phones, I started asking myself about mobile threats. While there is not as much malicious software attacking mobile platforms as exists in the desktop world, I was able to find some interesting samples to analyze. The following is an analysis of the WinCE/Brador.A malware.

The first job most malicious programs do upon execution is to insure they will be started every time an infected system boots. To do so, Brador.A copies itself to the \\Windows\\Startup folder under the name svchost.exe. Under Windows mobile, there is no need to modify the registry to start an application automatically.

The main functionality of the threat Brador.A is to open a backdoor on the mobile device. The attacker is notified by an email when a new device is infected. The backdoor can perform the following tasks:

• Find a file on the local drive
• Read a file from disk and send it to the attacker
• Execute an executable from disk
• Display a message box saying “Hi” using the MessageBoxW API.
• Close backdoor connection

The orders from the controller are sent over a TCP connection. The first character of the network packet is the order sent from the attacker, for example, ‘f’ denotes find. Even if the code has been compiled for ARM processors, understanding it is relatively easy for anyone with experience in the x86 world:

BL      recv ; Calls the recv function
LDRB    R0, reception_buffer
LDR     R1, =dgrpmf_string

cmp_string:
LDRB    R2, [R1],#1
CMP     R0, R2
BNE     cmp_string
LDR     R0, =(dgrpmf_string+1)
SUB     R1, R1, R0
LDR     R3, =call_table ; Call table contains references to the six functions of the backdoor
LDR     PC, [R3,R1,LSL#2]; Call the corresponding function from call_table

The samples I have analyzed are all very similar. They seem to have been released in 2004 and don’t use any packing mechanism to hide their behavior or hamper reverse engineering. Furthermore, the code we analyzed does not contain any infection routine. Thus, the only way a mobile device can be infected by this threat is if a user runs the program. To ensure the security of your mobile device, we recommend that you use the same security measures as for a desktop: don’t run unknown programs.

Pierre-Marc Bureau

Malware Researcher

 In my copious free time, I sometimes answer questions on security issues on one of those "Ask the Experts"  pages. It sometimes feels a bit like stepping into a not-quite-parallel universe, where it’s still 2002-3: a strangely high proportion of those queries are about Helkern (the worm most us know as Slammer or SQL Slammer, or even Sapphire). How can such an old threat still constitute such a problem?

In fact, it doesn’t. It’s essentially a noise generator, a classic example of malware intended only to replicate. That’s bad enough, of course: no-one wants to waste bandwidth on the networking equivalent to housedust, and in any case, there’s always a risk that malware that does very little will have unexpected consequences on some systems in some contexts. In general, though, it doesn’t pose a significant risk to anyone not running an unpatched SQL Server installation. The "noise" comes from the fact that there obviously are still unpatched installations out there somewhere that keep sending probes out to random IP addresses over UDP/1434. The problem arises because some security software generates an alert every time it sees that wretched UDP packet, and users assume that (a) their system is in danger (b) they’re the victim of a targeted attack (not so – the target IPs are selected randomly (c) they’re seeing a huge onslaught of attacks by a worm that isn’t picked up by other security software. Back in this universe, any competent, mainstream scanner is capable of detecting Slammer, but most don’t generate alerts for random probes.

However, it’s usually possible to turn off alerts for network attacks in firewalls (and at least one AV engine) where alerting on everything is enabled by default, without turning off protection, and you can still check logs to see that the product is doing its job and blocking such probes, where appropriate, if you need that reassurance.

David Harley
Research Author
ESET LLC

Layer L0

Layer L1

Layer L2

Because almost the entire analysis was done statically, I missed some "tricks" during the rebuilding of the imports.

Anti Debug

Lukasz Kwiatek

I run (in my copious free time) a page called Mac Virus that I inherited from Susan Lesch, who ran it as a comprehensive Mac antivirus resource. (That page has nothing to do with the later pages at macvirus.org or macvirus.net, by the way, which also refer to themselves as Mac Virus, and recently experienced infestation problems with fake codecs.)

 I’ve never really had the time to keep Mac Virus current to the standard that Susan did, updating it on a pretty much daily basis, but I try to keep at least half an eye on the Mac malware scene and try to help out with Mac-related queries when I receive them. This week, I had one of those "So what Mac malware is there really?" enquiries. This really ought to be an FAQ at Mac Virus, I guess, but until it is (and because there are readers of this blog who are interested in Mac issues), here’s a quick summary of my response. Even at the risk of an avalanche of rabid Mac zealots telling me that I don’t know what I’m talking about.

 There are quite a few older malicious programs that are specific to the Mac, though hardly any of them are likely to have any effect on a modern system (especially an Intel-driven system, where the Classic/pre OS X environment is no longer supported), and I haven’t seen any of them reported in years. (Is anyone still using HyperCard?!) 

Then there are some proof of concept viruses for OS X, but they don’t pose much of an immediate threat. (Of course, replicative malware is a shrinking proportion of current malware even on Windows platforms.)

There are other malware-related threats that you should be aware of, if not panicked by. (We’re not talking huge numbers to date.) For instance, Trojans like the DNSchanger fake codecs mentioned earlier, the occasional rootkit, rogue anti-malware programs… Some of these are affecting

And there are the cross-platform issues: macro viruses aren’t a very big deal now, but they haven’t altogether disappeared, and there are other  issues with MS Office document vulnerabilities, though the exploits have been almost invariably Windows-specific till now. Also, VBA  is absent from the latest Office for Mac, though  it will be back in the next version, apparently.

In fact, there is a persistent risk of Windows-specific or cross-platform malware spreading by way of Windows non-users. It was actually an instance of that – the macro epidemic of the mid-1990s – that dragged me into the Mac anti-malware arena in the first place.

I would advocate that Mac users in a corporate environment should be using protected machines, irrespective of the perceived risk from Mac-specific threats. I would never discourage the use of commercial anti-malware by home users (there is some free AV for Macs, but none that offers comprehensive protection). Macs aren’t at anything like the same level of direct risk from malware that Windows is, and may never be. That said, we do see the bad guys getting interested in mining sparser seams of potential victims as Windows users become more security-conscious. Some, including me, believe that the risk level is increasing, but slowly. We may not yet be at the point where anti-malware protection is essential even for people who use Macs at home and who don’t take foolish risks. But never say never.

As it happens, Apple have just released a comprehensive – well, large, anyway – document on securing Leopard.  Being an Apple document, it includes a brief mention of viruses (summary: use antivirus, practice safe hex) but makes no mention of the wider range of malware that might concern you more. Ah well… I do happen to know that "OS X Exploits and Defense" (published recently by Syngress) includes more information on malware, because I wrote those two chapters. Contrary to the impression you may get from some book sites, though, I didn’t write or tech-edit the whole book (the confusion arises because I had to withdraw from editing due to imminent surgery), and I haven’t found time to read the rest of the book yet. When I do, I’ll give you the benefit of my prejudices.  

David Harley
Research Author
ESET LLC

With the June Virus Bulletin test, ESET became the first antivirus company in the world to pass 50 tests for VB100 awards.

As consumers I think you should know what the VB100 award means. First of all, a VB100 award does not mean that a product detects 100% of all viruses or malware. The VB test only includes self-replicating code (viruses and worms and potentially some bots). Normal Trojans, spyware, and adware are not in the test. The samples used by Virus Bulletin and most certification bodies are the samples on the Wildlist. The Wildlist organization has reporters throughout the world. If two reporters submit samples of the same virus from different locations then it is placed on the Wildlist.  We know for a fact that there are lots of viruses out there infecting people that are not on the Wildlist.

One of the purposes of the Wildlist is to create a test set that only includes samples that we know are infecting users and actually do work. One of the problems with many tests is that they use files that should not be detected because they are corrupted and do not run. In many cases we have seen harmless text files in test sets as well.

The Wildlist provides a scientifically sound test set. The Wildlist does not provide a statistically significant test set. That is to say that you cannot tell what anti-virus product is best based upon Wildlist testing alone. Even if we could collect every real threat in the world, I don’t think you could decide what product is best based upon any single test. That would be like picking a stock because it had the biggest gain one day.

Another thing to know about the VB100 is that it is essentially a test that all of the anti-virus companies have the answers to in advance. The AV companies have fundamentally the same set of samples before the test.

In order to obtain a VB100 award a company has to detect all of the samples on the Wildlist and do so with no false positives, both on-demand and on-access.

Most of the critics the VB100 award have obviously never successfully tried to make an antivirus product of even low relative quality. The fact that so many companies fail the tests for missed viruses indicates it actually is a bit more difficult than one might think, especially since the companies have the answers to the test in advance.

50 VB100 awards is a track record and an indication of the dedication of quality that ESET’s developers and researchers have!

There are more difficult tests out there, but you should expect your AV product to be able to deal with the easier tests on a consistent basis, especially since we all know that the samples in the test are really infecting users!

Randy Abrams
Director of Technical Education
ESET LLC