11

Once I perform static analysis on a malware sample, I next run it in a virtual machine.

  • Does this give the malware a chance to spread to the real machine?
  • Does this give the malware a chance to spread across networks?
  • What steps/tips can I follow to prevent the malware from spreading from the VM?

I use VMwareW.

  • I edited your question to clarify the main point. I also attempted to make it less broad than it was before, otherwise it would have been closed. Have a look at the questions FAQ for more. – asheeshr Jul 22 '13 at 2:38
  • possible duplicate of How can I analyze a potentially harmful binary safely? – PSS Jul 22 '13 at 5:47
  • 2
    Note also that the malware may detect the virtual machine and stop operate as usual. Then, you will need to install it on a real machine (or change your VM). – perror Jul 22 '13 at 6:45
11

The malware can propagate from the VM to the host in several circumstances:

  • If there's a bug in the VM software. That's not very common, but it's possible.
  • If there's a bug in the host OS. A bug that specifically allows malware to break out of a VM is unlikely but again possible.
  • If there's a bug in the processor. That's even more unlikely but still not mathematically impossible.
  • If there's a way for the malware to exchange information with the host. This can be over the network; in this respect, there's no difference between using a VM and using a separate physical machine, so you need to firewall the VM appropriately (allow only the bare minimum, don't do anything that might allow the server to hijack the client such as SSH with X forwarding). Another vector is via the VM tools such as file and clipboard sharing: the software running in the VM might read and write shared files, access the host clipboard, etc. So when running malware in a VM you should disable all these convenience tools (disable them in the VM configuration, it's not enough to refrain from installing the guest software since the malware could come with its own).

For more on that topic, read https://security.stackexchange.com/questions/9011/does-a-virtual-machine-stop-malware-from-doing-harm and https://security.stackexchange.com/questions/12546/is-it-safe-to-install-malware-in-a-vm

All in all, most malware can be analyzed safely in a properly configured virtual machine. Disable all guest features and don't connect to the VM with any protocol that allows the server to influence the client. Firewall the VM as if it was hostile (it is); you should use a host-only network so that you can easily control what goes there.

There's another reason why you might prefer a physical machine to a virtual machine. There's quite a bit of malware that attempts to detect whether it's being analyzed, and doesn't behave maliciously when it is. Obvious, common things that malware tries to detect is signs that it's running under a debugger: check if it's being ptraced (or the Windows equivalent), check for sudden pauses in the execution, … And some malware looks for telltale signs of a VM, such as drivers for hardware that common VM software emulates, or CPU oddities that are inexistent or rare outside emulated CPUs. This isn't to say that you cannot analyze malware in a VM: sometimes you can, sometimes you can't, it depends on the malware. If you start in a VM and find nothing you need to be prepared to move to a physical machine.

Note that there are risks with a physical machine too: malware could attempt to plant itself into one of the many pieces of firmware on the motherboard and peripherals. Toolkits for this are beginning to emerge, such as Rakshasa and Mebromi. So if you analyze some sophisticated malware on a physical machine, don't trust this physical machine any more, ever.

  • 1
    >That's even more unlikely but still not mathematically impossible, it is very real and dangerous, just check out the erretas from intel or AMD, the best bug i found was in a Core2 Series where the memory above 4GB wasn't secured completly – Quonux Jul 28 '13 at 1:35
5

There were a lot of saying in replays, but I'd like to stress on some answers from the practical point of view:

  • network connection - a while ago I would agree that simply disconnecting the vm from the network will solve the problem of spreading through the network. Today, there are more and more malwares that will work only when the connection to CnC has been established or at least it can ping to the outer world, so I'd suggest that you should think about more serious solution than just disconnecting the cable:
    • setup another vm which will function as a gateway, this will also help you to log the traffic
    • use network simulation software like iNetSim which can help in some cases when you need to fake the result returned by the CnC
    • setup firewall and try not to use network shares or at least make them read only
  • VM setup - not installing vm tools is of cause a way to hide vm from the malware but it is really hard to work on such vm. The very least that you should do, is setup the VM in a more stealthy way. I've found a couple of links that may help with this, but there are many more other solutions:
    • Bypassing Virtual Machine Detection on VMWare Workstation - you can find here vmware configuration options for stealthier work and some other stuff.
    • Malware anti-VM technics - some explanations about what helps the malware to detect vm
    • the next step is to develop different proprietary tools that can help you with research and more advanced anti-vm techniques.
    • try to setup your environment is such a way, so that the host and the guest are different OSs - host is linux/unix/osx and the guest is windows. This will further minimize the risk of host infection.
  • physical machines - from practical point of view the use of physical machines is pretty annoying and consumes time and demands much accuracy especially when dealing with unknown malwares and I'm not event talking about the restore overhead after the machines were infected.

Hope this will help :)

4

if youre using VMWare I suggest using a host only connection. Typically when you create a VM it will use NAT or bridged, sharing the host computers IP and/or network adapter. Using Host-Only lets the VM only be locally connected to that particular adapter with no internet connectivity(It's assigned its own local IP and uses its own Gateway)

Typically when running malware live you want to go with this setup. Your other solutions are using sandboxing software such as cuckoo sandbox or sandboxie. They have the added ability to log what the malware is doing and keeping it sandboxed ( It usually doesnt touch system files or infects the system in any way)

4

If the VM software has a bug a malware can also spread out of the VM and infect the host computer.

There is also the possibility that the underlying processor (if you are using hardware virtualization) has a bug which lets the malware escape the VM.

If you have a network connection it is possible that the malware can spread over the network. So to prevent this you have to choose a setup which may never have a network connection. Even disabling the network in the guest is not enough. The VM has to be setup so that no network connection is possible.

To prevent the spreading of malware you have to disconnect your testing device (the host) from the network and set it up for every malware newly. Also be aware that malware may use the MBR or the BIOS to nest into your computer.

3

Use the latest and greatest version of VMWare. Monitor your real system. :) Why? well I've seen malware that 'breaks' out Vmware. How? Ring -1 exploitation. It's not something you'll commonly seen. But it can happen, will it with your sample unlikely but, it might.

So, monitor your own system (ProcMon). Don't install VMware tools (easier detected by the sample and it might just be dormant). And try a number of VirtualSystems, Qemu, VirtualBox the works.

Have fun :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.