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.
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.
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.
Jul 26th 2007
1 decade ago