The biggest malware threat we’re dealing with at the moment is definitely the Storm worm. Unless your e-mail address is ultra secret, you probably received more than a couple of infamous e-card e-mails asking you to visit a strange URL address that can potentially lead to your machine being infected with the Storm worm.

While the Storm worm hasn’t brought anything really new, the authors definitely went a step further – the Storm worm’s code looks much better than a lot of malware we’ve seen. And besides that, you have a custom packer that makes analysis and detection more difficult, rootkit capabilities so it’s completely hidden, P2P botnet control and so on.

While analyzing one sample I noticed that the Storm worm tries to detect if it’s running in a virtual environment. This became pretty popular with malware writers lately. The main reason they're doing this is (presumably) to make analysis more difficult. The first step in malware analysis today is typically to run it in an isolated environment and to monitor its behavior.

By detecting virtual machines and changing the behavior, malware authors make analysis more difficult – an AV researcher either has to run the malware on physical machines, modify the virtual environment he’s using to prevent detection or manually analyze the malware. That being said, virtual environment detection is also a double edged sword for malware authors – by implementing something like this they are effectively losing certain number of potential victims which will only be higher in the future, as virtual machines are more and more popular (especially for servers).

The Storm worm tries to detect two popular virtual machine products: VMWare and Microsoft’s VirtualPC. If it detects that it’s running in one of these products it will simply reboot the machine – the machine will not be infected. So, let’s see how the Storm worm does this.

VMWare detection

The method used above was published by Ken Kato (http://chitchat.at.infoseek.co.jp/vmware/backdoor.html) and it uses VMware’s “backdoor” I/O port. Basically, VMWare supports a magic number (0x564D5868 = “VMXh”) that has to be used with VMWare’s I/O port (0x5658 = “VX”). After the IN instruction, if the program is running in VMWare the EBX register will contain the magic number. This method makes it trivial to detect VMWare (there are many, many other ways for doing this). Of course, if you are manually debugging this you can just change the result of the CMP instruction (zero the Z flag) and the Storm worm will not detect that you’re running in VMWare.

VirtualPC detection

The Storm Worm uses Elias Bachaalany’s method (http://www.codeproject.com/system/VmDetect.asp - this web site seems to be down at the moment) for VirtualPC detection. Basically this method consists of using illegal instruction opcodes. The program sets an exception handler that is called on normal CPUs when an illegal instruction is encountered. However, if you are running in VirtualPC this will not happen and the program can easily detect if this is the case (the EBX register will stay 0 if VirtualPC is running).

It will be interesting to see if malware authors will change these tactics in the future as the number of virtual machines will grow for sure. As I already wrote – virtual environment detection is a double edged sword – it makes malware analysis more difficult (it is not always easy to circumvent detection as in this case) but it also decreases the number of potential victims. It is also clear that malware authors keep improving their code and that they are keeping an eye on research fields that interest them, such as virtual machine detection.

UPDATE: Some e-cards do like virtual environments …

I’ve received several submissions from our readers about samples that do work in virtual environments, especially in VMWare.

The sample I originally analyzed was one of the first variants of the Storm worm, acquired back on 2nd of July. After I received these e-mails I decide to quickly analyze couple of fresh samples (after all, I just need to check my e-mails – over the night I received a dozen of them).

Indeed, I found out that the latest versions of the Storm worm work in VMWare without any problem. What’s even more interesting, the latest sample I analyzed didn’t even try to hide itself – the process was nicely visible from the user land.

While I haven’t analyzed this further, there seem to be two main variants, just judging by their file size. Here are some samples I acquired, with their file sizes:

139238        fc66e6af9efd1cabdc52cf9aafd75140
96740         fc6c3532b4e27cb9ea59fde9898a6927
96695         fc7cee5c1e5717c10cf709c96e563d9c
96729         fc8c88a4d571afc8f2bc8eaec6eea759
96850         fd236947368d63c80dcd58eb809354d4
139247        fd3a02abc6ebc5001a6e3ba614579079
96771         fd436facccb626fadc5eecaa8c092d05
139173        fe2da62aa2ce1f0a54e78a50b2f538d7
139192        fe4ec24803b9f5f42cff13aaf8932b6b
139169        fe55823bfed577f1882c4ef79d683919

I’m not sure yet, but it looks like the 139kb variant includes a rootkit, while the 96kb one doesn’t.

One other thing I noticed was that almost all received e-card e-mails were marked by spam by my e-mail system. After checking the triggered rules (by SpamAssassin) it looks like the combination of DCC+Razor+various RBLs does the job. This also makes sense - since e-mails are almost identical (with minor changes) it is very easy to detect them as spam with fuzzy matching algorithms such as those used by DCC and Razor.

--
Bojan