20,000 Leagues Under The Sand, part 4
When running malware in a virtual machine sandbox, proper management of the VM is imperative to prevent (unwanted!) contamination. You may already know that it is good practice to establish a clean state with a snapshot prior to running a potential nasty, so that you can simply restore it to get back to a known good state. It’s generally pretty intuitive to do this in a hypervisor’s GUI. It’s also pretty obvious how to run the malware you’re interested in – double click and hey presto, malware happens. But what do you do if you want all that to take place without you in the driving seat?
Hypervisor APIs
There are three core elements to automating a sandbox:
- Controlling the guest VM’s state
- Interacting with the guest
- Capturing information from the guest
Fortunately, automating virtual machines is a requirement for far more than just the niche world of malware analysts. For nearly every function you could imagine, there is a means of controlling it with code instead of a GUI. You may have already noted that for my sandbox I chose QEMU/LibVirt, and one of the core reasons was the extensive resources for controlling it in the language I am most comfortable with, Python. If you are more partial to other languages, you can also choose from C, C++, C#, Go, Java, OCaml, Perl, PHP and Ruby.
Other hypervisors also have decent APIs; VirtualBox supports C++, SOAP (yuck), Java, and Python. Hyper-V is (naturally) controlled with Powershell. And so on and so forth.
Hypervisor APIs are primarily designed around the first of the three core elements (control), though there are some aspects for interaction and information capture available also. So to begin with the VM state, let us consider what control we might need. Since we want to make sure our results are relevant to the particular malware we have selected, we must be able to place the VM into a clean state. It is also sensible to only have the VM active when we are actually using it, so pausing/unpausing is also desirable (a cold boot might work, but you would either have to devise a means of logging in, or configure the VM for automatic login; plus it wastes time). These options are both possible through the LibVirt APIs.
Guest interaction
Two items involving guest interaction are essential to automate the testing of malware:
- Deliver the sample to the guest
- Execute the sample
You must transfer the sample to the guest’s file system. This can either be done from the host, or from the guest. It is theoretically possible to write directly to the filesystem, though this is strongly advised against for running VMs as it can cause corruption. Exposing a share with write permissions to the host is another option. The reverse can be done from host to guest (also not recommended). In my case I have chosen to cause the guest to download the file from a HTTP server exposed on the host’s virtual network interface. This is done with a small service running on the guest¹.
Running the sample can be done in a few ways. One that I experimented with was via a command:
cmd /c start C:\Users\<user>\Desktop\malware.exe
This should cause the file to be started with its default program and parameters. However, my results with this method were extremely unreliable, particularly with Java .jar files. It may have been possible to find out what was breaking things and fix it, but after a few weeks I was just tired of it and decided to try something else. What I wanted instead was for something that I could guarantee would work without fail. Enter VNC.
VNC is a protocol for remotely interacting with the graphical interface of a system. LibVirt comes with VNC as one of the options for interacting with guests; and handily there is a python library with which you can control VNC. Using this allowed me to send mouse movements and clicks, launching the file just as a user would. I should note here that the default protocol for interacting in LibVirt, Spice, is also capable of automation with python; however all of the resources I was finding when starting out helped me to get VNC working and I have not investigated the alternative at this point.
What we are doing here is not just executing the malware – we are simulating a user interacting with the system. This is important, because there is plenty of malware around that pays attention to what the user input is doing and will decide not to play ball if, for example, the mouse is not moving. I have also seen examples in which the malware will check for noticeable changes in the display and hide if it does not change – so just clicking empty bits of desktop is not going to help. Other samples might only become active if you visit the website of a bank (or any site the author is interested in – but mainly I have heard this in relation to banking malware). Capturing the activity of malware that does these things make simulating a variety of actions important.
VNC interaction in python
When simulating activity it is important to be aware of the limitations. If you are driving a sandbox, looking at a screen, you can react to what you see and adapt your actions. If a program has not finished running or a website has not loaded, you know to wait. You know what part of the screen is a login button for you to click, you know if there is a pop-up message that you have to approve or deny before progressing. A script controlling a VNC mouse and keyboard – unless you do some extraordinarily ambitious work with image recognition – has no concept of these things; you must carefully tailor and test your scripted actions to take account of them. Even having considered these things, my sandbox sometimes has problems; I believe some of the time this is down to hardware resource limitations – although I have programmed pauses at moments I expect something to be loading, if something else on my host decides it needs CPU time and slows everything down, the pause I’ve created might not be enough. This is just one of the possible reasons but hopefully it illustrates that the issues can strike from unexpected directions.
I hope this has been informative; the next post discusses automatic collection of artifacts and evidence from the malware you have just executed.